The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 1993 23:21:53 -0500
From:      panvalka@cs.unc.edu (Anay Panvalkar)
To:        comp.protocols.tcp-ip
Subject:   Re: Books....

In article <bansal.725649006@depot.cis.ksu.edu.cis.ksu.edu> bansal@cis.ksu.edu (Vivek Bansal) writes:
>
>I am looking references to some books which deals with writing system 
>software using UNIX and TCP/IP. I already have Comer and Stevens .
>
>I intend to write some device driver using STREAMS, switch software and
>other such kind of network software in near future. Any references in this
>context would be really appreciated.

I find the Sun Network Programming manual (Sun OS 4.1.2) very useful for 
STREAMS programming.

-Anay

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 93 16:59:53 GMT
From:      klaus@kphunix.han.de (Klaus Peter Herrmann)
To:        comp.protocols.tcp-ip
Subject:   LAN 8bit

I like to have an 8 bit connection on the remote login (abount telnetd).
The LAN is from Lachman. The Terminal-emulation on my PC can work
in 7-bit or 8-bit mode. But the System (SCO Unix) gives only an 
7-bit connection. Where can I change this?

Klaus

-- 
-------------------------------------------------------------------
Klaus - Peter Herrmann  	klaus@kphunix.UUCP
W-3000 Hannover   		klaus@kphunix.han.de
-------------------------------------------------------------------

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jan 1993 17:07:35 GMT
From:      vijay@iitb.ernet.in (Vijay J. Talati)
To:        comp.sys.cdc,comp.protocols.tcp-ip
Subject:   finger for CYBER (NOS/VE)

Hi,

Has anyone out there ported the TCP-IP programs , especially finger and talk
onto CDCNET's CYBER (NOS/VE).?

Any pointers would be helpful.
Please e-mail responses to vijay@gateway.iitb.ernet.in

Thanks.

Vijay



-- 
-----------------------------------------------------------------------
Vijay Talati                        Email: vijay@iitb.ernet.in
ERNet Lab.                          (X.400):
Computer Centre                      s=Talati ou=gateway o=iitb prmd=ernet c=in

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jan 1993 18:41:00 +0000
From:      shaman@cix.compulink.co.uk (Leo Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. PATHWORKS

In-Reply-To: <9212301417.AA22248@TIS.COM> mjr@TIS.COM (Marcus J. Ranum)

..Not forgetting Pathworks for Macintosh, which is an appletalk 
server on your DEC mini...:-)



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 1993 19:43:30 GMT
From:      scoggin@delmarva.com (John K. Scoggin, Jr.)
To:        comp.networks.noctools.wanted,comp.protocols.tcp-ip
Subject:   Looking for tools

In the Internet System Handbook, two tools are mentioned which appear to be quite useful:
	NCNS	network performance measurement tool from CMU
	NNam	network analysis tool from Merit

Does anyone know how to go about procuring copies of these tools?
---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
+---------------------------------------------------------------------+


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jan 1993 22:01:12 GMT
From:      dalk@login.dkuug.dk (Lars Kalsen)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Mixed trafic - x.25/TCP/IP

Hi - and Happy New Year,

We are considering a new network which connect all of our different
sites through a WAN. We will probably buy some CISCO routers. 

The trafic which is routed through the CISCO equipment is split
in two

       - FTAM trafic based on x25 connections             
    
       - Interactive terminal sessions based on TCP/IP on an Ethernet.


The CISCO routers can mix these two kinds of input intp one 2Mbit channel
which connects the different sites.

My concern is now : Will the interactive traffic suffer when a heavy
FTAM transport is taking place ?. Will the file transfers affect the
responsetimes for the interactive traffic to a large extend ?.

Is you have any experience with this please E-mail (or fax) me the 
information

~e



-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 93 22:34:18 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems detecting a dead client connections ??????

>But this may well annoy (or bankrupt) users of PayPerPacket networks, or
>those with Dial On Demand serial links.

It may well also annoy people who don't want the application to give up
on the machine on the other end of the connection just because some
router or link between the two machines was down for a while....

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 93 11:09:45 GMT
From:      bill@twg.bc.ca (Bill Irwin)
To:        comp.protocols.tcp-ip
Subject:   Trouble configuring UUCP on TCP/IP

A piece of information that I forgot to provide:  I had to change
the entry in /etc/inetd.conf for uucpd from "/etc/uucpd" to
"/usr/lib/uucp/uucpd" in order to get to the password prompt.  I
just changed the entry back to "/etc/uucpd" in both system's
files and got the following:

mchFind called (McDonal)
list (rmail) num = 1
fillFlds: entered
fillFlds: returning
list (/) num = 1
list (/) num = 1
list (ALL) num = 1
_Request (TRUE), _Switch (TRUE), _CallBack (FALSE), _MyName (), _Commands ALL
chdir(/usr/spool/uucp/McDonal)
conn(McDonal)
ProtoStr = e
Device Type TCP wanted
Internal caller type TCP
tcpdial host McDonald, port 540
family: 2
port: 7170
addr: 02029384
set interface TCP
processdev: calling setdevcfg(uucico, TCP)
getto ret 5
sendthem (^M)
expect: (gin:)
login:got it
sendthem (hammond^M)
expect: (word:)
 user unknown^Jlost line errno - 108
 ^^^^^^^^^^^^
close caller (5)
delock(TCP,e)
Call Failed: LOGIN FAILED
exit code 101
Conversation Complete: Status FAILED

TM_cnt: 0

Notice the "user unknown" above?  I was getting this when there
used to be a password on the account, before the password was
even prompted for!  Now I have removed the password because of
some recent postings about two Sun systems needing the parity
changed for the password.  Since this is a TCP connection, the
password is not necessary, so I've removed it.

I don't know why there are two "uucpd" programs, one in "/etc"
and the other in "/usr/lib/uucp", but using the one in uucp does
not produce the "user unknown" message.  I think that there is
some TCP configuration info either missing or incorrect so that a
UUCP connection attempt bombs this way.

This is new territory for me so I'm just guessing at what could
be wrong.  The documentation does not cover setting up UUCP on
TCP/IP very well at all.

Thanks for any help you may be able to provide.
-- 
Bill Irwin    -       The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!twg!bill            (604) 431-9600 (voice) |     Your Computer  
bill@twg.bc.ca            (604) 430-4329 (fax)   |    Systems Partner

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Jan 1993 11:53:04 GMT
From:      andrew@megadata.mega.oz.au (Andrew McRae)
To:        aus.sun-works,comp.sys.sun.admin,comp.sys.sun.hardware,comp.protocols.tcp-ip,aus.sources
Subject:   Announcement: CSLIP for SunOS 4.1.x

A revamped SL/IP package for SunOS 4.1.x is available for
anonymous ftp from dmssyd.syd.dms.csiro.au, under
the file src/cslip-sunos.tar.Z

Kam Tam from the CSIRO has kindly allowed me to place the
package on dmssyd, as we do not have a direct Internet
connection. Any comments, complaints or corrections should
*not* be directed to anyone at the CSIRO, but to
me (andrew@mega.oz.au).

I have seen several people asking about cslip for 4.1.x, and
I have sent a few people this package and they tell me it works,
and that I should make it publicly available, so here it is.

The first origins of the software is lost in the mists of time;
Mark Andrews (from CSIRO) converted it to use SunOS STREAMS.
I used that package as a base, and have hacked it mercilessly to
add VJ TCP header compression, and to streamline it so that it can
run a little faster.

It has been tested and used on IPC's, SS1's and some other
Suns we have lying around, all under SunOS 4.1.1 - I don't
see any reason why it wouldn't drop into any 4.1.x system,
but your mileage may vary.

The primary motivation for doing this was to get TCP
header compression running on low speed (2400 baud) SL/IP
lines - PPP could not be used because the terminal servers
on the other end can't talk PPP. Even if you do not
use header compress, it is probably worth using this
package for ordinary SL/IP because of the CPU cycles you
will save.

Please send any comments, patches etc. to me. It would help
if someone compiled it and ran it on 4.1.3 just to see
if it works.

The README is attached.

Enjoy!

Andrew McRae			inet:	andrew@mega.oz.au
Megadata Pty Ltd,		uucp:	..!uunet!mega.oz.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847
------------------
README for SunOS 4.1.1 Compressed SL/IP

The original package was developed by Mark Andrews @ CSIRO DMS Sydney,
from the original SL/IP stuff.

This version has been much modified, with the dual goal of adding
Van Jacobsen's TCP header compression, and improved performance.
Even if you do not use the header compression stuff, the reduced
load on the CPU is worth it.
It should be completely compatible with old SL/IP drivers, as
the TCP header compression can be enabled/allowed via an option
to slip-attach.

A summary of changes:

- Added TCP header compression - The standard header compression code
  was used unmodified *except* for a small mod to use mbufs in the
  decompression so that the caller would not have to allocate 128 bytes
  at the start of every packet. The new slcompress.c is included.

- Collapsed the SL/IP frame encoding from a separate STREAMS module
  into the main module. An attempt to reduce extra overhead.

- Removed re-copies of data. As a result of having two STREAMS modules
  in the stack, the same data was copied to and fro several times.

- Attempted to guess some buffer sizes to avoid scanning the whole
  packet and count the ESCaped characters.

- Added the FLAGS setting code, and also put in the slip stats
  counting.

By far and away the biggest difference in performance is due to the
(almost paranoid :-) avoidance of data copying. In the old code I
counted 4 copies of the same data; 1) from zs driver to STREAMS mblk,
2) in slipencode, from STREAMS mblk to internal buffer, 3) at end
of packet to another mblk for xfer to str_ip, 4) in str_ip from
the mblk to the mbufs. On output the code scanned the entire packet
and counted the escapes before allocating a mblk, then had to
scan the packet again to copy it.

The new code copies the mblk data from the zs driver directly to mbufs,
after doing the SL/IP frame decoding.
On output a buffer is allocated after a scratch-the-head fudge
factor is added to the actual length of the packet, and then the
packet is copied. If it runs out of room, it retries with a bigger
packet etc. I keep a track of the number of recopies, and it has
never needed to do one yet, so I figure it's a win.

The SunOS 4.1.1 serial driver for the Zilog 8530 (at least on
all the Suns I have tried) is still a performance black hole, but
at least the rest has been leaned down somewhat. It does make
a difference. The problem seems to be related to extra interrupts
and CPU load when the SL/IP is busy. For example, in one test I
sent large ping packets to an idle workstation on a 19.2 Kbaud
SL/IP line; the system time went to over 50%, and the number of
interrupts went to over 27000 per second (I would only expect around
4000 max), so if *anybody* knows what's going on and can give
me a magic fix, I would appreciate it.

Installation Instructions.
--------------------------
cp slip_var.h slcompress.h /usr/include/sys
cp slip_var.h slcompress.h /sys/sys
cp streamsip.c slcompress.c /sys/os

edit /sys/conf.common/files.cmn and add the lines:

os/streamsip.c                optional slip
os/slcompress.c               optional slip


edit /sys/sun/str_conf.c and add:

#include "slip.h"

#if     NSLIP > 0
extern  struct  streamtab streams_ip;
#endif

#if     NSLIP > 0
	{ "str_ip", &streams_ip },
#endif

Edit your kernel configuration /sys/sun?/conf/MACHINE and add the
line below to install the SL/IP psuedo devices.

pseudo-device    slip2

Build the new kernel, install and reboot.

make and install slip-attach and slipstat

run slip-attach
	slip-attach [ -csa] device speed local remote netmask

Where -c will turn on header compression, -a will only turn it on
if a valid compressed SL/IP packet is received. The default is
to disable the header compression. -s will set a small MTU (256 bytes);
the default is 1006 bytes.
e.g.
/usr/local/etc/slip-attach -c /dev/ttya 19200 my_host their_host 255.255.255.0

slipstat will give you statistics about normal and compressed packets sent
and received. Run it with stdin set to the device that the SL/IP module
is running on e.g.

	slipstat < /dev/ttya

Slipstat has an option (-c) to print the header compression stats, and
you can also put a delay and count in to continuously print the stats e.g:

	slipstat -c 10 5000 < /dev/ttya

will print the header compression stats every 10 seconds for 5000 samples.

Enjoy!
Andrew McRae (andrew@megadata.mega.oz.au)

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Jan 1993 13:53:51 GMT
From:      mg@world.std.com (marcia a gulesian)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for OS/2  -  BOSTON DEMO  -  FEBRUARY 2  -  7:00 pm


UPCOMING EVENTS: 

Boston Area OS/2 USERS' GROUP (BCS)


FREE SOFTWARE DOOR PRIZES !   REGISTRATION NOT REQUIRED !


January 12, 1993     7:00 p.m.      (Tuesday)

OS/2 DATA COMPRESSION;  OS/2 PERFORMANCE TUNING & OPTIMIZATION:

Part 1 - Theory of data compression, architecture of Stac
Electronic's STACKER  FOR OS/2, increasing the utility of
fixed disks through data compression, live demonstration.

Part 2 - Tips and techniques for matching the design of
OS/2 with that of your DOS, Windows, and OS/2 applications.
This talk will focus on the dissection of CONFIG.SYS.

Note: Vendor demonstration of new  OS/2 software for the
"power user," beginning at 6:30 pm.


February 2, 1993    7:00 p.m.      (Tuesday)

TCP/IP for OS/2;  OS/2 PERFORMANCE TUNING & OPTIMIZATION

Part 1 - Discussion and live demo of X Windows, NFS (operating
peer-to-peer), Telnet, FTP, SMTP (E-Mail), SNMP (network management, 
SLIP (TCP/IP over a serial line) etc . . . . first across a Local Area Network,
then over The Internet.

Part 2 - Tips and techniques for matching the design of OS/2 with
that of your DOS, Windows, and OS/2 applications. This talk will 
focus on strategies for partitioning the fixed disk, selection of 
a file system. etc.


GENERAL MEETING INFORMATION

LOCATION :  IBM BOSTON COMPUTER CENTER,
One Copley Place,  Boston, Mass. Near Back Bay
and Copley train stations.

DIRECTIONS : Mass. Turnpike East - Exit 22 (Copley Square
Lane) - First Left onto Dartmouth St -
Next Left onto Huntington Ave. Enter COPLEY
PLACE PARKING on left.

FREE PARKING : Free parking when you spend $5 and
have your parking ticket validated in any restaurant
or store at Copley Place, provided you enter the
garage after 5 p.m.


For more information on meetings, please telephone Marcia
Gulesian at (508) 369-3918.


-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 93 16:45:48 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Services getting CLOSED??

We've been having some problems lately with services getting CLOSED out.
When this happens, you can do a netstat and it will show telnet, for
example, as being in a "CLOSED" state.  No one can telnet in because it
did not do a passive open.  What could be causing this?  When I kill the
offending telnet process, it clears up the problem.  But I'd like to
know what is causing it in the first place so I can correct it.  Any
ideas?

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 1993 09:35:05 GMT
From:      mathias@solomon.technet.sg (Mathias Koerber)
To:        comp.protocols.tcp-ip
Subject:   wanted: rpc info, primer, generator

I'm looking for a primer on rcp, general info and some tools and maybe
a generator to help in creating programs that use rpc.

Any pointers?

Thx alot
Happy New Year
Gong Xi Fa Cai

--
Mathias Koerber	                    | Tel: +65 / 7780066 ext 29
SW International Systems Pte Ltd    | Fax: +65 / 7779401
14 Science Park Drive #04-01        |
The Maxwell, Singapore Science Park | email: mathias@solomon.technet.sg
Singapore 0511                      |        swispl@solomon.technet.sg
-------------------------------------------------------------------------------
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 1993 09:55:42 GMT
From:      bill@twg.bc.ca (Bill Irwin)
To:        twg.sco-list,comp.protocols.tcp-ip,biz.sco.general,comp.mail.uucp
Subject:   Solution to: Trouble configuring UUCP on TCP/IP


bill@twg.bc.ca (Bill Irwin) writes:

: unilabs!chare@uunet.UU.NET (Chris Hare) writes:
 
: : In article <2808@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes:
: : >
: : >I am having trouble configuring UUCP to use the TCP/IP network as
: : >its "device".  I have two systems, both running SCO UNIX 3.2.4,
 
: : I went through this recently.  this is what you need to do.
 
: : In Devices, create an entry which reads
 
: : TCP TCP,e     -       Any     TCP     540
 
: : Note:  this instructs uucp to use the 'e' protocol, and to connect on port
: : 540.
 
: I have the uucico accessing the TCP device now, but it is failing
: after the password is given to the remote system.  Following is a
: portion of the -x9 log:
 
: mchFind called (SystemB)
 [stuff deleted]
: sendthem (^M)
: expect: (gin:)
: login:got it
: sendthem (systema^M)
: expect: (word:)
:  Password:got it
: sendthem (password^M)
: msg > Login incorrect.^Jimsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg
 
: The ">imsg" stuff keeps going and going until the log is is over
: 700Kb in size.  Then it fails.  I have seen this type of output
: on a normal modem connection before, but can't recall what it is
: a symptom of.

Actually, this was the uutry log produced after I changed the
entry in "/etc/inetd.conf" from "/etc/uucpd" to
"/usr/lib/uucp/uucpd".  There seemed to be another uucpd on the
system and it seemed to get me a little further along in the
dialogue.  The original uucpd was producing a "user unknown"
message right after the login name was given and before a
password was even checked.  This is the right uucpd to use, which
was pointed out to me by belal@sco.com.  The one in usr/lib/uucp
was released with the UNIX runtime in error and was compiled from
an earlier version of the source, with the wrong development
environment.

The mystery is solved.  It seems that the Systems file entry chat
script that was used when a modem was being used to connect was
producing my "user unknown" message.  Here are the two entries
that I have used to fix the problem:

#SystemB Any TCP,e  Any - --gin:--gin:--gin:-BREAK-ogin:-BREAK-ogin: systema word: foobar
SystemB Any TCP,e  Any - gin: systema word: foobar

The first one was being used until today, when I was mailed an
extract from the SCO "How to" database that showed the greatly
simplified chat script.  I decided to take a shot in the dark and
see if the BREAK (which I never saw being sent in the uutry log)
was causing the trouble.  The second entry worked fine, first
try.

I am now going to test the first entry by just removing the BREAK
portion of the entry, to see if it is the syntax of the script
that causes the problem, or the BREAK.

I would like to thank the following people who responded and
helped in this solution:

fenner@cs.psu.edu (Bill)
belal@sco.com (Bela)
chare@unilabs.org (Chris Hare)
fitz@wang.com
giles@promed.com.au (Giles Lean)
udo@umonk.GUN.de (Udo Monk)
-- 
Bill Irwin    -       The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!twg!bill            (604) 431-9600 (voice) |     Your Computer  
bill@twg.bc.ca            (604) 430-4329 (fax)   |    Systems Partner

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 93 10:23:10 GMT
From:      nguyenth@amertume.ibp.fr (Thao Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Distributed Applications?

Hi there,

First: Happy New Year All ;)

I'd like to know more about distributed applications. I mean how do they really work and how to implement
them. If any gurus out there give me some hints on that.
Also, if there's any newsgroups, mailings or books that I can refer to if I want to know more
about distributed development. (e.g. is client-server applications can be called distributed?)
Well I'm kindda *rookie* so excuse me if it's not the right newsgroup for that :)

Thanx & Bye
-- 
Thao
Believe it or not but I have no e-mail address!

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 93 13:18:34 GMT
From:      moshek@FibHaifa.com (Moshe Kochinski)
To:        comp.protocols.tcp-ip
Subject:   Source files from TCP/IP Volume 2 Douglas E. Comer


Hi Netters,

How can I get the source files from the Douglas E. Comer book -
Internetworking with TCP/IP Volume 2 ?

Thanks,


-- 
Moshe Kochinski
------------------------------------------------------------------
Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL
phones: +972-4-313665/620              Fax: +972-4-313342
e-mail: moshek@FibHaifa.com   or     moshek@fibronics.UUCP
------------------------------------------------------------------

-- 
Moshe Kochinski
------------------------------------------------------------------
Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL
phones: +972-4-313665/620              Fax: +972-4-313342

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 1993 16:17:04 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Source files from TCP/IP Volume 2 Douglas E. Comer

	The sources to volume II of _Internetworking_with_TCP/IP_ are
copyrighted by Prentice Hall and available for sale only. You can get them
through Prentice Hall (order number 47322-3 [Sun cartridge] or 47233-2
[9-track 1600 BPI tape]), or directly from us at a higher price. I'll send
ordering information directly to you, and anyone else interested can send
me mail for details.
	And while I'm at it, the sources for volume III are available for
free via anonymous FTP to "ftp.uu.net", directory "published/books", file
"comer.internetworking3.tar.Z".
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 93 17:32:46 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Software release problem?

In article <1huab3INNs4t@vttux1.vtt.fi> leino@rat.vtt.fi (Tapio Leino) writes:
    
    a) If the TCP/IP-software in my PC is the Wollongong WINTCP for DOS
       there is no trouble in connecting the PC (with telnet) to the 4D/20G
       type IRIS with the older IRIX 3.3.1 operating system,
       but it cannot be connected to the other IRIS (with IRIS 4.0.5)?
    
    b) If I am using a product called PCTCP instead of the WINTCP I can
       connect to both IRIS workstations with no trouble.
    
    This started when we took the newest release 4.0.5 of IRIX! Before that I
    could connect the PC to both workstations with WINTCP.
    
    We have checked what happens on the lines. The messages seem to go to the
    IRIS quite OK but the messages it sends to the PC are not understood by
    the WINTCP and everything just stops.

It isn't really clear from this what the problem is:  Does ARP fail (you
should be able to check the cache on both ends), or is it that ARP works
but TCP can't make a connection?  Or is the problem that the TCP connection
opens but you never get a Telnet prompt?

If ARP fails, then the issue may be in the PC's hardware driver - you don't
say which network interface you're using, but the TWG driver may not go to
as much effort to salvage packets in the face of board errors.

If TCP won't connect, examine the packets and refer to RFC 793.

If Telnet never gets a prompt, the issue might be in Telnet option
negotiation.  Check the Assigned Numbers RFC for the names of the options
that Irix is asking for, and check how the PC responds to each.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 93 17:39:58 GMT
From:      peterson@commtg3.rtp.dg.com (Kevin Peterson)
To:        comp.protocols.tcp-ip
Subject:   BOOTP and the first stage bootstrap

Is there a configuration option in bootp that will allow a
client to get a bootp request from one machine and the first
stage bootstrap from another machine.  We had the impression
that this is possible but I cannot find out how to accomplish this.
We have multiple subnets and are willing to put a bootp server
on each of the subnets. We would like the clients to boot off
of a different machine than the bootp server.

Thanks for any help.

- Kevin

--

                             ,,,
                            (o o)
------------------------oOO--(_)--OOo-----------------------
|                                                          |
| Kevin Peterson              | peterson@dg-rtp.dg.com     |
| Data General Corporation    | Research Triangle Park     |
| Tie-line: 262-6342          | (919)248-6342              |
 ------------------------------------------------------------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 93 17:43:08 GMT
From:      ad0@cbnewsj.cb.att.com (amarjet.dhingra)
To:        comp.protocols.tcp-ip
Subject:   Need help with CCITT SS7 docs picked from FTP site

I picked up some files from gumby.dsd.trw.com.  These are postcsript
format CCITT SS7 files in directory /pub/standards/ccitt/1988/postscript.
WHen I print a file , text shows up fine but figures don't print at all.
I looked at the file (Don't know anything about postscript language) and
it SEEMS that source for figures is not there at all.  Anybody has
any ideas, please send email at 
att!mtgzfs3!ad0
or ad0@mtgzfs3.att.com

Thanks in advance.

Amarjit

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1993 19:22:39 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and the first stage bootstrap

In article <1993Jan4.173958.17884@dg-rtp.dg.com> peterson@commtg3.rtp.dg.com (Kevin Peterson) writes:
>Is there a configuration option in bootp that will allow a
>client to get a bootp request from one machine and the first
>stage bootstrap from another machine.

This seems to be an ugly part of the BOOTP protocol.  If you look in section
7.3 of RFC 951, the client is expected to use the siaddr field as the TFTP
server's IP address and sname as the name.  I would think it would be safe to
set siaddr and sname to something other than the BOOTP server's address.
Why would the client want the BOOTP server's address?  What it really needs
is the TFTP (or other boot protocol) boot address.

I'm sure this will be a controversial suggestion, but I think it's justified.
It satisfies the use of the siaddr (and sname) fields, if not the intent.
If it really bothers you, think of it as "proxy BOOTP".  ;-)

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1993 19:41:14 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and the first stage bootstrap

Oops!  I forgot to mention that your client will have to use the RFC 1084
vendor extensions, or a similar vendor extensions field, in order to give
the client its netmask and gateway.  You can't TFTP through a gateway
without that info.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 1993 21:25:53 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Determining your pty

	A little insight/info would really be appreciated!!

1) I need to write an application that services users who dail-up via a terminal
server and are rlogin'ed or telnet'ed to a specified host.  Is there any easy way
from a 'C' application to determine the pty?

2) Since TCP/IP is the underlying transport, does using pty's cause significant
additional overhead?  Is there a straightforward method of accessing the socket,
and doing socket level communication between the process and the terminal server?

Thanks in advance!!!!!!

Ron


-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 93 23:30:40 GMT
From:      mcdermj@atlantis.CS.ORST.EDU (Jeremy Mcdermond)
To:        comp.protocols.tcp-ip
Subject:   Help with SLIP setup


	Can anyone send me some meaningful e-mail on how to set up SLIP from
an IBM PC running FTP Software's PC/TCP with the Clarkson SLIP8250 packet 
driver to a Microvax II running 4.3 BSD?  I have tried with no sucess, it seems
as if no packets are making it out even though PC/TCP says that it is sending
them.  This is designed to be a dialup connection over 2400 baud modems.  Thanks
in advance.

------------------------------------------------------------------------------
Jeremy C. McDermond				mcdermj@leela.cs.orst.edu
OSU Computer Science Outreach Support Staff	jeremy%symbio.uucp@cs.orst.edu
------------------------------------------------------------------------------

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 93 00:20:49 GMT
From:      jimg@ocean.rutgers.edu (Jim Gasprich)
To:        comp.protocols.tcp-ip
Subject:   STARLAN 10 10BASE-T hub unit doesn't like adapters

I have two somewhat old (circa 1988) STARLAN 10 hub units that 
are part of our TCP/IP ethernet LAN. Our lab is wired twisted pair
with RJ-45 plugs. This is fine for our PCs with their RJ-45 port 
cards, but for our UNIX boxes (Suns), we need to use AUI to RJ-45
adapter boxes.

Here's the problem. We recently bought a new (1991) adapter box from
Cabletron, but it did not work when we wired it up. We have a few 
old adapters from AT&T (which came with our now defunct 3B2s (ick!)),
and some others from a company called David Systems, which work A-OK.

I am somewhat perplexed. Has there been a change in the 802.3 standard,
are our hub units no longer usuable, or am I just missing something
somewhere ?? It would seem a shame to throw out 22 usuable ports, 
especially with the price of some of the new fancy-pants hubs I've
been looking at.

I apologize if these are newbie questions, or are more appropriate to
another, more wire-head hardware group.

Thanks,

Jim Gasprich                          e-mail: jimg@ocean.rutgers.edu
Research & Support Slave                tel:    (908) 932-9631
Cook College Remote Sensing Center      fax:    (908) 932-8644
Dept of Natural Resources
Rutgers University
New Brunswick, NJ, O8903        "Du bist mein Gweckman" - Anonymous Fascist

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jan 1993 07:29:59 GMT
From:      root@exicom.OZ.AU (Ray Soo)
To:        comp.protocols.tcp-ip
Subject:   ARE THERE ANY TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS?




is there any program(s) available which enables one to
query remote gateways for routing table information 
i.e. do a remote netstat -rn on arbitrary hosts
on the internet?

please mail replies to ray@exicom.OZ.AU

thanks,

ray


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1993 13:51:23 GMT
From:      leino@rat.vtt.fi (Tapio Leino)
To:        comp.protocols.tcp-ip
Subject:   WINTCP or DOS / IRIS Problem.

Hi folks,
Last week I posted an explanation about a problem with the
Wollongong WINTCP for DOS TCP/IT connection to IRIS workstation.

I received two mail answers and one posting to this newgroup.
Shantanu Kothavale from the Wollongong Group answered that there
is something in the WINTCP which makes it do this. It had something to
do with the large window sizes.
Tom Mitchell from Silicon Graphics responded also and he said that
the large window size of 60k in the new release of IRIX is the cause and
that we should alter it as the parameter fortunately is external (the
value in earlier release is 24k). The same has happened with several
other products than WINTCP too.

We did it and now it seems to work again.  Thank you very much!

This just makes us wonder. Why has the window size been changed? What
do we lose changing it back to its original value, 24k?

-- 
Tapio Leino
Technical Research Centre of Finland / Laboratory of Structural Engineering
mail: VTT/Rakennetekniikan laboratorio, P.O. Box 26, SF-02151 ESPOO, Finland
tel: -358-0-456 6683, telefax: -358-0-456 7003    e-mail: Tapio.Leino@vtt.fi

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jan 1993 16:00:17 GMT
From:      geranen@phx.mcd.mot.com (Scott Geranen)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and the first stage bootstrap

In article <1ia2pvINNj7b@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
>In article <1993Jan4.173958.17884@dg-rtp.dg.com> peterson@commtg3.rtp.dg.com (Kevin Peterson) writes:
>>Is there a configuration option in bootp that will allow a
>>client to get a bootp request from one machine and the first
>>stage bootstrap from another machine.
>
>This seems to be an ugly part of the BOOTP protocol.  If you look in section
>7.3 of RFC 951, the client is expected to use the siaddr field as the TFTP
>server's IP address and sname as the name.  I would think it would be safe to
>set siaddr and sname to something other than the BOOTP server's address.
>Why would the client want the BOOTP server's address?  What it really needs
>is the TFTP (or other boot protocol) boot address.
>
>I'm sure this will be a controversial suggestion, but I think it's justified.
>It satisfies the use of the siaddr (and sname) fields, if not the intent.
>If it really bothers you, think of it as "proxy BOOTP".  ;-)

I have done exactly this.  The only "trick" is that the CMU bootpd server
checks to see if the download file is on the system.  When the new "sa"
(server address) tag is used in the bootptab file it doesn't check for the
file -- I didn't want to try to verify that the file existed on the remote
system.  I've sent this modification to CMU but I haven't seen it come back
out.

Also, as noted in a later post, you need to send the gateway and subnet
mask if you're booting through a gateway.  

Another useful modification I made was to be able to use host names instead
of IP addresses for the "ip" tag.  I hate duplicating information already
in the hosts file.

>
>-- 
>Stephen Trier                      "We want to offer you a price that you
>Network software type               just can't afford to take advantage of."
>Case Western Reserve University         - Sales blurb from HSC Software
>trier@ins.cwru.edu


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

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 93 21:42:47 EST
From:      roseberry@taney.uscghq.uscg.mil
To:        comp.protocols.tcp-ip
Subject:   Mil-Stds for TCP/IP


	Does anyone know what Mil-Stds discuss the various parts of TCP/IP,
	SMTP, FTP, and Telnet ?

	Thanks.

	- Bert Roseberry
	  US Coast Guard

	  roseberry@taney.uscghq.uscg.mil


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 93 17:31:21 GMT
From:      soner@.cs.pitt.edu.cs.pitt.edu ( & Onder)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS SLIP and telnet problem

apollo@buengc.bu.edu (Doug A. Chan) writes:
: In article <1992Dec23.043717.1680@colorado.edu> garnett@refuge.Colorado.EDU (Santiago de la Paz) writes:
: >In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
: >>Whenever I try to telnet to a host, it just hangs there...
: >>What is wrong with telnet?
: >One of the primary reasons why a telnet attempt like this will hang is if
: >the remote host cannot reverse-lookup the IP address of the host you're 
: >coming from.  Make sure that both hosts are forward and reverse-mapped
: >(just for thoroughness, doncha know) if you're using DNS, or that they're
: >both in your machine's hosts files.
: 
: It wasn't any host/IP address problem (FTP, ping, nfsping, NFS, finger all
: work fine!)  The host table is okay... just telnet was broken.
: I turned on all of PC-NFS' telnet debugging and it got stuck during
: the initial negotiation (after it has established a connection with
: the host). 
: -Doug
Reminds me of some sort of Telnet option negotiation loop or deadlock. Your 
telnet program may be responding WILL to some option but may not be 
properly doing so. Something like this may cause the other system to wait
indefinitely. The other possibility is the two pairs are entering to
an WILL/DO or DON'T/WONT kind of negotiation loop. I don't know how PC-NFS
telnet debugging feature works, but depending on the implementation, I 
think you may not be able to see anything on the trace if a loop occurs.


                                        Soner Onder


-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jan 1993 19:51:10 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: STARLAN 10 10BASE-T hub unit doesn't like adapters

The main difference between StarLan10 and 10baseT is that 10bT requires
LinkBeat, and SL10 doesn't know what it is.  In a SL10 network, you need
to disable LinkBeat on all devices on the network.

- Steve Kao

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jan 1993 20:47:02 GMT
From:      maw@netcom.com (Martin Walker)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need NDIS spec please


Hello all.

I am looking for a complete spec for NDIS. Please can anyone tell me where
I can order/ftp/download a copy of said spec. Please respond via email
to maw@netcom.netcom.com. Thanks in advance.

Kean Johnston, via
maw@netcom.netcom.com
-- 
Martin Walker               |  "One way to stop a runaway horse
++27-12-344-3973 (w)        |   is to bet on him"
++27-12-998-7263 (h)        |   maw@netcom.com
Pretoria, South Africa      |   martin@paradigm.CO.ZA

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 93 22:37:54 GMT
From:      olo@ccwf.cc.utexas.edu (Lee Thomas)
To:        comp.protocols.tcp-ip
Subject:   NEEDED:  A good TCP/IP short course. (Austin, Dallas area)


I need to attend a good TCP/IP course that would cover administration issues,
network management, programming (RPC or some DCE maybe), etc. 

Thanks for any ideas!

-Lee Thomas

---------------------------------------------------------------------------
Lee Thomas                              Voice: (512)322-6386
Systems Specialist                        FAX: (512)322-6350
City of Austin Electric Utility      Internet: olo@ccwf.cc.utexas.edu
---------------------------------------------------------------------------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jan 1993 22:49:47 GMT
From:      davidr@cs.uow.edu.au (David Ian Raymond)
To:        comp.protocols.tcp-ip
Subject:   Re: Distributed Applications?

nguyenth@amertume.ibp.fr (Thao Nguyen) writes:

>Hi there,
 
>First: Happy New Year All ;)
 
>I'd like to know more about distributed applications. I mean how do they really work and how to implement
>them. If any gurus out there give me some hints on that.
>Also, if there's any newsgroups, mailings or books that I can refer to if I want to know more
>about distributed development. (e.g. is client-server applications can be called distributed?)
>Well I'm kindda *rookie* so excuse me if it's not the right newsgroup for that :)
 
>Thanx & Bye
>-- 
>Thao
>Believe it or not but I have no e-mail address!

Hi,
  This seems like a good book:

Distributed systems / edited by Sape Mullender.
New York, N.Y. : ACM Press ; Wokingham, England ; Reading, Mass. :
          Addison-Wesley Pub. Co., c1989.

I had a bit of a read of it to get a basic idea of distributed systems.

David
davidr@cs.uow.edu.au

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1993 23:00:12 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip,comp.mail.mime,comp.os.ms-windows.apps
Subject:   Frontier MIME support in Super-TCP for Windows ?

Open Systems Today (4 Jan 1993) reports that Frontier has a MIME mailer
for MS Windows.  Can anyone from Frontier comment on how well it works,
or even send me some nice multimedia mail to show that it does?

The listed phone contact is +1 414 241 4555, no email was listed tho.

thanks,

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB
           (keeper of the comp.mail.mime FAQ, write for a copy)

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 93 00:33:23 GMT
From:      valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
To:        comp.protocols.time.ntp,comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: xntp3 socket problem with UDP datagrams from INADDR_ANY.

In article <1992Dec29.115408.103086@ipgaix.unipg.it> peppe@ipgaix.unipg.it (G. Vitillaro) writes:
>
>I had this problem with xntp3 (in xntpd) under AIX/370 1.2.1 (1400).
>I'm interested to understand if I met a bug and
>if there is any way to go over the problem.

Oh.. *that* little bug.  It drove me bonkers while trying to get
AIX/370 and xntp to cooperate.  Here's the fix I used to work
around it:

*** ntp_io.c.dist       Tue Mar 17 16:39:15 1992
--- ntp_io.c    Tue Mar 17 16:40:26 1992
***************
*** 688,693 ****
--- 688,694 ----
                printf("sendpkt(%s, %s, %d)\n", ntoa(dest),
                        ntoa(&inter->sin), len);
  #endif
+       if (inter == any_interface) inter++;

        for (slot = ERRORCACHESIZE; --slot >= 0; )
                if (badaddrs[slot].port == dest->sin_port &&


This basically prevents xntpd from "seeing" the 'wildcard' interface.

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 01:57:23 GMT
From:      ray@exicom.OZ.AU (ray)
To:        comp.protocols.tcp-ip
Subject:   MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS

many thanks to all those people who replied to my last post, when i asked how
would i perform the equivalent of a remote "netstat -rn" on 
arbitrary internet hosts.

Most people suggested SNMP. However, wouldn't this limit me to
querying hosts running SNMP? 

I was hoping that there would be a solution which only required 
that the gateway in question be running some routing daemon
talking RIP (e.g. gated), which is a more common property of gateways
than SNMP .

I vaguely remember hearing of a program called ripquery, but i can't
find any info on it. Has anyone heard of such a thing ; would this
do the job I just described in the previous paragraph?



-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 93 05:21:09 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS

In article <C0EtFo.FCq@exicom.OZ.AU>, ray@exicom.OZ.AU (ray) writes:
> many thanks to all those people who replied to my last post, when i asked how
> would i perform the equivalent of a remote "netstat -rn" on 
> arbitrary internet hosts.
> 
> Most people suggested SNMP. However, wouldn't this limit me to
> querying hosts running SNMP? 
> 
> I was hoping that there would be a solution which only required 
> that the gateway in question be running some routing daemon
> talking RIP (e.g. gated), which is a more common property of gateways
> than SNMP .
> 
> I vaguely remember hearing of a program called ripquery, but i can't
> find any info on it. Has anyone heard of such a thing ; would this
> do the job I just described in the previous paragraph?



There is `rtquery` source in the standard 4.3BSD distribution (I think
in the tools subdirectory of the routed subdirectory), and binary
shipped on some (at least one--guess which) vendors' workstations.

Rtquery works by sending out mostly ordinary RIP requests.
It obviously doesn't work if you are not using RIP.
It also does not work if the remote machine is picky, as cisco routers
seem to be.


Vernon Schryver,   vjs@sgi.com

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Jan 1993 16:13:21
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Mil-Stds for TCP/IP

In article <1993Jan5.214247.123@taney.uscghq.uscg.mil> roseberry@taney.uscghq.uscg.mil writes:

          Does anyone know what Mil-Stds discuss the various parts of TCP/IP,
          SMTP, FTP, and Telnet ?

MIL-STD-1777 is IP, 1778 is TCP, 1780 is FTP, 1781 is SMTP, 1782 is
Telnet.  However, most of the above are either incorrect, obsolete or
both.  See RFCs 963 and 964 for errors in 1777 and 1778.  RFC 959
(the correct spec for FTP) and a number of Telnet Option RFCs
post-date 1780 and 1782.  I don't know anything specific wrong with
1781, but you should refer to RFCs 821 and 822 anyway.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 93 18:23:01 PDT
From:      chris@distinct.com (Chris Bologna)
To:        comp.protocols.tcp-ip
Subject:   A short course in TCP/IP

>> I need to attend a good TCP/IP course that would cover administration issues,
>> network management, programming (RPC or some DCE maybe), etc. 
 
>> Thanks for any ideas!
 
>> -Lee Thomas

I know that the American Institute run hands-on training courses for TCP/IP -
they run courses all over the country.  I don't know what the level of the 
course is really at as I only know about it through their catalogue.  You
might want to call and find out.  Tel: (800) 345-8016

Chris Bologna
Distinct Corporation
14395 Saratoga Avenue, Suite 120
Saratoga, CA 95070

Tel: (408) 741-0781
Fax: (408) 741-0795
email: chris@distinct.com
*******************************************************************************

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 17:02:12 EST
From:      H. D. Knoble <HDK@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Help with CUTCP 2.2 TN/TC-D Telnet...

I cannot reproduce your problem with my version of TN3270 or TELBIN.
I'm running on an old PS/2 55SX with 8M Ram using a Token Ring Card and
drivers. I'm running under IBM DOS 5.0 (CSD UR36603 2/92), running from
DOS prompt, or DOS Shell, or from Windows PIF.

As of November 30, 1992 Clarkson U has updated the TN3270.EXE module (the
OMNIGATE.CLARKSON.EDU file /pub/cutcp/v2.2-E/tn3270.exe ). This newer file
is 112 bytes bigger than the previous one dated earlier last November.
I doubt that this has anything do to with your problem as the older TN3270
also does not fail on my configuration.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 93 12:20:12 GMT
From:      brunke@DKRZ-Hamburg.dbp.DE (Lutz Brunke)
To:        comp.protocols.tcp-ip
Subject:   Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REM


ripquery is a program which comes with gated. But it does not show
the routing table of a gateway, it only show which rip routes the
gateway is advertising.

Lutz

---

-------------------------------------------------------------------------
Lutz Brunke				Deutsches Klimarechenzentrum GmbH
Tel.: +49-40-41173-329			Abteilung Kommunikation
E-mail: brunke@dkrz-hamburg.dbp.de	Bundesstr. 55, D-2000 Hamburg 13
-------------------------------------------------------------------------



-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 93 18:04:18 EST
From:      SYAZDI@PK705VMA.VNET.IBM.COM
To:        comp.protocols.tcp-ip
Subject:   FTP Performance, FTP Performance information

Reply: SYAZDI@pk705vma.vnet.ibm.com

I have been looking for information regarding FTP performance on
different workstations and/or file servers?  I have found 0 so far.
Does anyone know/or have pointers to what "industry" performance
levels are for different machines.

Thanks in advance for any information.

Sean Yazdi


-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 13:48:52 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: PoP3 Daemon ftp site

> Does anyone know where I can find an FTP site for the PoP3
> daemon. I can find plenty for PoP2, no PoP3 alas.

I tried to reply in private, but the headers on your posting (and
your signature) didn't indicate an email address.  I don't know
of European locations, but here are two U.S. locations:

Unix POP3 Daemon:
        lilac.berkeley.edu
        /pub/popper

VMS POP3 Daemon:
        logos.ucs.indiana.edu
        /pub/iupop3

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


-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 14:02:38 GMT
From:      "Vladislav Akhmedov" <avg@gsrcc.msk.su>
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   NE2000 multicard driver. HELP!


Hi folks,

I have got a small problem with my ISC UNIX System V r.3.2 version 3.0.
I try to set UNIX LAN with UNIX NFS server and several DOS NFS (PCNFS)
workstations. Some of this wks are connected to one NE2000 of the UNIX
server and other ones to second NE2000 on the UNIX server. OK! I have got
UNIX server with two NE2000 cards. But UNIX have not multipcard driver for 
this adapter (only NE0 driver, no one NE1 or NE2 as Western Digital cards).
And file /etc/conf/pack.d/ne0/space.c has not structure declaration 
struct neparam neparams[NNE] = {
	...
	}
I have got some ideas about files /usr/include/sys/ne2k*.h, but i'm not 
sure, am i right or not.
If somebody knows anything of it, please tell me.
							Thanks in advance.
Vladislav Akhmedov, Russia, Moscov.
E-mail: avg@gsrcc.msk.su
	smm@gsrcc.msk.su
	


-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 15:24:57 GMT
From:      mpiet@is.morgan.com (Mark Pietrasanta)
To:        comp.protocols.tcp-ip
Subject:   Shareware TCP/IP, NFS

Has anyone out there used shareware TCP/IP and/or shareware NFS in
a production situation?  I am interested in other peoples experiences
with this and would be interested in any and all comments.  Please
respond by mail if possible.

Thanks,
Mark Pietrasanta - mpiet@is.morgan.com
* * * * * * * * *

"Great spirits have always encountered violent opposition from
mediocre minds." - Albert Einstein

----------------------------------------------------------------
Disclaimer: These responses are my own and in no way reflect the
            views of my employer.
----------------------------------------------------------------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 15:37:58 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REMOTE HOSTS

In article <C0EtFo.FCq@exicom.OZ.AU> ray@exicom.OZ.AU (ray) writes:
>
>I was hoping that there would be a solution which only required 
>that the gateway in question be running some routing daemon
>talking RIP (e.g. gated), which is a more common property of gateways
>than SNMP .
>
Using only RIP may not give you all of the information you want.  You can
certainly send a RIP Request to a remote machine. But, the only information RIP
will send back is a list of destinations for which that machine has routes, and
the associated metrics.  For example, it will not tell you what gateway the
remote machine uses to reach the destination.  Nor will you get any of the
other information which netstat provides.

Bill



-- 
Bill Warner						(317)494-1787
General Consulting					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 93 16:30:43 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   anonymous ftp






Is there any RFC or other kind of documentation that may
describe how the "anonymous ftp" works ?

Any pointers would be appreciated,

Maritza


-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1993 17:34:51 GMT
From:      cliff@garnet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: PoP3 Daemon ftp site

|> Unix POP3 Daemon:
|>         lilac.berkeley.edu
|>         /pub/popper

This should read:

|> Unix POP3 Daemon:
|>         ftp.cc.berkeley.edu
|>         /pub/popper

	Thanks,
		Cliff Frost
		UC Berkeley

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1993 19:09:17 GMT
From:      haynes@cats.ucsc.edu (Jim Haynes)
To:        comp.sys.sun.apps,comp.protocols.tcp-ip
Subject:   Has anyone ported 'query' to SunOS?


'query' is a program that has been around for a while, supplied as a
tool for debugging the route daemon routed.  It's available as part of
the Berkeley Net-2 code; but that version appears to be incompatible with
Suns because the differences in the way signal works.  Has anybody done
the necessary work to port query?
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 19:14:11 GMT
From:      burch@seas.smu.edu (Chris Burchett)
To:        comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Help! (75 seconds to connect() after reboot)

Help!  I've found a situation in which I'm unsure of the best 
solution.  The problem has to do with a 75 second timeout in the 
connect() system call.  This occurs after one of two previously
connected machines is rebooted and an attempt is subsequently
made to reestablish communication.

I am using TCP/IP via Berkeley sockets to communicate between a Sun
workstation and an embedded system running VxWorks.  After communi-
cation is established, the embedded system is rebooted.  Once the
reboot is finished an attempt is made to reestablish the connection,
at which point, the connect() system call on the embedded system is
unable to reconnect and times out after 75 seconds.  

I believe this may happen because the embedded system is using the 
same port number that was used for a connection before the reboot 
occured (while the remote machine still maintains an established 
connection on that port).  It appears that (after a reboot) if the 
embedded system attempts to connect() using a port number which was
not previously connected, the connection is immediately established; 
this is the desired behavior.  However, if the embedded system uses 
a port which was previously connected, the connect() system call 
times out after 75 seconds.

Unfortunately, in my application 75 seconds is somewhat too long 
to wait.  I have a potential work around, but it seems to be
sort of a kludge and I felt certain that this problem must be a 
known one with known solutions.  (I'm relatively new to NEWS and if
this is a topic which has already been discussed in depth or I have
improperly used this service in any way, I appologize.)  But if 
someone with insight into this problem would enlighten me on the 
issues involved, or documentation to be studied, or potential 
solutions, I would greatly appreciate the help.


Chris Burchett
email: burch@seas.smu.edu
voice: (214) 205-8065

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 93 19:48:43 GMT
From:      dawkins@acsu.buffalo.edu (Desmond D. Dawkins)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Help with CUTCP 2.2 TN/TC-D Telnet...

I'm having a strange problem with CUTCP 2.2 TN/TC-D.
(I'm not the primary user of this machine) 
Whenever the user exits from Telnet via logging out of the last session, 
ALT-X, or even ALT-F3, it hangs requiring a 'hot boot'. It never fails!
ALT-E does work, however. As does DOS-shelling from other programs - 
(WordPerfect). I'm at a loss. 
The following is a list of things I've already tried:
  a. stripped everything from the AUTOEXEC.BAT and CONFIG.SYS 
  b. reinstalled Telnet
  c. virus-checked the machine
  d. checked that COMSPEC was looking at the right COMMAND.COM

This is the configuration:

* 486/33 compatible with 4M RAM. 
* MS-DOS 5.0
* 3Com board 3c503 
* version 7 for the packet driver - 3c503.COM
* invocation - 3c503 -w 0x7e 0x3 0x310
* version 3.04 of the protocol - IPX304.COM

I would appreciate all suggestions that you might have. I'm pretty much
-- 
*  SUNY/Buffalo, 221 Computing Center, Buffalo, NY 14261 USA 716-645-3983 *
*  e-mail: dawkins@acsu.buffalo.edu,dawkins@ubvms.bitnet                  *
*   "One often meets his destiny, down the road he takes to avoid it."    *
 

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 21:13:40 GMT
From:      garnett@refuge.Colorado.EDU (Santiago de la Paz)
To:        comp.protocols.tcp-ip
Subject:   Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REM

brunke@DKRZ-Hamburg.dbp.DE writes:
>
>ripquery is a program which comes with gated. But it does not show
>the routing table of a gateway, it only show which rip routes the
>gateway is advertising.
>

Careful: ripquery is not to be trusted, precisely because it does *not* 
truthfully show the routes that are being rip-advertised.  ripquery operates 
by generating a rip POLL, which explicitly asks the queried gateway to say 
what its rip-list looks like.  Unfortunately, most machines ignore 
split-horizons when they respond to a rip POLL, so what you'll see is a 
list of *all* the advertisements that gateway is making, regardless of whether 
or not it will make them onto the network that you're querying over.

The only way to really make sure of what advertisements a gateway makes is
to sit and listen for them, e.g. with gated tracing turned on or some
handmade NIT utility.

~james

  James Garnett, Network Engineer                               (303) 444-1338
  garnett@cogwheel.com

  Cogwheel Incorporated, Boulder  ***  Producers of low-cost dialup IP routers
                        Boulder-Denver/Hong Kong


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 1993 23:03:03 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp

In article <1993Jan6.163043.17410@walter.bellcore.com>,
maritza@espresso.bae.bellcore.com (Maritza Ramirez) wrote:
> 
> 
> Is there any RFC or other kind of documentation that may
> describe how the "anonymous ftp" works ?
> 
> Any pointers would be appreciated,
> 
> Maritza

There is a document by Tom Czarnik, called Anonymous FTP List - FAQ,
which he posts regularly to a number of newsgroups: comp.archives.admin,
comp.misc, comp.sources.wanted, alt.sources.wanted, & news.answers.

It should answer your questions.



Matt Healy
"I pretend to be a network administrator; the lab
 net pretends to work!"

matt@wardsgi.med.yale.edu

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 93 23:44:22 GMT
From:      hwajin@iphasew.com (Hwa-Jin Bae)
To:        comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: Help! (75 seconds to connect() after reboot)

In article <1993Jan6.191411.4535@seas.smu.edu> burch@seas.smu.edu (Chris Burchett) writes:
>Unfortunately, in my application 75 seconds is somewhat too long 
>to wait.

in vxworks 5.0+, there is an undocumented call -- connectWithTimeout() which
takes the same args as connect() plus extra last arg of type 'struct timeval *'
which you may be able to use -- you can specify the delay of your own.

or you could also just try non-blocking connect() -- set socket FIONBIO
temporarily, call connect(), which should return EINPROGRESS immediately
if connect attempt is to block -- when this happens you should select()
for 'write'.  the socket will be marked writeable once's it's connected.
to verify the connection after select() returns with 'write' selected, you
can do a getpeername().  this is actually what connectWithTimeout() does.
[ i do hope this is still in vxworks, it was a few years back when i put this
into the system ]

hwajin

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 93 08:05:44 CST
From:      shan@cray.com (Sharan Kalwani)
To:        comp.protocols.tcp-ip
Subject:   Re: A short course in TCP/IP

In article <1006.UUL1.3#20656@distinct.com> chris@distinct.com (Chris Bologna) writes:
>>> I need to attend a good TCP/IP course that would cover administration issues,
>>> network management, programming (RPC or some DCE maybe), etc. 
 
>>> Thanks for any ideas!
 
>>> -Lee Thomas
>
>I know that the American Institute run hands-on training courses for TCP/IP -
>they run courses all over the country.  I don't know what the level of the 
>course is really at as I only know about it through their catalogue.  You
>might want to call and find out.  Tel: (800) 345-8016
>
>Chris Bologna


you may also wish to contact InterOp. I don't have a phone number handy....
also the USENIX, LISA folks have TCP/IP courses too....


-- 
Sharan Kalwani, cri, 2000 town center suite 2350, southfield mi 48075 
phone:    (313) 576-3948				(313) 335-5580
internet: shan@cray.com 		uucp:  ...!uunet!cray.com!shan

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 11:24:31 GMT
From:      grunert@jupiter.rz.Uni-Osnabrueck.DE (Joerg Grunert)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP with XINU

I want to use TCP/IP with the XINU system and a WD8003 Ethernet card.
If you have a source code in C please mail it to me.
It will help me also, when you mail me the Internetaddress of a FTP Server
where I can find the Programms.



Regards
     grunert@jupiter.rz.uni-osnabrueck.de

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 12:06:41 GMT
From:      kees@echelon.uucp (Kees Hendrikse)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Problem with SCO TCP/IP 1.2 and Kermit

When I use Kermit (3.11 or 3.12) to connect to a SCO/Unix system with
TCP/IP 1.2 installed, everything works fine, except for two annoying
details:

1) I can't send a DEL to interupt a process. If I hit the DEL key
   (or ^C after 'stty intr ^C') a 'r' character is echoed. 
2) If I hit ESC, the connection hangs.

We use the same setup we use when connecting to TCP/IP 1.1.3 systems
where we don't have this problem. Also, when telnetting from one SCO
TCP/IP 1.2 box to another, telnet just runs fine, including interpretation
of a DEL character.

Does anybody know what's wrong here?


-- 
Kees Hendrikse                                | email: kees@echelon.uucp
                                              |
ECHELON consultancy and software development  | phone: +31 (0)53 836 585
PO Box 545, 7500AM Enschede, The Netherlands  | fax:   +31 (0)53 337 415

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1993 14:15:01 GMT
From:      julian@math.uni-muenster.de (Julian F. Reschke)
To:        comp.protocols.tcp-ip
Subject:   Help needed: receiving broadcasted UDP packages

Problem: I am trying to receive broadcasted UDP packages. I'm on SunOS 4.1.3,
and use datagram sockets in the internet domain. The port number is 2010 (non-
privileged), and the sender has it's socket configured to allow broadcasts. In
fact, `etherfind' shows that the packets indeed are sent out. However, the
receiver (using revcfrom) doesn't, listening on port 2010, doesn't get them.
When I change to sender not to broadcast, but to send directly to the machine
running the receiver, all works well.

I've looked into SUN's `radio' sources, and all seems to by very similar.
Any help appreciated...




---
________________ cut here _________________________
Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster
  eMail: julian@math.uni-muenster.de, jr@ms.maus.de
________ correct me if I'm wrong __________________


-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 93 14:18:46 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Why would a Sun take 1.5 seconds to retransmit a missed packet?

I am examing some data collected from a medical network, and noticed
some unusual timings.

A Sun is transmitting large files (3.5Mbytes average) to an archive 
system while receiving images from a scanner.

Packets are missed by the archive system, so the Sun has to retransmit
the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
while the sending machine has to "back up" and retransmit packets that
were previously sent but never acknowledged. 35% of the sessions had
inter-packet delays > 1 second.  The receiving buffer size is 24K.

Why would there be such a long delay? I would expect the data is in
mbufs, so the time to resent the missed packets should be small. 
From the timing it looks like the data was occasionally on a disk.
If we wanted to remove these conditions, am I correct in assuming the
sending system needs more RAM or perhaps more buffers?
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 17:00:30 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Netblazer

I currently attach via SLIP over a leased line using v.32bis/v.42bis
modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer.

Would I see any significant increase in throughput using this same
physical connection (v.32bis/v.42bis) but replacing the Dell SLIP
with a Netblazer on my end -- and connecting my machines via ethernet
to the Netblazer?

I assume this would give me the ability to support PPP/CSLIP since
my connection would be Netblazer-Netblazer -- what would PPP buy me
over traditional SLIP (our feed is basically for smtp/nntp traffic,
with ftps,telnets,rlogins used infrequently)..


-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 93 17:59:29 GMT
From:      G.J.Milne@daresbury.ac.uk (g.j.milne)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp: subcommand error codes

In article 160@bjcong.bj.co.uk, maf@bjcong.bj.co.uk (AUSTIN FARR) writes:
>What is the meaning of the 3-digit numbers in messages relating to ftp (on AIX)
>subcommands?  In particular, how is a failure signalled?

You should take a look at RFC959. As well as providing a description of
the FTP protocol it describes the reurn codes in a fair amount of
detail.

I have a feeling that there is an RFC that describes the return codes
only but I can't remember which one.

Ciao!

Gordon

     _/_/_/ _/_/_/ _/_/_/  _/_/_/ Gordon J. Milne
    _/     _/     _/   _/ _/      SERC Daresbury Laboratory, Warrington,
   _/_/_/ _/_/_/ _/_/_/  _/       WA4 4AD.
      _/ _/     _/   _/ _/
 _/_/_/ _/_/_/ _/   _/ _/_/_/     e-mail: g.j.milne@dl.ac.uk

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 18:05:23 GMT
From:      faivre@cst02.segin.com (Denis Faivre)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS SLIP and telnet problem

apollo@buengc.bu.edu (Doug A. Chan) writes:

>What is wrong with telnet?

Good question ! I also have trouble using PC-NFS Telnet...

I recently upgraded my PC-NFS 2.0 to a newer 4.0 version.
Unfortunately, I discovered that Telnet 4.0 is far slower than the older one.
Some pointers in the news enabled me to get the 4.0a patch, but Telnet is
still worse than before.

The machine is a Dell 316SX with 4Mb of RAM, with a 3COM 3C501 Ethernet
adapter.
The hosts are Sun's (4/330, SunOs 4.1.1) and HP's (9000-800, HPUX 8.0).

Note that the hardware did not change from 2.0 to 4.0 .

Telnet is particularly slow when I'm using the vi editor and scrolling into a
file (with the Ctrl-F "page forward" sequence) : sometimes I must wait several
seconds (typically 2 or 3) before the screen is updated.
With Telnet 2.0, the reaction was always immediate.

Knowing that Telnet 4.0 is a brand new implementation, I tried to use the
old one on 4.0 sublayers, but it didn't give good results.

Did somebody experience the problem ?
RTFM did not lead me to a solution.

Denis.


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 18:11:48 GMT
From:      liza@panix.com (Liza Gouger)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP & SNA on IBM Lan adaptor card, availability of virtual term?

Hi, I'm posting this for a friend, Please reply to
alen@crash.cts.com or post here (where he will look).

Alen's request for information...
I have a bunch of 486s running OS/2 connected via an IBM Token Ring
(using a LAN Adaptor card in each). The main node in this net will
be connected to a central machine (via ethernet and TCP/IP). I need
to access terminal sessions on the central machine from any of the 486s.
The central machine is likely to be a VAX w/VMS but may turn out (in some
cases) to be an IBM connected via SNA (LU6.2 capable).

Given these 2 scenarios, can anyone out there in NetLand advise me where
to look for bridging software across the OS/2 (NetBios) -> TCP/IP
VAX and across OS/2 (NetBios) -> SNA?

What kind of hardware requirements are there?

The main interest is in getting live terminal sessions from OS/2
PM windows on each PC node. There is some need for file and/or data
transfer, so leaving these options open would be a plus.

Thanks in advance
--alen (trying to turn a Sparc into a Flame)
alen@crash.cts.com


-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 18:13:56 GMT
From:      mlewis@telebit.com (Mark S. Lewis)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer


> I currently attach via SLIP over a leased line using v.32bis/v.42bis
> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer.
 
> Would I see any significant increase in throughput using this same
> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP
> with a Netblazer on my end -- and connecting my machines via ethernet
> to the Netblazer?
 
> I assume this would give me the ability to support PPP/CSLIP since
> my connection would be Netblazer-Netblazer -- what would PPP buy me
> over traditional SLIP (our feed is basically for smtp/nntp traffic,
> with ftps,telnets,rlogins used infrequently)..


> -- 
> Larry Snyder                                    internet: larry@gator.rn.com
> keeper of the Gator                                  uucp: uunet!gator!larry

No I don't think you would get a significant performance increase by
putting a NetBlazer at both ends.  You are using relatively slow
serial lines limited by V.32bis modulation with whatever compression
you get with V.42bis.

You would get significant performance increase for telnet sessions
using TCP header compression.  This won't help UDP traffic of course.
This compression can be used with SLIP (CSLIP) or PPP.  Many PPP
implementations include header compression.

The main benefits of PPP are dynamic configurability and the ability
to run multiple protocols.  PPP negotiates things like header
compression, MRU/MTU size while trying to bring the link up.  With
SLIP all this must be statically configured ahead of time.

PPP has specifications for protocols other than IP.  People run IPX,
AppleTalk, XNS, Decnet, OSI, and bridging over PPP links.  SLIP is
only useful for IP.

... Mark

=========-----------          Mark S. Lewis      -----------==========
inet: mlewis@telebit.com      Telebit Corp.     Telebit (408) 745-3232
uucp: uunet!telebit!mlewis                          Fax (408) 745-3810

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 93 19:21:57 GMT
From:      larry@eco.twg.com (Lawrence B. Henry III)
To:        comp.unix.aix,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: ftp: subcommand error codes


In article <160@bjcong.bj.co.uk>, maf@bjcong.bj.co.uk (AUSTIN FARR) writes:
|>
|>ftp on AIX: subcommand errors
|>-----------------------------
|>
|>What is the meaning of the 3-digit numbers in messages relating to ftp (on AIX)
|>subcommands?  In particular, how is a failure signalled?
|>
|>The following is an extract from an ftp dialogue:
|>ftp> get absent
|>200 PORT command successful
|>550 absent: No such file or directory
|>ftp> cd tmp
|>250 CWD command successful
|>
|>The leading 3-digit numbers in messages from ftp appear to relate to
|>interactions with the remote machine.  A number beginning with '5' appears to
|>signify failure of the operation.  If the last message before the 'ftp>' prompt begins with a digit other than '5' - is this a sufficient test for successful
|>completion of the last subcommand?
|>
|>I would be grateful for further information.  Please reply by email.
|>Thank you.
|>

Austin,
	Check out rfc640.. I believe that this is the latest source of 
information on this topic.. it is readily available from nic.ddn.mil in the
RFC sub-directory..

-Larry.


---Excerpt from RFC640 showing response codes for FTP---

       There are four values for the first digit of the reply code:      11a

       1yz   Positive Preliminary reply                                  11b

          The requested action is being initiated; expect another
          reply before proceeding with a new command.  (The
          user-process sending another command before the  completion
          reply would be in violation of protocol; but server-FTP
          processes should queue any commands that arrive while a
          preceeding command is in progress.)  This type of reply can
          be used to indicate that the command was accepted and the
          user-process may now pay attention to the data connections,
          for implementations where simultaneous monitoring is
          difficult.                                                    11b1

       2yz   Positive Completion reply                                   11c

          The requested action has been successfully completed.  A
          new request may be initiated.                                 11c1

       3yz   Positive Intermediate reply                                 11d

          The command has been accepted, but the requested action is
          being held in abeyance, pending receipt of further
          information.  The user should send another command
          specifying this information.  This reply is used in command
          sequence groups.                                              11d1

       4yz   Transient Negative Completion reply                         11e

          The command was not accepted and the requested action did
          not take place, but the error condition is temporary and
          the action may be requested again.  The user should return
          to the beginning of the command sequence, if any.  It is
          difficult to assign a meaning to "transient", particularly
          when two distinct sites (Server and User-processes) have to
          agree on the interpretation.  Each reply in the 4yz
          category might have a slightly different time value, but
          the intent is that the user-process is encouraged to try
          again.  A rule of thumb in determining if a reply fits into
          the 4yz or the 5yz (Permanent Negative) category is that
          replies are 4yz if the commands can be repeated without any
          change in command form or in properties of the User or
          Server (e.g. the command is spelled the same with the same

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [5]



          arguments used; the user does not change his file access or
          user name; the server does not put up a new
          implementation.)                                              11e1

       5yz   Permanent Negative Completion reply                         11f

          The command was not accepted and the requested action did
          not take place.  The User-process is discouraged from
          repeating the exact request (in the same sequence).  Even
          some "permanent" error conditions can be corrected, so the
          human user may want to direct his User-process to
          reinitiate the command sequence by direct action at some
          point in the future (e.g. after the spelling has been
          changed, or the user has altered his directory status.)       11f1

       The following function groupings are encoded in the second
       digit:                                                            11g

          x0z   Syntax - These replies refer to syntax errors,
                  syntactically correct  commands that don't fit any
                  functional category, unimplemented or superfluous
                  commands.                                             11g1

          x1z   Information -  These are replies to requests for
                  information, such as status or help.                  11g2

          x2z   Connections - Replies referring to the TELNET and
                  data connections.                                     11g3

          x3z   Authentication and accounting - Replies for the logon
                  process and accounting procedures.                    11g4

          x4z   Unspecified as yet                                      11g5

          x5z   File system - These replies indicate the status of
                  the Server file system vis-a-vis the requested
                  transfer or other file system action.                 11g6

       The third digit gives a finer gradation of meaning in each of
       the function categories, specified by the second digit.  The
       list of replies below will illustrate this.  Note that the
       text associated with each reply is suggestive, rather than
       mandatory, and may even change according to the command with
       which it is associated.  The reply codes, on the other hand,
       should strictly follow the specifications in the last section;
       that is, Server implementations should not invent new codes
       for situations that are only slightly different from the ones
       described here, but rather should adapt codes already defined.

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [6]



       If additional codes are found to be necessary, the details
       should be submitted to the FTP committee, through Jon Postel.     11h
                                                                             

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 19:34:48 GMT
From:      fredh@bohr.logiconultra.com (Fred Hronicek)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Software for VAX 8700



Does anyone know of what TCP/IP software is available for the VAX 8700?
(Vendor name, approximate cost, etc) 

Shareware would be nice.

Fred Hronicek
Logicon Ultrasystems, Inc.
310/643-5111

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 20:10:08 GMT
From:      ben@csi.compuserve.com (Benny Jones)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Tops-10

Back in the medieval days of computing, did TCP/IP ever run on a
TOPS-10 system?  I'd be very interested in knowing who did it or
any names of individuals that I might contact with questions about
the implementation.  Thanks loads.

-- 
Benny Jones		614-457-8600
CompuServe 		70003,1153
Internet		ben@csi.compuserve.com
			hjones@magnus.acs.ohio-state.edu

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 93 20:34:04 GMT
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?

In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>I am examing some data collected from a medical network, and noticed
>some unusual timings.
>
>A Sun is transmitting large files (3.5Mbytes average) to an archive 
>system while receiving images from a scanner.

   Transmitting using what protocol?   FTP, NFS copy or what?

>
>Packets are missed by the archive system, so the Sun has to retransmit
>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)

   Those are pretty typical numbers for TCP layer time-outs...

>
>Why would there be such a long delay? I would expect the data is in
>mbufs, so the time to resent the missed packets should be small. 
>From the timing it looks like the data was occasionally on a disk.
>If we wanted to remove these conditions, am I correct in assuming the
>sending system needs more RAM or perhaps more buffers?
  
  If this is FTP, you'd probably be better off getting rid of the
  fatal collisions on the net.....unless you can set the time-outs
  to a very small number (very dangerous, but....)


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 1993 20:45:11 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   SLIP connections and ifconfig/netstat/route problems

my netstat -rn shows (after a re-boot):

Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      0          lo0
192.207.21.3         192.207.21.3         UH       0      0          sl0
192.207.21.3         192.207.21.3         UH       0      0          sl0
default              192.207.21.3         UG       5      1366       sl0
192.190.77           192.190.77.1         U        0      0          eth0

I bring the machine up with:

cp /etc/inet/resolv.conf.orig /etc/inet/resolv.conf
/usr/sbin/slipattach /dev/term/b01s 192.207.21.195 netblazer-ip 38400
/usr/sbin/ifconfig "sl0" gator netblazer-ip netmask 255.255.255.0 up
cp /etc/inet/resolv.conf.conf /etc/inet/resolv.conf
/usr/sbin/in.named
/usr/sbin/route add default netblazer-ip 1

Now, if I don't add the above ifconfig line, route fails with
"network is unreachable" on the above route command.  I need
to add the ifconfig line in order for the route add default....
to take effect.

Any ideas why I need to specify another ifconfig (besides the
default that comes up enabled with slip)?

larry

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 93 22:46:37 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0I42H.23D@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>Since the serial ports in the netblazer are on the motherboard, is it
>possible to disable them and add a stock 2 port serial board with
>16550A chips and will the NB take advantage of the FIDO buffers in
>the chips?
>
>Can the NB support 2 56700 baud modems going full blast on the
>stock 2 serial ports on the motherboard?

try pulling the case off and seeing of the UARTs are 16550's.

i would suspect so.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416-506-0654 ]
[                      longer life through colder blood                       ]

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 93 23:11:46 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   tftp for MVS



Is there available on the internet a C ported version 
of the TFTP protocol for the MVS mainframes ?

Thanks,

Maritza

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 00:22:57 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

merce@xenitec.on.ca (Jim Mercer) writes:

>>Can the NB support 2 56700 baud modems going full blast on the
>>stock 2 serial ports on the motherboard?
 
>try pulling the case off and seeing of the UARTs are 16550's.
 
>i would suspect so.

but does their code use the FIFO in the 550A if installed in a slot?

-- 
Larry Snyder                                    internet: larry@gator.use.com
keeper of the Gator                                   uucp: uunet!gator!larry

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 00:26:33 GMT
From:      black@ll.mit.edu (Jerry Glomph Black)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Packet Driver or PCROUTE on PC-synch card NEEDED!

I need to upgrade my Slip service to operate on a 56kB leased DDS line,
for which my CSU/DSU operates synchronously.  

Is there a PCROute driver, or a packet driver, which can talk to a PC
card which does synchronous serial?  

email to black@LL.MIT.EDU   Thanks!

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 00:37:08 GMT
From:      bhays@teal.csn.org (Boyd Hays)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   SLIP on a SUN?

Hello,
    I need to put SLIP up on a SUN IPC running 4.1.2. Is there a general
    concensus as to which version is "best". I'm anticipating putting up
    cslip-2.6. Is this good, bad, or indifferent. Also, I keep reading in
    most documents associated with the various SLIP verions not to have
    a getty on the serial line. I'm confused. What I want to do is:

    1) Hang a getty on the receiving modem's port.
    2) Make the connection over a phone line.
    3) Login to a account that runs sliplogin or the equivalent.
       (I don't have sanction to run slattach on the host machine)

    Is this the general process? Is there a FAQ for SLIP installations?
    The best thing I've found so far is the O'Rielly TCP/IP Administration
    book's description. Are there any other "standard" references?

Thanks in advance,
Boyd Hays
bhays@csn.org


-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 02:26:41 GMT
From:      hak@alf.cooper.edu (Jeff Hakner)
To:        comp.protocols.tcp-ip
Subject:   Re: STARLAN 10 10BASE-T hub unit doesn't like adapters

in article <Jan.4.19.20.49.1993.958@ocean.rutgers.edu>, jimg@ocean.rutgers.edu (Jim Gasprich) says:
> 
> I have two somewhat old (circa 1988) STARLAN 10 hub units that 
> are part of our TCP/IP ethernet LAN. Our lab is wired twisted pair
> with RJ-45 plugs. This is fine for our PCs with their RJ-45 port 
> cards, but for our UNIX boxes (Suns), we need to use AUI to RJ-45
> adapter boxes.
> 
> Here's the problem. We recently bought a new (1991) adapter box from
> Cabletron, but it did not work when we wired it up. We have a few 
> old adapters from AT&T (which came with our now defunct 3B2s (ick!)),
> and some others from a company called David Systems, which work A-OK.
> 
> I am somewhat perplexed. Has there been a change in the 802.3 standard,
> are our hub units no longer usuable, or am I just missing something
> somewhere ?? It would seem a shame to throw out 22 usuable ports, 
> especially with the price of some of the new fancy-pants hubs I've
> been looking at.
> 
> I apologize if these are newbie questions, or are more appropriate to
> another, more wire-head hardware group.
> 
> Thanks,
> 
> Jim Gasprich                          e-mail: jimg@ocean.rutgers.edu
> Research & Support Slave                tel:    (908) 932-9631
> Cook College Remote Sensing Center      fax:    (908) 932-8644
> Dept of Natural Resources
> Rutgers University
> New Brunswick, NJ, O8903        "Du bist mein Gweckman" - Anonymous Fascist

I've had a similar problem.  When I used the Allied Telesis thick-10BASE-T
adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the
whole network starting dying with heavy collisions (and no traffic!).
WHen I replaced the hub with an Allied hub (more modern), no problems.
I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps
there are some subtel differences which prevent this interoperation?


--Jeff Hakner
Asst. Dir. Telecommunications
Cooper Union
NYC


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jan 93 03:48:26 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver or PCROUTE on PC-synch card NEEDED!

In article <1993Jan8.002633.24525@ll.mit.edu> black@ll.mit.edu writes:

   I need to upgrade my Slip service to operate on a 56kB leased DDS line,
   for which my CSU/DSU operates synchronously.

   Is there a PCROute driver, or a packet driver, which can talk to a PC
   card which does synchronous serial?  

Ask Niwot Networks.  They sell ISA sync cards that have packet drivers.
They're at 303-444-7765.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 06:11:02 GMT
From:      lin@tasman.cc.utas.edu.au ()
To:        comp.protocols.tcp-ip
Subject:   How to network printers?


Hi netlanders,

I don't know whether this is right place to ask this question.  But, anyway,...

Our group has more than 10 PCs, one Dataproducts LZR-1260 b/w laser printer,
one HP Deskjet 500C color printer and one HP Scanjet IIp b/w scaner.
At moment, the printers and scanner are not networked, even though our
PCs are networked through ethnet to a Unix server.

We now want our printers and scanner to be networked as well.  What do we need?
Hardware, software?  Someone mentioned FASTPORT (TCP/IP network print server)
by MiLAN Technology should be OK for our purpose.  Is that right?
Any other options?

Your help would be greatly appreciated.

Please send responses to my account since I don't read this newsgroup very often.

I will post a summary if there are enough responses and interests.

Thanks in advance.


--Tony Lim

Internet:   lin@tasman.utas.edu.au
	    zzl@bom.gov.au


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 06:38:15 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.unix.sys5.r4,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0IEE9.M4I@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>merce@xenitec.on.ca (Jim Mercer) writes:
>
>>>Can the NB support 2 56700 baud modems going full blast on the
>>>stock 2 serial ports on the motherboard?
 
>>try pulling the case off and seeing of the UARTs are 16550's.
 
>>i would suspect so.
>
>but does their code use the FIFO in the 550A if installed in a slot?

ka9q has had support for the 550 for some time.

i once asked Phil Karn if the rumor was true that the Netblazer kernel
was based on ka9q.

his responded something like "a much mutated version".

if the motherboard has 550's on it, it would be rediculous(sp?) for
telebit not to support them, especialy if the support was in the
base code.

8^)

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416-506-0654 ]
[                      longer life through colder blood                       ]

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jan 1993 12:48:46
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?

In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

    In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:

    >Packets are missed by the archive system, so the Sun has to retransmit
    >the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
    
       Those are pretty typical numbers for TCP layer time-outs...

If so, it indicates that 1) the path is long, 2) the archive system is very
slow or 3) the sending TCP has an inferior or broken adaptive retransmit
algorithm.  TCP should retransmit in something on the order of twice the
average Round Trip Time (from send to ack).  Some implementations use exactly
2X, others combine the RTT and its standard deviation.  With the TCP in PC/TCP
for DOS on a local LAN, the retransmit timeout is typically near its floor of
166 Ms, and I don't see any significant number of unwarranted retransmits.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 08:16:44 GMT
From:      tbooth@netcom.com (Todd Booth)
To:        comp.dcom.cell-relay,comp.dcom.lans.novell,comp.protocols.tcp-ip
Subject:   RESULT: comp.dcom.sys.wellfleet pass 122:14

Happy new year!

At the end of the voting period (midnight GMT, Tuesday, January 5th,
1993), 136 people had sent in their ballots in response to the CFV.

First let me say that this message has been posted to:
	news.announce.newgroups
	comp.dcom.lans.ethernet
	comp.dcom.lans.fddi
	comp.dcom.lans.misc
	comp.dcom.lans
	comp.dcom.cell-relay
	comp.dcom.lans.novell
	Wellfleet email distribution list (wellfleet-l@nstn.ns.ca)

The mailing list will remain, and those who prefer to receive by
mail, can continue to do so.  

Here are the results:

Summary of vote tally:

	yes:   122
	no:     14
	total: 136
 
Vote test 1: There were over 100 more valid yes votes than no.

Vote test 2: There were over 2/3 of the total (136) in favor.

There will be a five day waiting period during which the net
will have a chance to correct any errors in the voter list or 
the voting procedure.

After the waiting period and if there were no serious objections
that might invalidate the vote, the newgroup will be created.

--todd booth 

Wellfleet Communications, Inc. ; 310 445-8840
Systems Engineer in Los Angeles today
Stockholm next month (still with WF, still tbooth@wellfleet.com)

********

email addresses for those in favor of comp.dcom.sys.wellfleet: 

Vote: From:
yes   A.AGNEW@qut.edu.au
yes   stortek!Aaron_Dailey@csn.org (Aaron Dailey)
yes   "Alain FONTAINE (Post master - UCL)" <fontaine@sri.ucl.ac.be>
yes   nothaft@nas.nasa.gov (Alfred E. Nothaft)
yes   Andries Ruiter <RUITER@RC.RUG.NL>
yes   Andy Linton <Andy.Linton@comp.vuw.ac.nz>
yes   Andy Malis <malis@BBN.COM>
yes   Armand Giraud <agiraud@itb1s1.grenoble.hp.com>
yes   Arne Langmo <Arne.Langmo@runit.sintef.no>
yes   art@brick.purchase.edu (Art Weisenseel)
yes   ashah@eos.ncsu.edu
yes   B.J.  10-Dec-1992 1357 <herbison@erlang.enet.dec.com>
yes   b.watson%uws.edu.au@tscc.macarthur.uws.EDU.AU
yes   Barry Lynam <LYNAM@qut.edu.au>
yes   rlfink@net.lbl.gov (Bob Fink)
yes   rhott%galaxy@relay.nswc.navy.mil (Bob Hott - K31)
yes   cdperry@attmail.com
yes   ccganzhorn@mmm.com ("Charles Ganzhorn")
yes   chinson@CS.UCLA.EDU
yes   mack23@avalon.eecs.nwu.edu (Chris Walsh)
yes   claude@banana.dis.fedex.com (claude bowie)
yes   Colin Cooper <colin@udcf.gla.ac.uk>
yes   abbott@MicroUnity.com (Curtis Abbott)
yes   D.REES@qut.edu.au
yes   "D.W.Stevenson" <craa85@computer-centre-sun.strathclyde.ac.uk>
yes   dan@lannet.com (Dan Romascanu)
yes   carr@acsu.buffalo.edu (Dave Carr)
yes   Dave Geurs <dgeurs@mot.com>
yes   Dave Pokorney <POKE@nervm.nerdc.ufl.edu>
yes   David Kuzminski <kuzminsk@cs.unc.edu>
yes   levine@berlioz.nsc.com (David LeVine)
yes   dcarros@rcsuna.gmr.com (Donald Carros )
yes   Don_Jarmon@ingr.com
yes   "Ekkehard Lang"  <A2824AA@lrz1.lrz-muenchen.de>
yes   Eric Hunt <bsc835!ehunt@uunet.UU.NET>
yes   Evan Gamblin <0001847804@mcimail.com>
yes   emss!geboykin@uunet.UU.NET (G. E. Boykin     x5522        )
yes   Gary Kunis <gkunis@cisco.com>
yes   skaggs@nsslsun.nssl.uoknor.edu (Gary Skaggs)
yes   Gavin Stone-Tolcher <ccgavin@cc.uq.oz.au>
yes   gordonr@nms.otca.oz.au (Gordon Rowell)
yes   Greg Sawyers <g.sawyers@trl.oz.au>
yes   Hampton Watkins <hwatkins@BBN.COM>
yes   hand@tbird.cc.bellcore.com (hand,james c)
yes   Hiroyasu Murakoshi <mrks@edp.tis.toshiba.co.jp>
yes   HJOLLO@BG.HBG.HYDRO.NO
yes   takumi@ai03.ics.nitech.ac.jp (Ichi Takumi)
yes   Jack Allen Underwood <Jack.A.Underwood@med.umich.edu>
yes   Jason R. Pascucci <jasonp@primerd.prime.com>
yes   barnes@xylogics.com (Jim Barnes)
yes   Jim O'Shea <jwo@hpuerca.atl.hp.com>
yes   jim@unirsvl.RSVL.UNISYS.COM
yes   John Burgess <jtb@garage.att.com>
yes   John Curran <jcurran@nic.near.net>
yes   lekash@nas.nasa.gov (John Lekashman)
yes   jmills@cass.ma02.bull.com (John Luke Mills)
yes   jsblau@panix.com (Jonathan Blau)
yes   jude@wk87.nas.nasa.gov (Jude George)
yes   Katy Kislitzin <ktk@nas.nasa.gov>
yes   Ken Hays <hays@dirac.scri.fsu.edu>
yes   Ken Tobias <ktobias@amgen.com>
yes   kent@unlinfo.unl.edu (kent eitzmann )
yes   smiles@NMC.ED.RAY.COM (Kevin Ruddy)
yes   Kirk Olsen <kgo@sununix.comm.wang.com>
yes   Larry Rebarchik <lrebarch@us.oracle.com>
yes   infmise@grds01.deinf.abb.com (M.Scheurer)
yes   marcel@irdeto.nl (Marcel Koelewijn)
yes   Marciano Pitargue <pitargue@cisco.com>
yes   "Marian Gawel, ESC Data Network Operations" <gawel@bb.dec.com>
yes   Mark Garrett <mark@arvak.une.edu.au>
yes   "Mark I. Williams" <M.Williams@cc.uq.oz.au>
yes   mast@maldata.se (Martin Stromberg)
yes   mborden@wellfleet.com (Marty Borden)
yes   matsuo@mars.elcom.nitech.ac.jp
yes   mmt@RedBrick.COM (Maxime Taksar KC6ZPS)
yes   Michael A Wojcik <woj@ll.mit.edu>
yes   Michael Quinn <MJQUINN@pucc.Princeton.EDU>
yes   "Michael S. McMahon"  <MCMAHON@unocdc.unomaha.edu>
yes   mgh@sunbim.be (Michel Hendrick)
yes   "Michelle R. Koblas" <Michelle.Koblas@itek.norut.no>
yes   mac@critter.Prime.COM (Mike Croke x5386 )
yes   Mike Scott <mjtt@tonto.cc.rochester.edu>
yes   mike@Cadence.COM (Mike Tucker)
yes   mustang@iastate.edu
yes   nick@beethoven.wellfleet.com (Nicholas Jacobs)
yes   bg54305@bgsau3.hbg.hydro.no (Ola Hjollo)
yes   Patrick Herlihy <P.Herlihy@ccsd.uts.EDU.AU>
yes   pwk@telecomm2.iss.bnr.com (Paul Killion)
yes   schow@sun1.InterLan.COM (Peter Schow)
yes   PETER@zeus.ed.ray.com
yes   proyse@peeras.demon.co.uk (Phil Royse)
yes   ptrubey (Phil Trubey)
yes   Philippe Debroux <Debroux@sri.ucl.ac.be>
yes   Philippe Francq <Francq@sri.ucl.ac.be>
yes   michel@thomson-lcr.fr (Philippe Michel)
yes   pm@sunbim.be (Philippe Moitroux)
yes   pstevens@BBN.COM
yes   rjmeye1@afterlife.ncsc.mil (Randy Meyers)
yes   rfranken@cs.umr.edu
yes   Ritu Bansal <rbansal@cc3.bbn.com>
yes   rcraig@cisco.com (Robert Craig)
yes   "Robert S. Logan" <BOB@ROMEO.CALTECH.EDU>
yes   sameer@atlastele.com
yes   scod@ewi.ch (Schorr Daniel)
yes   scott@Nova.TCS.Tufts.EDU
yes   simha@lannet.com (Simha Karlin)
yes   Stephen Sakamoto <steph@CS.UCLA.EDU>
yes   sbauer@silver.sdsmt.edu (Steve Bauer)
yes   Steve Elias <eli@cisco.com>
yes   "Steven Lendt - UNOnet Manager"  <SLENDT@unocdc.unomaha.edu>
yes   Terry Gong <thg@hprnd.rose.hp.com>
yes   thomasb%kestrel.AUSTIN.LOCKHEED.COM@AUSTIN.LOCKHEED.COM (Thomas Benjamin)
yes   a2824ak@sunmanager.lrz-muenchen.de (Thomas Kaiser)
yes   Tim Pletcher <Timothy.A.Pletcher@med.umich.edu>
yes   Todd Booth <tbooth@wellfleet.com>
yes   tj@CS.UCLA.EDU (Tom Johnson)
yes   Tony Knaus <awk@antlia.ece.cmu.edu>
yes   trall@almaden.ibm.com
yes   T  elogy.Networks@uu2.psi.com, Inc. <billw@telogy.com>
yes   Val Freda <rxtvf@possum.ecg.rmit.edu.au>
yes   Vesa Halkka <vhalkka@cc.helsinki.fi>
yes   cire "ya mon" eric <cire@cisco.com>

********

email addresses for those against comp.dcom.sys.wellfleet: 

Vote: From:
no    Adrian Miranda <ade@vancouver.wsu.edu>
no    Charles Shub <cdash@moet.cs.colorado.edu>
no    mcp@netcom.com (Craig Presnell)
no    emcguire@intellection.com (Ed McGuire)
no    grima@iphase.com (Gary Rima)
no    gator@vnet.ibm.com
no    ggw@wolves.Durham.NC.US (Gregory G. Woodbury)
no    gulik@motcid.rtsg.mot.com (Gregory Gulik)
no    Marc Moorcroft <smarry@zooid.guild.org>
no    pseudo!mjn@uunet.UU.NET (Murray Nesbitt)
no    rens@lorax.shearson.com (Rens Troost)
no    rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller)
no    "Roy Engehausen" <enge@almaden.ibm.com>
no    tom_limoncelli@Warren.MENTORG.COM

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 13:06:54 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   FTP ABOR vs data channel reset?

Hello Net

I would value information on ways to abort or terminate an FTP sessions
data channel.  According to the spec the suggested (required?) way is to
issue an ABOR command on the control channel. However I haven't yet found
any type of machine that takes any notice of this.  They all seem to finsh
the transmission and then say something like ABOR command successful.
Obviously this is kinda pointless - or am I just doing it wrong some how.

The other method is to reset the data channel. This works just fine but some
machines (SRV? unix) also shut the control channel (hence logging you out) at
the same time. This is kinda annoying.

So can anybody tell me if they have observed this as well - ( my software is
home grown so I can't really be too sure it isn't my fault). Any suggestions on
alternate methods?, anyone know of any catastrophic problems with the reset 
method (besides the one mentioned?). 

All info appreciated.

                                                  Dale Edgar
                                                  Cybernetic Control Inc.
                                                  DEDGAR@MTA.CA


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 13:47:02 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <1993Jan07.224637.4538@xenitec.on.ca> merce@xenitec.on.ca (Jim Mercer) writes:
>In article <C0I42H.23D@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>>Since the serial ports in the netblazer are on the motherboard, is it
>>possible to disable them and add a stock 2 port serial board with
>>16550A chips and will the NB take advantage of the FIDO buffers in
>>the chips?
>>
>>Can the NB support 2 56700 baud modems going full blast on the
>>stock 2 serial ports on the motherboard?
>
>try pulling the case off and seeing of the UARTs are 16550's.
>
>i would suspect so.

They certainly are.  (I have examined lots of these)

They wouldn't work at that speed if they weren't.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900]

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 14:23:23 GMT
From:      jh@cadre.com (Joe Hartley)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: SLIP on a SUN?

In article EAC@csn.org, bhays@teal.csn.org (Boyd Hays) writes:
>Hello,
>    I need to put SLIP up on a SUN IPC running 4.1.2. Is there a general
>    concensus as to which version is "best". I'm anticipating putting up
>    cslip-2.6. 

I'm currently looking at setting up a SLIP connection as well.  I got a
version of cslip off the net, although it was not the latest version.  It
had almost nothing in the way of documentation, and I didn't get it to
install properly.  I then tried a copy of MorningStar's PPP with cslip
that we had in-house.  It installed fairly easily, and seems to work fine.
I'm going to get the new cslip today, but if it's as cryptic as the old one,
MorningStar's going to have a new customer.

---
===============================================================================
Joe Hartley          | jh@cadre.com  -  Whenever you find that you are on the
Cadre Technologies   | side of the majority, it is time to reform. - M. Twain
222 Richmond St.     | --------------------------------------------------------
Providence, RI 02903 | Overman 1st Class - the Kilgore Trout Memorial Clench
(401) 351-5950 x266  |            of the Church of the SubGenius  
===============================================================================

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 15:43:32 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

karl@ddsw1.mcs.com (Karl Denninger) writes:

>>>Can the NB support 2 56700 baud modems going full blast on the
>>>stock 2 serial ports on the motherboard?
>>
>>try pulling the case off and seeing of the UARTs are 16550's.
>>
>>i would suspect so.
 
>They certainly are.  (I have examined lots of these)

So one can assume they support the FIFO to get those speeds.

My next question is do you have to enable a specific protocol --
ie: Can I start talking to the NB with SLIP using VJ compression
and will it start using VJ - likewise, can I connect using PPP
and will the netblazer be smart enough to change?

-- 
Larry Snyder                                    internet: larry@gator.use.com
keeper of the Gator                                   uucp: uunet!gator!larry

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 15:46:18 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

Would VJ compression with SLIP be benificial even if you
have hardware compression (v.42bis?).  If so, how much?

Just wondering --


-- 
Larry Snyder                                    internet: larry@gator.use.com
keeper of the Gator                                   uucp: uunet!gator!larry

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 15:50:33 GMT
From:      sailesh@litsun.epfl.ch (Sailesh Chutani)
To:        comp.protocols.tcp-ip
Subject:   question - performance and fault management in networks

Greetings

I am trying to identify the problems that are considered to be the key
problems in the area of Network Management, going beyond those solved by CMIP, DME,
and SNMP etc.  In particular I am focusing attention on fault and
performance management issues at the transport layer. I would 
like to hear from people who are working in the related areas
or have some experience and/or ideas on the topic that they would like to
share.

The problems of interest for example, could be related to :
	- abstractions used to describe the system
	- protocol design, specification, and validation techniques
	- modelling and statistical techniques
	- framework for dealing with incomplete and erroneous information
	  on problems
	- gathering and analyis of problem related data
	- automation of detection and recovery
	- design of suitable interfaces to aid discovery, diagnosis and
	  recovery

I would prefer any feedback via e-mail. I shall post a summary
of the information thus collected.

Thanks for your help.

-Sailesh

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 15:57:32 GMT
From:      davidsen@ariel.crd.GE.COM (william E Davidsen)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0I42H.23D@news.rn.com>, larry@news.rn.com (Larry Snyder) writes:

| Can the NB support 2 56700 baud modems going full blast on the
| stock 2 serial ports on the motherboard?

Answer 1: probably, if they're com1 and com2
Answer 2: who cares, use SAS

I have a copy of SAS I got from Dell, and a copy of ESIX ppp I'm going
to try this weekend. I'll let you know how they work!
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 16:22:43 GMT
From:      fisher@tinton.ccur.com (Greg Fisher)
To:        comp.protocols.tcp-ip
Subject:   Trivial Telnet?

I was working with a unix kernel the other day whose TCP protocol was
"sick", so I could not telnet or ftp to the system.  But udp & ip were fine;
ping and tftp had no problems.

So I just wondered if anyone knows of a telnet-like thing which uses udp
(or even raw IP?) so that you can log in and poke around even when half
of the protocol stack has gone South?

(I realize that some packets may be lost, but I don't think that matters
very much in this kind of situation).

Comments?

-- 

Greg Fisher @ fisher.tinton.ccur.com


-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 16:33:58 GMT
From:      gmarzot@mitre.org (G. S. Marzot)
To:        comp.protocols.tcp-ip
Subject:   Round Trip Time(RTT) and FTP

Here are some interesting issues that I have been having trouble nailing
down concerning the behavior of TCP, and FTP on top of TCP in particular. I
am on a Sun SPARC 2 SunOS 4.1.2

When FTP begins a file transfer, assuming the connection has already been
established, it makes another connection to host1.ftp-data, negotiates MSS
and window sizes(in my case mss=1460 and window=24576) and then starts
transferring data. The question is - does the second connection use the RTT
calculated when the FTP session was brought up or must it recalculate it
anew?  

What is the initial guess at RTT(and corresponding RXMIT timer) for a new
TCP connection?

Can this be changed? by FTP? in the kernel?

Is there a way to monitor/log the progress of the RTT calculations for a
particular connection?

Does Sun's implementation of TCP use adaptive window slow start algoritms?

I have seen FTP sessions negotiate different maximum segment sizes(mss) for
different connections - what are the issues driving the selection of an mss
and can this be controlled by the user?

Thank you very much in advance for any light shed.

-GSM

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 16:37:18 GMT
From:      pozar@kumr.lns.com (Tim Pozar)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

mlewis@telebit.com (Mark S. Lewis) writes:
>> I currently attach via SLIP over a leased line using v.32bis/v.42bis
>> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer.
 
>> Would I see any significant increase in throughput using this same
>> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP
>> with a Netblazer on my end -- and connecting my machines via ethernet
>> to the Netblazer?
>> [...] 
>> Larry Snyder                                    internet: larry@gator.rn.com
>
>No I don't think you would get a significant performance increase by
>putting a NetBlazer at both ends.  You are using relatively slow
>serial lines limited by V.32bis modulation with whatever compression
>you get with V.42bis.
>
>Mark S. Lewis  inet: mlewis@telebit.com  

I disagree.  I think you will get some increase in preformance, depending 
on how loaded your box that is doing the routing is.  Routing IP packets 
takes a certain amount of CPU over head as well as servicing the serial 
line interupts that happen every time you get a packet in.  Using 16500 
helps.

BTW there are other soultions to netblazers...

We have been playing with a number of router soulutions for our coopertive 
network, "The Little Garden".  Currently we are running KA9Q/NOS for our 
dial-up routers.  The other day I brought up 386BSD as a router and found 
that ping times went down by about 10 to 20%.  With a '386DX-16 running 
KA9Q tied via v.32bis/v.42bis Forval modems to a '386SX-25 runing KA9Q 
our 56byte ping times were about 200 to 240mS on an unloaded circuit.  
With 386BSD on just one side the ping times were about 190 to 210 mS.  
Same hardware, just one side had different router software.

After experimenting with 386BSD a bit, I am going to put more of an effort 
into getting something ship shape to run off a floppy and try to replace 
a couple of our links with it.

A side note.  Netblazer software was based on the KA9Q software.  Enough 
work has gone into it by now that I imagine that it doesn't look like KA9Q 
any more, but I wonder if it still has the same problems that KA9Q has, 
like memory leakage and high latency. Perhaps Mark could comment on the
Netblazer software.

Our cost per KA9Q box is about $600 as it is only a fast '386 mother
board with 1Meg of memory, 1.4 meg floppy drive and controller, case/power 
supply, keyboard, ethercard(SMC), 16550 stuffed async card, monitor and 
video card.  

Phil Karn asks for about $50 for commercial installation of the KA9Q 
software.  386BSD is currently availible for free off of the net from 
agate.berkeley.edu.  Bill Joliz does ask for a contribuition of $50 for 
the binaries and $100 for the source.

At the last ONEBBS con in Denver, there was a demonstration of a device 
called "Slip-on-a-Stick".  It was a box that was about 10"x6"x2" tall, and 
would do slip.  I don't know if it will do the right thing with subnetting
as I only saw it work with one device on it.  The price was less than a
grand.

                            Tim

-- 
    Internet: pozar@kumr.lns.com     FidoNet: Tim Pozar @ 1:125/555
Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
                        Voice: +1 415 788 2022

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 16:39:58 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Tops-10

According to Jerry Burchfiel, who was there at the time: "Bill Plummer
and Ray Tomlinson of BBN first implemented TCP/IP on TENEX.  Thanks to
Charles Lynn, also of BBN, it was later ported onto TOPS-20.  I think it
skipped over TOPS-10."

Alex McKenzie
BBN 
 

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1993 16:59:38 GMT
From:      kby@cco.caltech.edu (Kimo B. Yap)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Tops-10

As I mentioned to the original author (but didn't bother to post) I believe
there was a hack version of TCP/IP for the -10, but I think it was last
known to work in about 6.02.  I don't remember who did it and will have to
do some digging (I know the chain, but the end is kind of buried).-kby

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 17:07:48 GMT
From:      chuck@npdiss1.StPaul.NCR.COM (Charles Rissmeyer)
To:        comp.protocols.tcp-ip
Subject:   Re: STARLAN 10 10BASE-T hub unit doesn't like adapters

In article <1993Jan8.022641.27932@alf.cooper.edu> hak@alf.cooper.edu (Jeff Hakner) writes:

>I've had a similar problem.  When I used the Allied Telesis thick-10BASE-T
>adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the
>whole network starting dying with heavy collisions (and no traffic!).
>WHen I replaced the hub with an Allied hub (more modern), no problems.
>I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps

I'm not very familiar with the details of STARLAN10 hubs. The newer ones
are 10BaseT compatible. It sounds like you might have a problem with the
link-beat , sometimes called link integrity, or
heartbeat.  Basically, if you have link-beat on at the hub, you need it on
at the workstation's transceiver.  If your hub doesn't support link-beat, then
you must turn it off at the terminal too.  

One more thing I just thought of, I believe some Allied Telesis transceivers
do not have the ablility to turn off link-beat.  This means you must have
it on at the hub.

Good luck,

Charles (Chuck) Rissmeyer    KE0VG
(612) 638-7669  (VP 652-7669) -  charles.rissmeyer@StPaul.NCR.COM
NCR - An AT&T Company             NCR  CCS-PM&S NPD St. Paul

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 17:20:41 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   VJ compression (Re: Netblazer)

In article <C0JL58.HqK@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
   Would VJ compression with SLIP be benificial even if you have
   hardware compression (v.42bis?).  If so, how much?

Yes, because RFC-1144 "VJ" TCP header compression and V.42bis do
different things.  The former is application-specific to TCP datagram
headers, so it can be very efficient at its narrow mission.   The
latter is a general-purpose data compressor, so it does a fair job on
lots of different data.

RFC-1144 reduces the number of overhead octets with which each TCP
datagram is afflicted.  It does nothing with the fare-paying cargo
inside the packet.  A typical single-character telnet packet shrinks
from forty-something to 5-8 octets, reducing transmission time and
therefore dramatically reducing interactive latency.

V.42bis is a general purpose data compression algorithm that
compresses everything that passes through the modem - overhead and
data alike.  V.42bis processing actually adds a little latency, but
not so much as to be objectionable.  And its effect on shrinking the
total size of the packets helps a *lot*.  You'll often see over 3Kb/s
FTP throughput over a V.32bis (14400) carrier with a 38400 DTE, with
very little (if any) adverse effect on latency.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jan 93 00:31:47 MST
From:      wmah@ersys.edmonton.ab.ca (Wayne Mah)
To:        comp.protocols.tcp-ip
Subject:   Unisys TCP/IP and UTS 20/40/60 emulation

Can anyone write a few words about TCP/IP on an Unisys 
mainframe and using a PC based package to provide UTS 20/40/60
emulation?
 
Our very old DCP is flakely and we would like to use the HLC
for connection to our Ethernet/Token Ring lan.
 

--
Wayne Mah              wmah@ersys.edmonton.ab.ca 

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 17:41:07 GMT
From:      heberlei@cs.ucdavis.edu (Louis Todd Heberlei)
To:        comp.protocols.tcp-ip
Subject:   reading what you're writing on Suns

I have found while using ethernet analyzers on Sun workstations
that they do not report the packets from the same host that they
are running on.  For example, the command:

		etherfind host toadflax

should report all packets TO and FROM toadflax; however, if I am
running the analyzer on toadflax, I only see packets TO toadflax.
None of the packets FROM toadflax are reported.

Apparently a Sun cannot read the packets that it is writing to
the network.  I have two questions regarding this:

    1) Is this common with most/all workstations (non-Suns)?
    2) Is there a patch so the Sun can read it's own packets?

Any help would be appreciated.  Thanks,


Todd				heberlei@cs.ucdavis.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jan 93 18:13:43 GMT
From:      alan@oetl1.scf.lmsc.lockheed.com (Alan Strassberg)
To:        comp.protocols.tcp-ip
Subject:   Re: STARLAN 10 10BASE-T hub unit doesn't like adapters

In article <1993Jan8.022641.27932@alf.cooper.edu> hak@alf.cooper.edu (Jeff Hakner) writes:
[..]
>I've had a similar problem.  When I used the Allied Telesis thick-10BASE-T
>adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the
>whole network starting dying with heavy collisions (and no traffic!).
>WHen I replaced the hub with an Allied hub (more modern), no problems.
>I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps
>there are some subtel differences which prevent this interoperation?

	When you mix non-link integrity (pre 10BaseT) with 10BaseT
	standard you get massive collisions. I run both the old 
	and new side by side by cascading hubs with an AT&T transceiver
	that has a switch for link-integrity - they work fine together.
	Some hubs (Asante, AT&T) have link-integrity switches on a per-port
	basis. And the newer StarLAN10 cards have a link switch on back.

					alan
-- 
Alan Strassberg   alan@oetl1.scf.lmsc.lockheed.com     (408) 425-6139
Lockheed, Santa Cruz, California.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 19:22:35 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?

In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>      Transmitting using what protocol?   FTP, NFS copy or what?

It's TCP based. Similar to FTP.

>>Packets are missed by the archive system, so the Sun has to retransmit
>>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
 
>   Those are pretty typical numbers for TCP layer time-outs...


Thomas Narten mentioned that the granularity of the retransmit timer
is a multiple of 0.5 seconds. Also for every ACK of one segment sent,
you have to restart the timer for the next segment.

I wonder if a finer granularity on the retransmit value would help if
the peer is on the same network? I guess this is tough because some
peers may be slow and some may be fast. It could keep track of the
time for an ACK and try to pick a timeout near that time, I guess.....


>     If this is FTP, you'd probably be better off getting rid of the
>     fatal collisions on the net.....unless you can set the time-outs
>     to a very small number (very dangerous, but....)

It's not collisions, because I saw the packets being sent.  It seems
the receiver _missed_ seeing the packets on Ethernet. People have told
me the best solution is to upgrade the receiver. This could be a
hardware upgrade (faster CPU, more memory, more ethernet ports,
smarter ethernet ports, etc.) and possibly some software tuning. Does
anyone have advice on the relative advantage of each option? How much
would more memory help? A faster CPU? A second CPU? A second Ethernet
card?  A faster disk? What is the best choice? The most cost-effective
choice? Who's gonna win the Superbowl? Well, forget the last question.
I was on a roll..... :-)


Thanks for all of the advice, esp. Stephen C. Trier, Aaron Leonard,
Thomas Narten, Anay Panvalkar, Paul Hyder, and Roger-Hunen.

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 19:24:13 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

>Apparently a Sun cannot read the packets that it is writing to
>the network.  I have two questions regarding this:
>
>    1) Is this common with most/all workstations (non-Suns)?

I've never seen an Ethernet interface that *does* hear its own
transmissions, but some may exist.  All the Ethernet-interface drivers
I've seen will wrap transmitted *broadcast* packets around internally,
so that it *looks* as if they receive the packet, but they don't do so
for non-broadcast packets.

>    2) Is there a patch so the Sun can read it's own packets?

The precise question you're asking is "is there a patch so that the Sun
can read its own packets *through the Network Interface Tap (NIT)
mechanism*, that being the mechanism that "etherfind" uses to listen to
Ethernet traffic.

I know of none, although a quick look at the code indicates that it
might be possible to arrange to have non-broadcast packets wrapped
around, just as broadcast packets are wrapped around, if the Ethernet
interface is in promiscuous mode, so I suspect such a patch is, at
least, implementable.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 19:51:39 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Tops-10

In article <lkrbiuINNi35@news.bbn.com> mckenzie@labs-n.bbn.com (Alex McKenzie) writes:
>According to Jerry Burchfiel, who was there at the time: "Bill Plummer
>and Ray Tomlinson of BBN first implemented TCP/IP on TENEX.  Thanks to
>Charles Lynn, also of BBN, it was later ported onto TOPS-20.  I think it
>skipped over TOPS-10."

Gee, if i'd known there'd be this much interest, i would have posted the
answer instead of just sending it directly.  I implemented TCP/IP on
TOPS-10.  There's no relation between the TOPS-10 implementation and the
TENEX/TOPS-20 implementation.  On the other hand, a derivitive of the
TOPS-10 code ran on WAITS, just in case anyone thought this conversation
wasn't obscure enough yet.  To my knowledge, there is no copy of the
code on the face of the earth, though i'd be happy to hear someone tell
me i'm wrong, particularly if they could send me a copy.

And, although i can't imagine anyone really cares, it ran on 6.02 and
6.03a.  After that i'm a little vague, but i think i got it to run on
7.00, but not 7.01.  Something about radical changes to the IO system
in 7.01, but, gee, that was many years ago so i don't remember the details.

						don provan
						donp@novell.com

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 20:37:30 GMT
From:      sobczyk@bcstec.ca.boeing.com (Andy Sobczyk)
To:        comp.protocols.tcp-ip
Subject:   DLPI/LLI Protocols

Newsgroup: comp.protocols.tcp-ip
Expires: 1 Feb 92

I am converting a SCO DLPI (Data Link Provider Interface) to a Interactive
/Venix LLI driver to work with WINTCP for STREAMS.  The problem I am
having is getting any information on the two protocols LLI/DLPI perferable
a detailed spec. Does anyone know where I can get this information?

If you have a copy on line.... could you mail one to me????

Andy Sobczyk
sobczyk@bcstec.ca.boeing.com



-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 93 20:39:28 GMT
From:      larry@eco.twg.com (Lawrence B. Henry III)
To:        comp.unix.aix,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: ftp: subcommand error codes


In article <1993Jan7.192157.18720@eco.twg.com>, larry@eco.twg.com (Lawrence B. Henry III) writes:
|>Austin,
|>	Check out rfc640.. I believe that this is the latest source of 
|>information on this topic.. it is readily available from nic.ddn.mil in the
|>RFC sub-directory..
|>
|>-Larry.

Ok.. so my index is old.. :-)

-Larry.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 20:49:12 GMT
From:      narten@cs.albany.edu (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?

In article <930108124846@cream.ftp.com> jbvb@vax.ftp.com  (James B. VanBokkelen) writes:

> In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
> 
>     In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
> 
>     >Packets are missed by the archive system, so the Sun has to retransmit
>     >the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
> 
>        Those are pretty typical numbers for TCP layer time-outs...
> 
> If so, it indicates that 1) the path is long, 2) the archive system is very
> slow or 3) the sending TCP has an inferior or broken adaptive retransmit
> algorithm.

The third answer is probably the best.  While one could argue that the
implementation is "inferior", the observed behavior makes sense given
the implementation. In the following, assume we are on a LAN, so that
actual RTTs are on the order of milliseconds.  It is still possible to
see retransmissions up to 1.5 seconds after a segment is sent.

Under BSD, the TCP retransmit timer clock ticks at a relatively slow
rate of .5 seconds.  Thus, the absolute minimum retransmit time one
can set is .5 seconds.  However, the time can be up to twice as long
even under normal circumstances.  One factor is that BSD only has one
retransmit timer going at a time, rather than one for each outstanding
segment.  If one transmits segments 1-4, for example, BSD starts a
single retransmit timer for segment 1.  When the ACK for segment 1
arrives, a timer needs to be started for segment 2.  Although segment
2 was sent in the past sometime (perhaps as long as just under one RTT
ago), the timer is reset to the full smoothed RTT value.  Thus, the
actual time that elapses before the retransmit timer for segment 2
expires could be as long as twice what it should be.

Finally, even though one can theoretically set a timer to go off in .5
seconds, that's not exactly the case.  BSD implements timers by having
a clock device driver call the routine tcp_slowtimeo() every .5
seconds. The actual retransmit timer is maintained as a counter in
units of .5 seconds, so that tcp_slowtimeo() simply decrements the
timer, and if it reaches 0, retransmits the segment in question.  Now,
if one wants to schedule a timer to go off in exactly .5 seconds, one
might think that setting the counter (timer) to 1 would do the trick.
Unfortunately, if tcp_slowtimeo() was last invoked 499 ms ago, it is
about to be invoked right away again and it would decrement a timer of
1 to 0 almost immediately, certainly before .5 seconds have elapsed.
Thus, when setting a timer for .5 seconds, one actually wants the
timer to go off *no sooner than* .5 seconds from now, and one may
actually have to wait .9999 seconds. That is, we want the timer to go
off during the second call of tcp_slowtimeo() rather than the first.

Even on a LAN, the above would account for the actual retransmit timer
for a segment varying from .5-1.5 seconds.  
-- 
Thomas Narten
narten@cs.albany.edu

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 21:08:27 GMT
From:      johnson@trwacs.fp.trw.com (Steve Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: A short course in TCP/IP

shan@cray.com (Sharan Kalwani) writes:

>In article <1006.UUL1.3#20656@distinct.com> chris@distinct.com (Chris Bologna) writes:
>>>> I need to attend a good TCP/IP course that would cover administration issues,
>>>> network management, programming (RPC or some DCE maybe), etc. 
>>>> Thanks for any ideas!
>>>> -Lee Thomas
 
>you may also wish to contact InterOp. I don't have a phone number handy....
                              ^^^^^^^
			1 - 800 - INTEROP  (figures ;-) )
>also the USENIX, LISA folks have TCP/IP courses too....
>-- 
>Sharan Kalwani, cri, 2000 town center suite 2350, southfield mi 48075 
>phone:    (313) 576-3948				(313) 335-5580
>internet: shan@cray.com 		uucp:  ...!uunet!cray.com!shan
-- 
------- Any views expressed are those of myself and not my employer. --------
Steven C. Johnson, WB3IRU / VK2GDS      |
TRW                                     | johnson@trwacs.fp.trw.com
FP1 / 3133                              |         [129.193.172.90]

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 93 21:34:38 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <16287@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
> >Apparently a Sun cannot read the packets that it is writing to
> >the network.  I have two questions regarding this:
> >
> >    1) Is this common with most/all workstations (non-Suns)?
> 
> I've never seen an Ethernet interface that *does* hear its own
> transmissions, but some may exist.  All the Ethernet-interface drivers
> I've seen will wrap transmitted *broadcast* packets around internally,
> so that it *looks* as if they receive the packet, but they don't do so
> for non-broadcast packets.
> 
> >    2) Is there a patch so the Sun can read it's own packets?
> ...


With 7990 LANCE based hardware, it is impossible to hear your own
packets with just the hardware, unless your packets are ridiculously
small.  Anything larger than something like 38 bytes cannot be heard.

With SEEQ 8003 and similar based systems, the hardware can in be built
to hear its own output, but the main vendor I know of that uses 8003's
and derivatives in some systems (guess which vendor) has chosen to
implement loopback purely in software.

Doing loopback in software is a good idea with common 4.3BSD and SVR4
(I think) style code, which do not work well if they cannot hear their
own broadcasts.  You usually want your system to come up even if the
ethernet cable is unplugged.


Vernon Schryver,  vjs@sgi.com

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 21:42:48 GMT
From:      rama@andy.bgsu.edu (Sub Ramakrishnan)
To:        comp.protocols.tcp-ip
Subject:   freeware PC RPC

Greettings:
Our PC will be connected to the ethernet using a WD ethernet card.
Is there a public domain RPC (and TCP) software for PCs? I know
Sun's rpc for unix platform is free but am not sure about PCs.
Thank You
==sub
-- 
Dr. Sub Ramakrishnan         Internet: rama@truth.bgsu.edu
Dept of Computer Science     Bitnet:   rama@bgsuopie
Bowling Green State University
Bowling Green, OH 43403      Voice: 419 372 2337. Fax:419 372 8061

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 1993 22:55:59 GMT
From:      sasmkg@unx.sas.com (Mark Gass)
To:        comp.protocols.tcp-ip
Subject:   seeking WINSOCK API definition

Where can I find the definition for the WINSOCK
API (the recently defined socket API for MS-Windows)?

I would like to understand portability problems
between UNIX and WINSOCK. For example, I assume
that socket descriptors cannot be passed by
the normal fork()/process-creation mechanism that
is used under UNIX. If this problem exists, are additional
functions introduced as an alternative socket passing
mechanism?

Thanks,

Mark Gass                EMAIL: sasmkg@unx.sas.com
SAS/C Development        Voice: (919) 677-8000
SAS Institute            FAX: (919) 677-8224


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jan 1993 00:49:58 GMT
From:      "Bernd Finkemeyer" <p00122@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Mil-Stds for TCP-IP

| The following article was forwarded from a Compuserve user. Please send
| any private responses to "72500.3562@compuserve.com".

These are the military standards:

MIL-STD-1777     IP
MIL-STD-1778     TCP
MIL-STD-1780     FTP
MIL-STD-1781     SMTP
MIL-STD-1782     TELNET

The last three are verbatim copies of the corresponding RFCs. The
first two are technically aligned with the corresponding RFCs, but are
more readable and include clearer, tutorial-type descriptions of the
protocols. All of them are in the Volume 1 of the Internet Technology
Handbook from the SRI NIC (nisc@nisc.sri.com)

Bill Stallings
72500.3562@compuserve.com



-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jan 1993 00:55:10 GMT
From:      hofer@rchland.vnet.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip
Subject:   XTI confusions

If a server is written using XTI, at what point 
does TCP begin sending a positive ack flow
back to the client machine in response to an
inbound connection request:

1) When the server issues the t_bind() to 
mark the descriptor to begin queuing 
connections?
2) When the server issues the t_listen() 
to find out if any connections are queued?
3) When the server issues t_accept() to 
accept the connection on the same or a 
different descriptor?

The X/open XTI spec almost reads like the
answer should be 3.  The sequence number
from the t_listen() completion is used
to respond with an "I'll take the connection"
via t_accept() or with a "no way" 
via t_snddis().  If it worked like
this, then the server could control
if the client connect completed
ok or with something like 
ECONNREFUSE.  

But, my knowledge of how the sockets 
API works tells me that XTI
probably doesn't work this way, and
the answer is problably 1).  

I'm guessing that the TCP ack goes back
to the client when the connection indication
is received, as long as someone has 
done a t_bind(), which appears to be
the same as a socket listen().

Ok, if I guessed wrong, please inform me
of how this works!  If I guessed 
correctly, could someone tell me what
happens to the connection identified
by a t_snddis() sequence number when
it is not yet accepted by the server
application?  Does TCP just send a 
RESET?

Thanks!
Kent


-- 
Kent Hofer             hofer@rchland.vnet.ibm.com
(my opinions are my own and have nothing to do with my employer)


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jan 1993 04:34:07 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>karl@ddsw1.mcs.com (Karl Denninger) writes:
>
>>>>Can the NB support 2 56700 baud modems going full blast on the
>>>>stock 2 serial ports on the motherboard?
>>>
>>>try pulling the case off and seeing of the UARTs are 16550's.
>>>
>>>i would suspect so.
 
>>They certainly are.  (I have examined lots of these)
>
>So one can assume they support the FIFO to get those speeds.
>
>My next question is do you have to enable a specific protocol --
>ie: Can I start talking to the NB with SLIP using VJ compression
>and will it start using VJ - likewise, can I connect using PPP
>and will the netblazer be smart enough to change?

The login you use on the NB will tell it what protocol (PPP or SLIP)

Once you are connected if the NB is set to "auto" mode it will send VJ
compressed packets IF it sees one from the other end.  That is, it watches
the line to see whether it should switch on the compression.

If you turn it "on" then it will initiate calls with this feature enabled.

Somewhat like the "compression" in their Trailblazer modems.  You can enable
"automatic" detection, set it "on", or "off".  If its "on" the other end
must support compression.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900]


-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jan 1993 04:34:51 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0JL58.HqK@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>Would VJ compression with SLIP be benificial even if you
>have hardware compression (v.42bis?).  If so, how much?
>
>Just wondering --

Yes.  Without VJ compression interactive sessions on SLIP or PPP connections
at dial speeds are painfully slow, even with V.42bis on the modems.

They are quite complimentary.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900]


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 93 08:08:07 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Tops-10

In article <lkrbiuINNi35@news.bbn.com>
   mckenzie@labs-n.bbn.com (Alex McKenzie) writes:
>According to Jerry Burchfiel, who was there at the time: "Bill Plummer
>and Ray Tomlinson of BBN first implemented TCP/IP on TENEX.  Thanks to
>Charles Lynn, also of BBN, it was later ported onto TOPS-20.  I think it
>skipped over TOPS-10."

The stock PDP-10s swapped segments. TENEX was a demand paged virtual
memory system, and BBN designed a memory management unit to support
that, and then implemented the system on that base. DARPA bought a lot
of them (by the standards of the time). Later, DEC built a streamlined
TENEX box and called it the DEC-system 20. The system was TENEX with
fairly minor changes, but to DEC Marketing decided to rename it TOPS-20
to underscore the similarities to TOPS-10.

The most significant DEC enhancement over TENEX, may have been
DECNET-20. Did TENEX have DECNET ?
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 93 08:13:20 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <16287@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>    2) Is there a patch so the Sun can read it's own packets?
>The precise question you're asking is "is there a patch so that the Sun
>can read its own packets *through the Network Interface Tap (NIT)
>mechanism*, that being the mechanism that "etherfind" uses to listen to
>Ethernet traffic.
>
>I know of none, although a quick look at the code indicates that it
>might be possible to arrange to have non-broadcast packets wrapped
>around, just as broadcast packets are wrapped around, if the Ethernet
>interface is in promiscuous mode, so I suspect such a patch is, at
>least, implementable.

It seems (from dumps of NIT-traces that I have done) as if some packets
do indeed get cloned and looped back, but generally, they don't have the
sender's ethernet address filled in, so they don't always get
recognized for what they are....
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 93 16:47:34 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: time outs in FIN-WAIT2??

In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes:
> Hello
> 
> I was wondering if anyone out there knows anything about a curious thing I've
> seen while ftping into various machines.
> 
> I am writing a pc based ftp client program, among other things this software
> has a hold screen function which is useful for pausing dirs to the screen &
> etc.  Anyway, if the screen is held the incoming directory listing backs up
> to the limit of my advertised window - just like it is supposed to. If the 
> window happens to be larger than the remaining data the other side will 
> send its fin and (i presume) move to fin-wait1. My side will go to close_wait
> 
> My side will remain in close-wait because it cannot get rid of the remaining
> data (the hold screen is on) but will ack the other sides fin which 
> (i presume) moves it to fin_wait2. The problem happens when I release the
> hold screen. When this happens my side finishes processing the data and sends
> its own fin, then moves to last ack. I have found that if the wait is long 
> enough (10 sec or so) the other side will ignore my fin and never return an
> ack - this leaves me in last_ack.  Eventually it seems my retransmitted fin
> will generate a reset from the other side. 
> 
> I interpret this problem to mean that the other side has timed out or retried
> out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?
> It sure isn't in the rfc. Is there another interpretation. I have experienced
> it with a number of types of machines on the internet (via anonymous ftp) maybe
> anonymous is a special case in unix boxes?
> 
> Can anyone definitly confirm (one way or the other) that this is in fact
> what is going on. I don't rule out bugs in my software, but I checked pretty
> thouroughly before asking here.
> 
> Thanks
> 						Dale Edgar
> 						Cybernetic Control Inc.
> 						DEDGAR@MTA.CA
-----------
	I did some similar thinking recently in my program. The answer depends
on how one interprets "delivers the data." I finally decided that delivery
meant placing in a socket buffer so I could send ACKs in the background as
the buffer filled. Given this position then the buffer belongs to the top
level application and not to the TCP session. Thus the session can close up
normally and so on, yet that buffer remains for later draining. This works
well with systems which insist upon sending reams of goodbye message material 
and my program is busy with other things for a while. For top level app, the
session is over when both the TCP part has finished completely and the buffer
is empty.
	Opinions do/will differ on this end to end delivery stuff. 
	Joe D.

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 93 15:05:50 GMT
From:      jraja@vipunen.hut.fi (Jarno Tapio Rajahalme)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking WINSOCK API definition

The winsock API specification can be found from vax.ftp.com with
anonymous ftp from directory pub/winsockapi/winsock-1.1. vax.ftp.com
is FTP Software's machine.

	Jarno

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jan 1993 16:42:15 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   time outs in FIN-WAIT2??

Hello

I was wondering if anyone out there knows anything about a curious thing I've
seen while ftping into various machines.

I am writing a pc based ftp client program, among other things this software
has a hold screen function which is useful for pausing dirs to the screen &
etc.  Anyway, if the screen is held the incoming directory listing backs up
to the limit of my advertised window - just like it is supposed to. If the 
window happens to be larger than the remaining data the other side will 
send its fin and (i presume) move to fin-wait1. My side will go to close_wait

My side will remain in close-wait because it cannot get rid of the remaining
data (the hold screen is on) but will ack the other sides fin which 
(i presume) moves it to fin_wait2. The problem happens when I release the
hold screen. When this happens my side finishes processing the data and sends
its own fin, then moves to last ack. I have found that if the wait is long 
enough (10 sec or so) the other side will ignore my fin and never return an
ack - this leaves me in last_ack.  Eventually it seems my retransmitted fin
will generate a reset from the other side. 

I interpret this problem to mean that the other side has timed out or retried
out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?
It sure isn't in the rfc. Is there another interpretation. I have experienced
it with a number of types of machines on the internet (via anonymous ftp) maybe
anonymous is a special case in unix boxes?

Can anyone definitly confirm (one way or the other) that this is in fact
what is going on. I don't rule out bugs in my software, but I checked pretty
thouroughly before asking here.

Thanks
						Dale Edgar
						Cybernetic Control Inc.
						DEDGAR@MTA.CA


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jan 1993 18:10:02 GMT
From:      jcmorris@mwunix.mitre.org (Joe Morris)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TELNET terminal types

[I haven't been monitoring this group before, so excuse me if this
 is an FAQ...]

I'm looking for some help in resolving a problem of common usage versus
RFC standards in the tcp/ip arena.

Our corporate standard PC-based TCP/IP package (Wollongong's PathWay for DOS)
gives us problems when it is used to attach via telnet to the various UNIX
boxes around the campus.  In particular, in the terminal-type options
negotiation (per RFC 1091) the Wollongong product is delivering the text
string:

    DEC-VT100

(or "DEC-VT220" or whatever) to the host.  Unless I've missed something
this actually does conform to the requirements of RFC 1060 ("Assigned
Numbers") dated 3/90.

The trouble is that none of our UNIX boxes (typically running SUN-OS,
IBM's AIX (RS-6000), or Silicon Graphics' IRIX) have the faintest
idea what to do with this terminal type; their terminfo files expect
something like "vt100".  One problem is that RFC 1060 does not include
any terminal types of the form "VTxxx".

So...any comments?  Is Wollongong alone in adhering to RFC 1060, or do
the UNIX vendors say "RFC's aren't legal standards", or have I missed
some obvious point here?

Joe Morris / MITRE

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jan 1993 23:59:02 GMT
From:      frank@twg.com (Frank McConnell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TELNET terminal types

I find the following workaround helpful in dealing with mismatches
between the terminal types listed in the Assigned Numbers RFC and
those that appear in termcap or terminfo databases:

	eval `tset -s -m 'dec-vt100:vt100' -m 'network:?vt100'`

This appears in my .login on most of the Suns that I work with.

The "-m 'dec-vt100:vt100'" instructs tset to map a terminal type of
"dec-vt100" to "vt100", and the "-s" instructs tset to issue commands
to reset the terminal type in the environment.  (The later 
"-m 'network:?vt100'" instructs tset to prompt for a terminal type if the
terminal type is initially set to "network", but to assume a default
value of "vt100".  This covers cases where the TELNET client I'm using
at the time isn't reporting a terminal type; in some of those cases,
I'm TELNET-ing in from an HP terminal that is not like a VT100 and so
want to be able to specify a type of "hp".)

Hope this helps!  If you need additional help with this, feel free to
e-mail me.

-Frank McConnell, Product Engineering, The Wollongong Group
 <frank@twg.com>

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jan 1993 00:18:13 GMT
From:      bygg@sunic.sunet.se (Johnny Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Tops-10

In article <1993Jan8.195139.27625@novell.com> donp@novell.com (don provan) writes:

>Gee, if i'd known there'd be this much interest, i would have posted the
>answer instead of just sending it directly.  I implemented TCP/IP on
>TOPS-10.  There's no relation between the TOPS-10 implementation and the
>TENEX/TOPS-20 implementation.  On the other hand, a derivitive of the
>TOPS-10 code ran on WAITS, just in case anyone thought this conversation
>wasn't obscure enough yet.  To my knowledge, there is no copy of the
>code on the face of the earth, though i'd be happy to hear someone tell
>me i'm wrong, particularly if they could send me a copy.

See below.

>And, although i can't imagine anyone really cares, it ran on 6.02 and
>6.03a.  After that i'm a little vague, but i think i got it to run on
>7.00, but not 7.01.  Something about radical changes to the IO system
>in 7.01, but, gee, that was many years ago so i don't remember the details.

It has been running on 7.02, talking IP-on-top-of-DDCMP to a VAX running
BSD 4.2, thru an ANF-10 front end sync port instead of using an IMP.
This required some slight changes...

Beginning if TCPSER.MAC follows, to prove I'm not lying:

title	TCPSer
subttl	provan

	search	f,s
	search	NetDef		; network definitions
	search	MacTen		; search only if symbol not found in NetDef

	sall

	$reloc
	$high

XP	VTCPSr,7		; TCP version
 comment	\

this module contains the support routines for the transmission
control protocol as defined in RFC-793

\
 	subttl	compilation control

; number of perpetual listens to allow at one time.
; [udp] make global
ifndef PlsLen,<	PlsLen==:^d10 >		; default is 10 entries
 	subttl	TCP states


; first define the states we have for TCP

S%Clos==^d0		;; closed (sometimes convenient, although usually
			;;		detected by absense of DDB)
			;; must ALWAYS be zero.  "closed" type states are
			;;	less than or equal to zero.
S%List==^d1		;; listen
S%SynS==^d2		;; SYN sent
S%SyRP==^d3		;; SYN received, passive
S%SyRA==^d4		;; SYN received, active (from S%SynS)
S%Estb==^d5		;; established
S%Fin1==^d6		;; FIN wait 1
S%Fin2==^d7		;; FIN wait 2
S%Clsn==^d8		;; Closing
S%TimW==^d9		;; time wait
S%ClsW==^d10		;; Close wait
S%LAck==^d11		;; last ACK
 	subttl	macro for dispatching on different states


; now define a macro to define a dispatch vector.  there are three
;  arguments.  the first is the register containing the state code.
;  the second is the location to jump to if a state comes which
;  is not defined in this table.  the third is a list of pairs of
;  entries: the state code and the instruction to execute.

;warning: the state pairs MUST begin on the same line as the second
;	argument.  state pairs MUST be separated from each other with
;	commas (between each pair) which MUST be on the same line as
;	the macro which FOLLOWs.

define	Dispat (AC,ErrLoc,StPair),
    <
	...min==777777			;; a high starting point
	...max==-1			;; and a low one
	define	Pair (state,instr),
	    <
		ifl <state>-...min,<	...min==<state>	>
		ifg <state>-...max,<	...max==<state>	>
	    >

	define	$$help(bogus),<	pair(bogus) >	;; your classic helper macro

	irp StPair,<		;; for each pair
		$$help(StPair)	;; expand the Pair macro with each pair
				;;  the as arguments.
	>

	;; code to check to see if the state is in the legal range
	cail	<AC>,...min		;; less than the lowest we know
	 caile	<AC>,...max		;; or greater than the highest
	  jrst	<ErrLoc>		;; go to the error handler

	define	Pair (state,instr),
	    <
		ife ...x-<state>,<	;; is this our state?
			instr		;; expand the instruction
			...flg==1	;; and tell that we did something
		>
	    >

	;; code for the actual dispatching
	xct	[
		 ...x==...min		;; start with lowest state
		 repeat ...max-...min+1,<	;; do every state in the range
		    ...flg==0		;; nobody's claimed this spot yet
		    irp StPair,<	;; go through all the pairs
			$$help(StPair)	;; expanding the Pair macro with each.
		    >
		    ife ...flg,<	;; if no one claimed to be this
			jrst	<ErrLoc>;; go to the error handler
		    >
		    ...x==...x+1	;; next place.
		 >
		]-...min(<AC>)		;; now correctly index the XCT
	purge	...min,...max,...x,...flg
    >	;; end of Dispat macro definition

;; Let's skip to an interesting routine:

	subttl	SecChk

;++
; Functional description:
;
;	Classified.
;
;
; Calling sequence:
;
;	Classified.
;
; Input parameters:
;
;	Classified.
;
; Output parameters:
;
;	Classified.
;
; Implicit inputs:
;
;	Classified.
;
; Implicit outputs:
;
;	Classified.
;
; Routine value:
;
;	Classified.
;
; Side effects:
;
;	Classified.
;
;--


SecChk:	pjrst	cpopj1##		; security looks good.

>						don provan
>						donp@novell.com

--Johnny

"When in doubt -- hesitate!"

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 93 03:08:41 GMT
From:      alagu@Apple.COM (Alagu Periyannan)
To:        comp.protocols.tcp-ip
Subject:   raw sockets and TCP/IP internals

Hi!

I would like to write some programs on a UNIX system to test
the TCP/IP protocol implementation on another system, say a black
box running a TCP echo server.  I need to test the IP and TCP
implementations on such a black box.

Is there any document where I can get more information on opening
raw sockets and accessing the tcp and ip layers directly ?
I would like to have access to the sequence numbers, ack numbers,
checksums, etc. on the outgoing packets.
I would also like to analyze the response from the black box
to determine whether it conforms to TCP/IP protocol.

Any suggestions on how to do this ??

There are many include files in /usr/include/netinet which are never
used with normal sockets programs. Is there any documentation for
using these files in programs ?

Thanks.

-Alagu Periyannan

alagu@apple.com

-- 
---------------------------------------------------------------
Alagu Periyannan

alagu@apple.com

.... and the cosmic hippo rides a jet carpet !!

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 93 06:15:28 GMT
From:      olson@anchor.esd.sgi.com (Dave Olson)
To:        comp.protocols.tcp-ip
Subject:   Re: WINTCP or DOS / IRIS Problem.

In <1ic3orINN9nn@vttux1.vtt.fi> leino@rat.vtt.fi (Tapio Leino) writes:
| This just makes us wonder. Why has the window size been changed? What
| do we lose changing it back to its original value, 24k?

Performance between hosts that can handle it.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 93 09:16:04 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386
Subject:   Unix drivers for TIARA LE16 ethernet adapters?

I am looking for updated Xenix drivers and SCO Unix drivers for Tiara
LE16 ethernet cards.  The card came with a slightly shakey Xenix driver,
and instructions to call the Tiara BBS (415-966-8533), which seems to
have died the death.  Does anyone know of FTP-able Tiara drivers for 
Xenix, SCO Unix or even Intel's sVr4?  I have the latest DOS packet
drivers, but can't afford to buy a few SMC cards right now :-(.

Any pointers will be most gratefully appreciated.
 
 ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
 Paul Nash                                         paul@frcs.Alt.ZA
 Box 12475, Onderstepoort, 0110 South Africa         +27-12-5611879

 "Standards are great -- everyone should have one" (Kent Landfield)

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jan 1993 10:06:58 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: MORE ON TOOLS TO FIND ROUTING TABLES OF REM

In article <1993Jan6.211340.13111@colorado.edu>, garnett@refuge.Colorado.EDU
 (Santiago de la Paz) wrote:
>The only way to really make sure of what advertisements a gateway makes is
>to sit and listen for them, e.g. with gated tracing turned on or some
>handmade NIT utility.

You could also use "tcpdump" to show what's coming in on the UDP RIP
port.

In any case, passive monitoring only works if you are on the same
network as the source.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jan 1993 14:22:47 GMT
From:      jp@tygra.Michigan.COM (John Palmer)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
"karl@ddsw1.mcs.com (Karl Denninger) writes:
"
">>>Can the NB support 2 56700 baud modems going full blast on the
">>>stock 2 serial ports on the motherboard?
">>
">>try pulling the case off and seeing of the UARTs are 16550's.
">>
">>i would suspect so.
"
">They certainly are.  (I have examined lots of these)
"
"So one can assume they support the FIFO to get those speeds.
"

The best bet in using the Netblazer for dialup IP is to ignore the first
two ports as they are built into the board and are standard AT serial
ports. The 8-port cards are Digiboard PC/8e's. You can take one out of
the box and plug it into your Netblazer and it will work fine. There are
instructions in the Netblazer manual on how to set the dip switches. 
-- 
Its most likely a     | E-MAIL: jp@michigan.com  CAT-TALK IS BACK as a FREE
forgery, so save your | SYSTEM!! 313-882-2209 300-14400 V.32/V.32BIS/TurboPEP
flames for someone    | Anon-UUCP: System: tygra, Login: nuucp, no pw
who cares  :->        | Get file "/cat/pub/filelist" for a list of files.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jan 1993 15:16:33 GMT
From:      wmchung@ie.cuhk.hk (chung wai man)
To:        comp.protocols.tcp-ip
Subject:   About image transmission protocol

Hello!

I wonder if there is any popular image transmission protocol (like 
ftp for file transfer). If so, what are they? And, is there any
document on those protocols?

Thanks!

Please mail reply to: wmchung@eng.ie.cuhk.hk

Best Regards,
W.M. Chung


-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 93 17:01:58 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TELNET terminal types

One solution is to modify the termcap or terminfo files, as appropriate for
the system, to accept dec-vt100 as a synonym for vt100.

The solution used by NCSA Telnet (or was it CUTCP?) was to make the terminal
name user-configurable.

The final option (really klugey) is to assume your telnet was written in C
and use a hex editor to search for and change "DEC-VT100\0" to
"vt100\0\0\0\0\0".  (\0 represents a NUL, an 00 byte.)

I strongly recommend the first option, since one should always prefer making
a system RFC compliant over making its peer non-compliant.  The third option
should be used only as your last resort, and you should check your license to
make sure it's legally OK before doing it.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 93 17:10:18 GMT
From:      jgm+@CMU.EDU (John Gardiner Myers)
To:        comp.mail.sendmail,comp.protocols.tcp-ip,comp.mail.headers
Subject:   Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers

bruce@blilly.uucp (Bruce Lilly) writes:
> 1)      RFC821 section 4.1.1 requires the "from" and "by" clauses, while
>         RFC822 4.1 lists them as optional.

[...]

> so if a message which arrives at an
> Internet site via some mechanism other than SMTP contains an RFC822
> Received header without a "from" or a "by" clause (or without both),
> it is a technical violation of either RFC821 or RFC1123 to transmit
> the message via SMTP to another Internet site

I disagree.  RFC 821 specifies the grammar of the time stamp line a
server must insert at the beginning of the mail data (4.1.1.DATA).  I
see no prohibition in RFC 821 against transmitting a message already
containing Recieved: headers that do not match the <time-stamp-line>
grammar.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jan 1993 22:48:44 GMT
From:      duncan@comp.vuw.ac.nz (Duncan McEwan)
To:        comp.protocols.tcp-ip
Subject:   Re: time outs in FIN-WAIT2??

In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>
>I interpret this problem to mean that the other side has timed out or retried
>out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?

I'm not sure if this is what you are seeing, but pg 365 of "The Design and
Implementation of the 4.3BSD UNIX Operating System", describes how 4.3
BSD also starts the 2*MSL timer when in FIN_WAIT_2 state if the local
process has closed.

>It sure isn't in the rfc.

It claims this is done as a work around because "certain other TCP
implementations (incorrectly) fail to send a FIN on a receive-only connection.
Connections to such hosts will remain in FIN_WAIT_2 state forever unless the
system times them out".

Duncan

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 10:29:26 -0500
From:      "Alex R.N. Wetmore" <aw2t+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   call routine when packet arrives?

I was wondering if there is any way to have standard bsd sockets
automatically call a routine when a packet arrives (sort of like what
signal() does for signals).  Basically, I have a program that isn't
event driven, but I would like for it to be able to get interrupted when
certain packets arrive (it is for a bbs, and I need to use it for system
messages, talk pages, etc).  I used to implement them using signals, but
since I am moving to a client/server model, and the client can be on a
different machine, I can't use signals anymore.

Otherwise, I could implement the packet waiting routine in where the
program waits for keystrokes, but I don't see a way of doing that
without polling (which means high cpu usage).

any ideas?

alex



-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 02:25:32 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: time outs in FIN-WAIT2??

In article <C0nu19.8z7@comp.vuw.ac.nz>, duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
....
> It claims this is done as a work around because "certain other TCP
> implementations (incorrectly) fail to send a FIN on a receive-only connection.
> Connections to such hosts will remain in FIN_WAIT_2 state forever unless the
> system times them out".

	It's actually worse than that, in that it doesn't require a non-
conforming TCP to break things. When you're in FIN_WAIT_2, all data you've
sent has been acknowledged and the user has already done a close(). All
you're waiting for is the FIN from the other side. If the other machine
crashes, there isn't anything to cause you to delete the entry or ever
resend another packet, so the TCB will hang around forever.
	In old 4.2 BSD implementations, these used to collect until a reboot
was required to get back the resources they were holding. Adding the timer
prevents that, but has its own problems. Having a timer, but a long one,
is a compromise. Our Berkeley derivatives timeout after 30 minutes, which
is probably long enough; the #define is still named "TCPT_2MSL" (RFC 793
says 2MSL'd be 4 minutes).
	If I remember right, the original poster said 10 seconds-- a good
implementation will restart the TIME_WAIT timer each time it receives a
segment, so it really is timing the "dead interval" when the other side may
have crashed. Fixing that (or asking the vendor to) may be the solution.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 03:23:35 GMT
From:      vances@xenitec.on.ca (Vance Shipley)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <1993Jan10.142249.5913jp@tygra.Michigan.COM> jp@tygra.Michigan.COM (John Palmer) writes:
>
>The best bet in using the Netblazer for dialup IP is to ignore the first
>two ports as they are built into the board and are standard AT serial
>ports. The 8-port cards are Digiboard PC/8e's. You can take one out of
>the box and plug it into your Netblazer and it will work fine. There are
>instructions in the Netblazer manual on how to set the dip switches. 

Is there any way to put a DigiBoard PC/8e in a KA9Q NOS box?

-- 
Vance Shipley 
vances@xenitec.on.ca         vances@switchview.com         vances@ltg.uucp

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 03:32:38 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <1993Jan10.142249.5913jp@tygra.Michigan.COM> jp@tygra.Michigan.COM (John Palmer) writes:
>In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>"karl@ddsw1.mcs.com (Karl Denninger) writes:
>"
>">>>Can the NB support 2 56700 baud modems going full blast on the
>">>>stock 2 serial ports on the motherboard?
>">>
>">>try pulling the case off and seeing of the UARTs are 16550's.
>">>
>">>i would suspect so.
>"
>">They certainly are.  (I have examined lots of these)
>"
>"So one can assume they support the FIFO to get those speeds.
>
>The best bet in using the Netblazer for dialup IP is to ignore the first
>two ports as they are built into the board and are standard AT serial
>ports. The 8-port cards are Digiboard PC/8e's. You can take one out of
>the box and plug it into your Netblazer and it will work fine. There are
>instructions in the Netblazer manual on how to set the dip switches. 

JP is back!

Heh John, that's damn funny you know..... I have this NetBlazer Classic
sitting right here in front of me with the cover off it.....

It has ------- a SERIAL BOARD in it with two 16550s in it!

BE CAREFUL with those Digiboards.  The PC/8e is available in more than one
version.  The ones used in the Netblazer run a different clock rate (12.5Mhz
vs 8Mhz normally) and have some other upgraded components.  Attempting to 
use a standard Digiboard >might< work, but it might also not, especially at
higher baud rates (57600 bps comes to mind).

(I've used more than 200 of the "classic" models, and a few of the STs.  The
ST is a nice box, but doesn't have enough slots ;-)

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900]

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 05:15:11 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

karl@ddsw1.mcs.com (Karl Denninger) writes:

>It has ------- a SERIAL BOARD in it with two 16550s in it!

Ok, so my question is answered.  Thanks -- is that Netblazer going
on ddsw1 (some of your users mentioned that ddsw1 should be on
the internet "real soon now")?

>(I've used more than 200 of the "classic" models, and a few of the STs.  The
>ST is a nice box, but doesn't have enough slots ;-)

I don't know the difference between the classic and st.  What is it?

Also, is it possible to put a v.35 board in a machine running Dell 2.2
and do the routing under Unix?

-- 
Larry Snyder                                    internet: larry@gator.use.com
keeper of the Gator                                   uucp: uunet!gator!larry

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 16:30:40 -0500
From:      Tod McQuillin <tm8t+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: call routine when packet arrives?

"Alex R.N. Wetmore" <aw2t+@andrew.cmu.edu> writes:
> I was wondering if there is any way to have standard bsd sockets
> automatically call a routine when a packet arrives (sort of like what
> signal() does for signals).  Basically, I have a program that isn't
> event driven, but I would like for it to be able to get interrupted when
> certain packets arrive (it is for a bbs, and I need to use it for system
> messages, talk pages, etc).  I used to implement them using signals, but
> since I am moving to a client/server model, and the client can be on a
> different machine, I can't use signals anymore.

Sure.  Use asynchronous I/O.  You'll want to use

	int yes=1;
	fcntl(s, F_SETFL, FASYNC);

Then enable a signal handler for SIGIO.

	signal(SIGIO, handler);

> Otherwise, I could implement the packet waiting routine in where the
> program waits for keystrokes, but I don't see a way of doing that
> without polling (which means high cpu usage).

You could do it this way too.  Use the select(2) system call instead
of polling.

Both these techniqies are well explained in Richard Stevens' book,
"Unix Network Programming," which I highly recommend.


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 09:56:34 GMT
From:      Jan.vOorschot@dnpap.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.snmp,comp.os.os2.networking,comp.os.os2.apps,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   New Beholder and Tricklet, RMON and SNMP software for OS/2 and UNIX

Beholder, The Next Generation (bntg)			8 january 1992

The btng package is the result of the latest work done by
the DNPAP group of the Delft University of Technology.

The btng package includes beholder.exe, an RMON compliant 
ethernet monitor for the OS/2 operating system environment.
It also includes the Tricklet package for OS/2 and UNIX. Tricklet is
a set of SNMP utilities, including a full featured Perl interface.

The OS/2 executables and documentation of btng and Tricklet 
version 2 can be found in:

	btng2exe.zip
	
The full source of the monitor and the Tricklet utilities are in:

	btng2scr.zip
	
The sources of the Tricklet utilities to be used on UNIX platforms 
are in:

	trcklt2.tar.Z
	trcklt2.zip
	
OS/2
----
You will need the following to run the OS/2 executables:

	- PC with a running OS/2 1.x or 2.x
	- ethernet network adapter
	- NDIS protocol stack
	- optional TCP/IP 1.2 from IBM for OS/2 (only used by Tricklet)

UNIX
----	
On a UNIX platform you will need an ANSI C compiler and a TCP/IP
stack with socket interface.

OS/2 development
----------------
To compile the OS/2 software, you will need:

	- microsoft C compiler 6.0 (last one with OS/2 support, thanx microsoft)
	- IBM's OS2 toolkit for OS/2 1.3
	- IBM's TCP/IP 1.2 kit



MISC
----
	- btng is distributed with source code
	- we don't ask for much, just acknowledgement of our work, 
	  bug-reports, suggestions etc.
	- the software can be obtained using anonymous ftp
	  to dnpap.et.tudelft.nl. Get the following files:
	  
	  	pub/btng/btng2exe.zip		# executables
	  	pub/btng/btng2src.zip		# full source
	  	pub/btng/trcklt2.zip		# UNIX source of Tricklet
		pub/btng/trcklt2.tar.Z		# utils.
						
		pub/btng/perl4019.zip  		# OS/2 1.3 perl
		pub/btng/perl4035.zip  		# OS/2 2.0 perl
		pub/btng/unz50x16.exe 		# OS/2 [12].x unzip
						
	  you can also mail to our mailserver
	  
	  	mailserver@dnpap.et.tudelft.nl
				   
Now the bad news:

	- btng2 is the first (beta-like) version that hits the
	  public streets. There will be problems/bugs.
	- it is a very advanced piece of software, and you
	  can do a lot of things wrong.
	- there is documentation, but no introduction
	  for the use of SNMP and RMON monitors.
	  
We wrote this software to experiment with network managament, SNMP,
and RMON. Although the software conforms to all these standards,
it is should not be confused with commercial products. We don't give 
support, and don't ask for money and licence fees.

So use it to experiment with network management, in non-critical 
network environments.

If you are using the btng software, you are advised to join
our mailing list. 

	btng@dnpap.et.tudelft.nl	 --> mailing list
	btng-request@dnpap.et.tudelft.nl --> subscribtions/unsubscr.

You can also have a look at our gopher server at

	dnpap.et.tudelft.nl  port 70
	
Carpe Diem,

Jan

-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
 



-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 13:47:51 GMT
From:      dos@major.panix.com (Dave O'Shea)
To:        comp.protocols.tcp-ip
Subject:   Address conversion

I've got the enviable task of connecting together two networks that were
designed separately. One is on the internet, so they've kept their
addressing clean and up to specs, but the other one is a small
stand-alone network that has its own rather unique addressing scheme.

Changing the addresses on the network is not really an option; the app
they have is hard-coded to look for certain addresses, and rewriting it
would be more troublesome than it's worth.

What I'm looking for is something along the lines of a router than could
hold an address translation table (which would, of course, have to be
generated by hand, but that's no problem), and convert addresses going
in both directions.

As this will be used to pass only some SNMP traffic, performance isn't
an issue; 50-100 packets/second would be more than sufficient.

Does anyone know if such an animal exists? I've heard of folks doing
something along these lines with what they called a gateway, but I've
been unable to trace down any commercial source for a product such as
this.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 14:55:19 GMT
From:      beaulieu@bose.com (Larry Beaulieu)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer


	I don't know the difference between the classic and st.  What is it?


The ST uses a 4" high PC case and has only 3 horizontal ISA slots vs the
more conventional configuration of the classic. Except for the limited
expandability of the ST the 2 are functionally identical.
--
--
Larry Beaulieu			beaulieu@bose.com
Bose Corporation		Phone: 508-879-1916 x6479
Framingham, MA 01701-9168	FAX:   508-820-4865	

		All flames gleefully ignored.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 15:15:39 GMT
From:      stein@itek.norut.no (Stein Olav Toennessen)
To:        comp.protocols.tcp-ip
Subject:   Source routing of "raw-IP" packets.


I'am looking for simple programs which use "loose source routing" in order to 
spesify a route of internet-addresses which raw-ip packets has to visit.

I have tried to implement some code which do this, on a decstation runing ultrix 4.2a, using BSD-sockets without sucess so far. Has somone done this before using raw BSD-sockets? If so how did you do it?

Is there other ways to spesify addresses which datagrams have to visit before delivery at destination?  (other then loose and strict source-routing)

If so, can the source-address and destination-address be the same ?

Please reply to me directly !!

__________________________________________________________________________
Stein Olav Toennessen 		Phone: +47 83 80150, Fax: +478382420
FORUT IT AS 
NORUT-Gruppen AS
N-9005 Tromsoe, Norway		E-mail: stein-olav.tonnessen@itek.norut.no
--------------------------------------------------------------------------

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 93 15:53:39 GMT
From:      bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly)
To:        comp.mail.sendmail,comp.protocols.tcp-ip,comp.mail.headers
Subject:   Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers

In article <gfICIOa00WBwQPAmVQ@andrew.cmu.edu>,
 posted to comp.mail.sendmail,comp.protocols.tcp-ip,comp.mail.headers,
 jgm+@CMU.EDU (John Gardiner Myers) wrote:
>
>I disagree.  RFC 821 specifies the grammar of the time stamp line a
>server must insert at the beginning of the mail data (4.1.1.DATA).  I
>see no prohibition in RFC 821 against transmitting a message already
>containing Recieved: headers that do not match the <time-stamp-line>
>grammar.

The section you mentioned explicitly states ``Relayed messages will have
multiple time stamp lines.'' The syntax for the time stamp (Received) lines
*requires* the "from" and "by" clauses. No exceptions are stated. Note that
example 8 in RFC821 shows "from" and "by" clauses in all Received headers,
not only the first one.

I suppose one could claim that Received headers without the "from"
and/or "by" clauses aren't RFC821 time-stamp lines, but are mere ordinary
RFC822 headers.  Note that RFC821 states ``that the final mail data will
begin with a  return path line, followed by one or more time stamp lines.
These lines will be followed by the mail data header and body''. If some
Received headers are to be considered non-time-stamps, then it will be
necessary to reorder the Received headers so that the ones which are also
time-stamp-lines are placed before the non-time-stamp lines. I feel that this
would hamper debugging, as the order of Received headers would not then
correspond to the delivery path.

I still think this area needs some clarification.  For reasons mentioned in
my original article, I would like to see at least the "by" clause made
mandatory.

-- 
    Bruce Lilly, Product Manager,      | 
    Routers, Peripherals & Still Store,| uupsi!monymsys!sonyd1!bruce
    Sony, 3 Paragon Drive, Montvale,   | lilb@sony.compuserve.com
    NJ 07645-1735  |  Telephone: +1 201 358 4161  |  FAX: +1 201 358 4274

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 15:53:49 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

The Berkeley Packet Filter, if installed in the kernel, does allow
etherfind/tcpdump to "see" packets transmitted. There is source and
binary available for some systems, but I have not been able to get it
working on SunOS - ( I didn't try too hard). 

The sources of BPF are included in the sources of tcpdump found on 
ftp.ee.lbl.gov:tcpdump.tar.Z
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1993 16:52:01 GMT
From:      berg@physik.tu-muenchen.de (Stephen R. van den Berg)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: SLIP on a SUN?

In article <1993Jan8.142323.28975@fripp.ri.cadre.com> jh@cadre.com writes:
>In article EAC@csn.org, bhays@teal.csn.org (Boyd Hays) writes:
>>Hello,
>>    I need to put SLIP up on a SUN IPC running 4.1.2. Is there a general
>>    concensus as to which version is "best". I'm anticipating putting up
>>    cslip-2.6. 
 
>I'm currently looking at setting up a SLIP connection as well.  I got a
>version of cslip off the net, although it was not the latest version.  It
>had almost nothing in the way of documentation, and I didn't get it to
>install properly.  I then tried a copy of MorningStar's PPP with cslip
>that we had in-house.  It installed fairly easily, and seems to work fine.
>I'm going to get the new cslip today, but if it's as cryptic as the old one,
>MorningStar's going to have a new customer.

The cslip-2.6 is heartily recommended.  Apart from a slightly awkward Makefile
it runs and installs like a charm.

The install docs are correct.
-- 
Sincerely,                                  berg@pool.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"Be spontaneous!"

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 18:00:37 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Using RARP for Greater Security


I want to sincerely thank all who answered my questions about using RARP.
Here is what you had to say.

Quoted material follows:



From:    Tony Li <tli@cisco.com>
Subject: Re: Using RARP for Greater Security



Disable ARP on the router attached to that interface.  Add static ARP
entries.  Filter traffic that comes out of that interface.

Tony




From:    Lyndon Nerenberg <Lyndon.Nerenberg@unbc.edu>
Subject: Re: Using RARP for Greater Security


Our plan is to install Beame & Whiteside TCP on our PC's. B&W provides
support for BOOTP. By replacing the ROMs in your Ethernet card you can
boot the PC's from your file servers. Using BOOTP allows you to maintain
a central database of Ethernet MAC to IP address mappings. They can't
bugger with this short of replacing the ROM's.

Send e-mail to sales@bws.com for further information.

--lyndon




From:    Adrian Miranda <ade@vancouver.wsu.edu>
Subject: Re: Using RARP for Greater Security


Well, I think all programs will allow you to change your
configuration, though most take a bit more effort than WINQVTNET
apparently does.  You could obtain the source for NCSA telnet, and
recompile it to force it to use rarp or bootp, but a student could
always get their own copy of telnet from the Internet and use that.

As far as I can tell, there's no really foolproof way to prevent
someone from choosing their own IP number.  Would it be enough to just
use something like NCSA which requires editing a file?  The only other
thing I can think of is to force your UNIX systems and Routers to use
static arp table entries for the PC ethernet numbers.  That is, you
would tell the UNIX system that a particular ethernet number and IP
number are associated.  Then the system would presumably ignore
attempts by another machine (with a different ethernet number) to
pretend to have that same IP number.  However, some ethernet cards
allow you to modify their ethernet numbers, so even that's not
foolproof.

By the way, if you're looking at RARP, you should also look at Bootp.
It's much more powerful.

Adrian Miranda
ade@clark.edu




From:    pcg@aberystwyth.ac.uk (Piercarlo Grandi)
Subject: Using RARP for Greater Security


The best one is to give up on such goals. Simply put, how are you going
to make sure that a fun loving student does not load its very own little
TCP/IP module on your dos machine? I always carry around with me a
floppy with a bootable system including NOS, PC GOPHER and TRUMPET, just
in case :-).

It's practically impossible to stop people doing what they want with
changing IP numbers, for example masquerading as any host they would
like to pose (there are even some Ethernet cards which have programmable
ethernet addresses). The only way out is cryptographic authentication.
Kerberos...

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 18:05:41 GMT
From:      jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
To:        comp.protocols.tcp-ip
Subject:   Who used TNAMED (IEN-116) any more?  And why?

I've noticed (via log_tcp) a few random connections from a couple of
machines to the obsolete (or so I thought) IEN-116 trivial name service
port.

Jan 11 09:42:01 avdms8 in.tnamed[2874]: connect from ...

At the time, I didn't have this service turned off, so I presume the
machines in questions had a successful connect.

Who would want to use trivial name service?

Sun's man page for in.tnamed doesn't mention any clients which use this
service.  There is a nod in the direction of uucp in the SEE ALSO area,
but the man page it refers to doesn't mention any sort of name
service.

Is there a client program to access this service?  I'd be interested in
seeing what these machines got from me, if anything.

Yes, I plan to ask the owners of these machines what they are doing.
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov
NASA/MSFC Flight Data Systems Branch

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 21:06:20 GMT
From:      parsons@postmaster@hq.af.mil (Mike Parsons)
To:        comp.protocols.tcp-ip
Subject:   Encapsulation of or translation of DECNET on a TCP/IP backbone


-- 
Does anyone know of any methods to either convert DECNET to TCP/IP and back
again or encapsulate DECNET within TCP/IP.  I need to have two DEC sites
communicate across a large packet-switched TCP/IP backbone.  Unfortunately, it
will be a somewhat unreliable network where network congestion and delay are
prevalent.  DECNET is a requirement because of the applications; TCP/IP is a
requirement for the backbone since it's someone else's empire and corporate
policy is to use the backbone.
--------------------------------------------------------------------
|	Mike Parsons			7CG  HSRP  PROGRAM	   |
|	parsons@nic.hq.af.mil					   |
|	703-614-6121					           |
--------------------------------------------------------------------

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 22:17:19 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TELNET terminal types

In article <jcmorris.726603002@mwunix> jcmorris@mwunix.mitre.org (Joe
Morris) writes: 
> In particular, in the terminal-type options
>negotiation (per RFC 1091) the Wollongong product is delivering the text
>string:
>
>    DEC-VT100

This is a conforming implementation.

>The trouble is that none of our UNIX boxes (typically running SUN-OS,
>IBM's AIX (RS-6000), or Silicon Graphics' IRIX) have the faintest
>idea what to do with this terminal type; their terminfo files expect
>something like "vt100".  One problem is that RFC 1060 does not include
>any terminal types of the form "VTxxx".

This is not a conforming implementation.

>So...any comments?  Is Wollongong alone in adhering to RFC 1060, or do
>the UNIX vendors say "RFC's aren't legal standards", or have I missed
>some obvious point here?

I've seen other things that adhere to the RFC 1060 standards wrt
terminal type.  I think that Multinet does as does the TOPS-20
implementation, but I could be wrong on either of these.

All that the unix telnet client is doing is pushing across the wire
the setting of TERM.  There is no attempt to map terminals into the
"standard" types and then back again.  In fact, I use this trick to
push across DISPLAY and terminal size information to less than robust
implementations of telnet (that do do terminal type stuff).

Your best bet would be to create aliases for DEC-VTxxx in the termcap
and terminfo databases.  This is a kludge, at best, but would solve
the problem of telnetting to the unix box from the PC.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 93 23:01:07 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?

In article <930108124846@cream.ftp.com> jbvb@ftp.com writes:
>In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

    In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:

    >Packets are missed by the archive system, so the Sun has to retransmit
    >the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
    
       Those are pretty typical numbers for TCP layer time-outs...

>If so, it indicates that 1) the path is long, 2) the archive system is very
 slow or 3) the sending TCP has an inferior or broken adaptive retransmit
 algorithm.  TCP should retransmit in something on the order of twice the
 average Round Trip Time (from send to ack).


The granularity of the per-TCB timers (retransmit, RTT, etc.) on
BSD-derived systems is 500ms.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jan 1993 23:56:19 GMT
From:      mlewis@telebit.com (Mark S. Lewis)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer


> mlewis@telebit.com (Mark S. Lewis) writes:
>>> I currently attach via SLIP over a leased line using v.32bis/v.42bis
>>> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer.
 
>>> Would I see any significant increase in throughput using this same
>>> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP
>>> with a Netblazer on my end -- and connecting my machines via ethernet
>>> to the Netblazer?
>>> [...] 
>>> Larry Snyder                                    internet: larry@gator.rn.com
>>
>>No I don't think you would get a significant performance increase by
>>putting a NetBlazer at both ends.  You are using relatively slow
>>serial lines limited by V.32bis modulation with whatever compression
>>you get with V.42bis.
>>
>>Mark S. Lewis  inet: mlewis@telebit.com  
 
> I disagree.  I think you will get some increase in preformance, depending 
> on how loaded your box that is doing the routing is.  Routing IP packets 
> takes a certain amount of CPU over head as well as servicing the serial 
> line interupts that happen every time you get a packet in.  Using 16500 
> helps.

I suppose it is possible to improve performance by shifting the burden
of routing to the NetBlazer, 386BSD or whatever.  Depends on the
routing effeciency of the original system.

Also, the NetBlazer typically drives modems at 57600, while many Unix
based SLIP connections can reliably support only 19200.  In this case,
a NetBlazer or dedicated SLIP solution may help.

> A side note.  Netblazer software was based on the KA9Q software.  Enough 
> work has gone into it by now that I imagine that it doesn't look like KA9Q 
> any more, but I wonder if it still has the same problems that KA9Q has, 
> like memory leakage and high latency. Perhaps Mark could comment on the
> Netblazer software.

As for memory leakage, we have come quite a ways.  We have made
numerous improvements to the memory allocation to help us find leaks.
At this point, there are only a few rare leaks.  In general, the
NetBlazer will stay up for months.

As for latency, I am not sure to which latency you refer.  What type
of connections are you assuming, async dial-up?  Are you talking about
round trip ping time?  Note that modems introduce significant latency.

> At the last ONEBBS con in Denver, there was a demonstration of a device 
> called "Slip-on-a-Stick".  It was a box that was about 10"x6"x2" tall, and 
> would do slip.  I don't know if it will do the right thing with subnetting
> as I only saw it work with one device on it.  The price was less than a
> grand.

I like that - "Slip-on-a-Stick."  Sound like the next taste sensation
:-)  Note that I know of several vendors that are developing such
dedicated networking serial devices.  It will be interesting to see
what comes down the pike.

>                             Tim
 
> -- 
>     Internet: pozar@kumr.lns.com     FidoNet: Tim Pozar @ 1:125/555
> Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
>                         Voice: +1 415 788 2022

KKSF is my favorite jazz station.  You guys play the tastiest jazz in
the bay area.  Thanks for the good programming.

... Mark

=========-----------          Mark S. Lewis      -----------==========
inet: mlewis@telebit.com      Telebit Corp.     Telebit (408) 745-3232
uucp: uunet!telebit!mlewis                          Fax (408) 745-3810

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1993 23:58:41 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <21102@ucdavis.ucdavis.edu> heberlei@cs.ucdavis.edu writes:
>I have found while using ethernet analyzers on Sun workstations
>that they do not report the packets from the same host that they
>are running on.
>Apparently a Sun cannot read the packets that it is writing to
>the network.  I have two questions regarding this:
>    1) Is this common with most/all workstations (non-Suns)?

Recent versions of ULTRIX provide a mechanism for applications
(such as tcpdump and nfswatch) to see all packets to/from the
host they are running on.  On ULTRIX: "man packetfilter" and
look for the string ENCOPYALL.  It took us a few tries to get this
correctly implemented, so before ULTRIX 4.3 there might be some
related bugs.

Recent releases of tcpdump and nfswatch, including the versions that
are shipped with ULTRIX, use this mechanism.  The latest version
of NNstat (v3.2) does not, but last week I made the appropriate
(1-word) patch.

-Jeff

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1993 08:45:31 -0500
From:      drj@dev-null.phys.psu.edu (Dan Jeuch)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP between PCs and 3B2s

I've got an interesting project to tackle.  I need to network an
AT&T 3B2 with a couple of IBM PCs.... preferably with minimal
equipment cost.  The PCs are currently equiped with Lantastic
ethernet cards, but the cards are supposedly compatable with
Novell NE2000 cards, but I have no way of verifying this.

Has anyone attempted/been sucessful in doing this?  Any suggestions
for software, or general advice would be greatly appreciated!

Please e-mail responses.  If there is a general interest, I can always
post a summary.

-Dan

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 93 00:38:54 GMT
From:      pccl@cbnewsd.cb.att.com (paul.c.liu)
To:        comp.sys.sun.apps,comp.protocols.tcp-ip
Subject:   tcp_mss "downshift" with consecutive rcp's

A while ago, I recall a netter from SGI posted an article
detailing a BSD TCP bug fix for the tcp_mss "downshift" symptom.

Symptom: consecutive "rcp remhost:remfil locfil" will result
	 in smaller TCP payload (i.e. from 1460-byte to 512-byte),
	 unless there is 60+ seconds time gap in between.

To reproduce: use three Suns, on sun_a, do 
	rcp sun_b:file1 file1, and
	rcp sun_b:file2 file2
	and run tcpdump/etherfind on sun_c to trace the network traffic.

Pointers are appreciated!

Paul.C.Liu@ATT.COM

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 93 01:12:46 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

>    2) Is there a patch so the Sun can read it's own packets?

This is fixed in SunOS 5.x; if a device is in promiscuous mode, the
datalink drivers will wrap packets around to all open streams attached
to that device that have "physical-level promiscuous enabled" (I assume
this means that individual streams can request to hear everything or not
to hear everything).

And, yes, "streams" refers to STREAMS; I *did* say "SunOS 5.x"....

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 03:15:12 GMT
From:      tclark@med.unc.edu (Thomas B. Clark III)
To:        comp.protocols.tcp-ip
Subject:   Setting date and time on PC

Does anyone have any experience setting the PC's date and time
from a UNIX time server using tcp/ip?

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 93 04:37:49 GMT
From:      jkreznar@ininx.UUCP (John E. Kreznar)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   SLIP (or PPP) versus ``dumb terminal'' network connections

I plan to change my network connection.  Please help me decide how.

I don't know that the groups I've selected for this posting are
appropriate.  If not, please steer me to the right place.

Is there a faq I should read?

Please respond by email.  I don't read these groups.

I am trying to decide what kind of network connection I should seek.
I have been a satisfied user of UUNET for years, but I believe that I
can now get service better matched to my needs and at lower cost.  I
am a single-user site A and seek dial-up connection through a local
Internet node B which might be commercial server or a university.  I
can think of two kinds of connection:

	Terminal.  A appears to B as a ``dumb terminal''.  A has a
	user account on B and must log in after calling.

	SLIP (or PPP).  At least for the duration of the dial-up
	connection, A is a full-fledged node on the Internet.

Are there others I should consider?

Based on a few impressions I've picked up, a terminal connection can
be lots less expensive than a SLIP connection.  One thing I'm trying
to do is clearly identify what I'd get for the extra cost of SLIP.  So
I compare the connection modes in their support of various network
services:

	email
	news
	ftp
	archie, gopher, etc.

In the following, I describe _my understanding_ of how these services
work in the two cases.  My main question is whether my understanding
is accurate and doesn't overlook important issues.

email.

Whether A is a terminal or has a SLIP connection, incoming email is
queued at B until a connection is made.  If A is a terminal, the queue
is A's user mailbox and A empties it by reading it, perhaps with the
help of a mail-reading utility.  On the other hand, if A connects
using SLIP, the queue is just another part of network traffic destined
for A which will be automatically transmitted when the connection is
made.  The mail then moves to a user mailbox at A, but since A has but
one user, this queue contains all email originally present in the SLIP
queue.  The volume of traffic over the dial-up connection doesn't
differ very much between the two cases.

There's the issue of what email addresses are possible in the two
cases.  With SLIP, A can retain its registered domain address and B's
address or identity need not be apparent in A's address.  As a dial-up
terminal, this may not be possible.

news.

Let's say that B is a major site that takes all of the news.  If A
connects as a dial-up terminal, the user at A can browse any of the
news.  The news is left undisturbed at B, although A may of course
capture to its own local files as it browses.  If the connection is by
SLIP on the other hand, site A must subscribe to the news groups it
wishes to see, this news and none other is automatically transmitted
to A's site when the connection is made, and I don't know if A could
readily browse news to which it does not subscribe.

ftp.

With SLIP, A is a full-fledged node on the Internet and can browse
directories and files anywhere else on the Internet in real time,
capturing files at will.  The same is true for the terminal case,
except that the ``capture'' is to a file at B, not A, and A would have
to do another step to get it further transmitted to A.

archie, gopher, etc.

These search tools seem to be equally available, whether as a dial-up
terminal or through SLIP.
-- 
        Relations among people to be by mutual consent, or not at all.
         ---John E. Kreznar, jkreznar@ininx.com, uunet!ininx!jkreznar

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 05:44:03 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TELNET terminal types

In article <jcmorris.726695948@mwunix>, jcmorris@mwunix.mitre.org (Joe Morris) writes:
> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
> 
> >One solution is to modify the termcap or terminfo files, as appropriate for
> >the system, to accept dec-vt100 as a synonym for vt100.
> 
>  [other options suggested]
> 
> >I strongly recommend the first option, since one should always prefer making
> >a system RFC compliant over making its peer non-compliant.  
> 
> I fully agree with this statement, but...
> 
> The trouble is that we have several hundred hosts, few of which are under
> the control of the central DP operations.  What I would like to see is
> fixes to the default termcap/terminfo tables to be issued by all the
> UNIX vendors to make their systems RFC-compliant.  
> 
> To me, the strangest thing about this is that I can't find anything to
> suggest that the issue has been previously raised.  Perhaps the proper
> solution is to re-open the "Assigned Numbers" list and update it to
> reflect industry practice, but until either the UNIX systems are changed
> or I can convince Wollongong to change, I've got a problem.
> 
> Joe Morris / MITRE

The issue is raised periodically - I believe I posted much the same beef
about 6 months ago, about adding the Telnet termtypes into the
terminfo/termcap files for standard releases. It doesn't do much good
though - users still have to patch their own files. sigh - maybe one
day.

	This was after wrestling with a box which 'required' telnet
term-type negotiation before it would negotiate _anything_ else
- and if the client refused to negotiate termtype, the link
would be left hanging, the box would acknowledge but not act on any data
or commands sent - this from a very well known firm with a TLA for a
name. Sigh.
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033| 
AUSTRALIA          |           Buy Australian

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1993 06:21:14 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Who used TNAMED (IEN-116) any more?  And why?

In article <jpc.726775541@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
>Who would want to use trivial name service?

Our 6-year-old Bridge terminal concentrators use it.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 12:51:00
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting date and time on PC

In article <1993Jan12.031512.16593@samba.oit.unc.edu> tclark@med.unc.edu (Thomas B. Clark III) writes:

    Does anyone have any experience setting the PC's date and time
    from a UNIX time server using tcp/ip?

A number of the PC TCP/IP packages (including ours) have clients for the
Time Protocol defined in RFC 868.  Its accuracy is limited, but it seems
to be good enough for most DOS usages.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 12:51:38
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TELNET terminal types

In article <C0pn8v.Anq@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:

    In article <jcmorris.726603002@mwunix> jcmorris@mwunix.mitre.org (Joe
    Morris) writes: 
    
    >So...any comments?  Is Wollongong alone in adhering to RFC 1060, or do
    >the UNIX vendors say "RFC's aren't legal standards", or have I missed
    >some obvious point here?
    
    I've seen other things that adhere to the RFC 1060 standards wrt
    terminal type.  I think that Multinet does as does the TOPS-20
    implementation, but I could be wrong on either of these.

PC/TCP defaults to RFC 1060, but we let users configure their own
names if they choose.  It would be nice if people paying for "support"
from the various Unix vendors submitted this problem as a bug - the
actual work of adding aliases wouldn't take them more than 1 day of a
junior engineer's time, and the Internet would become a *lot* better.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 93 11:40:04 GMT
From:      svl@ktas.dk (Sven Larsen)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   source from "internetworking with TCP/IP" ?


HI!
I'am looking for information on the SNMP software presented in the book

"Internetworking With TCP/IP", vol II: Design, Implementation, and
Internals. Written by Douglas E. Comer and David L. Stevens and
published 1991 by Prentice-Hall Inc.

If anybody knows the address of a ftp-server holding this software
please let me know. 

My aim is to integrate/modify the client software part to
handle the management of the MIB 1 objects in a CISCO router.

Best regards 

Sven Larsen, KTAS, Denmark; svl@ktas.dk

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 13:41:55 GMT
From:      rama@andy.bgsu.edu (Sub Ramakrishnan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IBM PC public domain TCP/IP, RPC stack


Hi, our PC will be connected to the ethernet
backbone using  a WD 8003 or something similar.
I want to do some RPC programming on RPC.

Two questions:
(1) Are there any public domain TCP/IP stack for IBM-PCs? 
(2) Are there any public domain Sun RPC or equivalent for IBM-PCs?

Thanks,
==sub

-- 
Dr. Sub Ramakrishnan         Internet: rama@truth.bgsu.edu
Dept of Computer Science     Bitnet:   rama@bgsuopie
Bowling Green State University
Bowling Green, OH 43403      Voice: 419 372 2337. Fax:419 372 8061

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 93 14:11:06 GMT
From:      luc@asterix.drev.dnd.ca (Luc Lamontagne)
To:        comp.protocols.tcp-ip
Subject:   Both client and server?


Hi,

 I want two similar applications to communicate with 
 each other. Can an application, based on RPC, be both 
 client and server? How can it be done?

 Reply to luc@vela.drev.dnd.ca .  
-- 
|                           | DREV, Defence Research Establishment,Valcartier |
|      @asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |
|            (131.132.48.2) | Office: (418) 844-           fax (418) 844-     |
+---------------------------+-------------------------------------------------+

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1993 16:47:19 GMT
From:      edvax@pyrite.som.cwru.edu (Ed Reznichenko)
To:        comp.protocols.nfs,comp.sys.sun.apps,comp.protocols.tcp-ip
Subject:   RPCGEN with inetd


The following is posted for a co-worker.  Email responses to me, and I
will pass them along.  

Thank you,

--ed

Internet: edvax@pyrite.som.cwru.edu
UUCP: uunet!pyrite.som.cwru.edu!edvax

             ----- begin included message -----
TOPIC: inetd rpc applications
HARDWARE: SPARC
OS: SunOS 4.1.1

Given that rpcgen -I fails to produce correct code for inetd-tcp-nowait
entries, does anyone happen to have tested server stubs used for 
inetd-tcp-nowait entries that they would be willing to share?

Also, the last Stevens text on page 339 says that there are no 4.3BSD 
inetd-tcp-wait flag applications. Does anyone know if this remains
true?

In order to simulate concurrent servers, we are considering defining
<n> inetd-tcp-wait servers with clients randomly selecting a server
with a uniform distribution, and hoping client time-outs are
sufficient to account for delays. Does anyone have opinions to offer
on this? 

Any help with this problem would be appreciated.
--------


Following is the rpcgen bug report we discovered painfully late after many 
futile attempts at creating an inetd-tcp-nowait entry:

 Bug Id:     1065359
 Category:  doc
 Subcategory:  network
 Release summary: 4.1.1
 Synopsis:  rpcgen -I does not work together with nowait servers
 	Integrated in releases:  5.0
 Summary:
	rpcgen -I produces rpc-code which could only be used for server
	with the flag wait in /etc/inetd.conf.  This is neither 
	documented in the man-page of rpcgen nor in the RPC-Programming
	Manual.


		----- end included message -----
--
Bus error, core dumped

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 17:53:05 GMT
From:      danson@lgc.com (Doug Anson)
To:        comp.protocols.nfs,comp.sys.sun.apps,comp.protocols.tcp-ip
Subject:   Re: RPCGEN with inetd

In article <1iusmnINNa3g@usenet.INS.CWRU.Edu>, edvax@pyrite.som.cwru.edu (Ed Reznichenko) writes:
|> 
|> The following is posted for a co-worker.  Email responses to me, and I
|> will pass them along.  
|> 
|> Thank you,
|> 
|> --ed
|> 
|> Internet: edvax@pyrite.som.cwru.edu
|> UUCP: uunet!pyrite.som.cwru.edu!edvax
|> 
|>              ----- begin included message -----
|> TOPIC: inetd rpc applications
|> HARDWARE: SPARC
|> OS: SunOS 4.1.1
|> 
|> Given that rpcgen -I fails to produce correct code for inetd-tcp-nowait
|> entries, does anyone happen to have tested server stubs used for 
|> inetd-tcp-nowait entries that they would be willing to share?
|> 
|> Also, the last Stevens text on page 339 says that there are no 4.3BSD 
|> inetd-tcp-wait flag applications. Does anyone know if this remains
|> true?
|> 
|> In order to simulate concurrent servers, we are considering defining
|> <n> inetd-tcp-wait servers with clients randomly selecting a server
|> with a uniform distribution, and hoping client time-outs are
|> sufficient to account for delays. Does anyone have opinions to offer
|> on this? 
|> 
|> Any help with this problem would be appreciated.
|> --------
|> 
|> 
|> Following is the rpcgen bug report we discovered painfully late after many 
|> futile attempts at creating an inetd-tcp-nowait entry:
|> 
|>  Bug Id:     1065359
|>  Category:  doc
|>  Subcategory:  network
|>  Release summary: 4.1.1
|>  Synopsis:  rpcgen -I does not work together with nowait servers
|>  	Integrated in releases:  5.0
|>  Summary:
|> 	rpcgen -I produces rpc-code which could only be used for server
|> 	with the flag wait in /etc/inetd.conf.  This is neither 
|> 	documented in the man-page of rpcgen nor in the RPC-Programming
|> 	Manual.
|> 
|> 
|> 		----- end included message -----
|> --
|> Bus error, core dumped

Furthermore, I would like to add that rpcgen -I doesnt produce stubs that can
be used for TCP RPC servers -- I cant seem to get the RPC handle to the
exec'ed server from my super server.

BTW, I was able to get nowait TCP servers running -- I really dont remeber doing
anything "special" to get them to work -- the stubs seem to work fine.

Doug

-- 
-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713.560.1274
FAX:	  713.560.1277
SNAIL:    Landmark Graphics Corporation LGC	
	  15150 Memorial Drive
	  Houston, TX 77079			
-------------------------------------------

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 93 17:59:30 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.sys.sun.apps,comp.protocols.tcp-ip
Subject:   Re: tcp_mss "downshift" with consecutive rcp's

In article <1993Jan12.003854.5821@cbnewsd.cb.att.com>, pccl@cbnewsd.cb.att.com (paul.c.liu) writes:
|> A while ago, I recall a netter from SGI posted an article
|> detailing a BSD TCP bug fix for the tcp_mss "downshift" symptom.
|> 
|> Symptom: consecutive "rcp remhost:remfil locfil" will result
|> 	 in smaller TCP payload (i.e. from 1460-byte to 512-byte),
|> 	 unless there is 60+ seconds time gap in between.
|> 
|> To reproduce: use three Suns, on sun_a, do 
|> 	rcp sun_b:file1 file1, and
|> 	rcp sun_b:file2 file2
|> 	and run tcpdump/etherfind on sun_c to trace the network traffic.
|> 
|> Pointers are appreciated!
|> 
|> Paul.C.Liu@ATT.COM

I don't know if a fix was given but I think I know what the problem is.

When a SYN segment is received on a TCP in TIME_WAIT, the old TCP end-point
is closed (tcp_close()) and the BSD code jumps back up to start over
processing the SYN segment from scratch (look for the "goto findpcb;").
The problem is that the TCP options (MSS) are processed and discarded in the
first pass and so are missing on the pass that actually creates the new
connection.  The new connection defaults to tcp_mssdflt (roughly 512 bytes).

I ran into this problem while implementing RFC 1323 (window scaling/
time stamps).  The options in the SYN were discarded in those cases
and so window scaling and time stamps wouldn't occur on those
connections.

Apparantly, rlogin and rcp use the SOREUSEADDR flag and they tend to
hit on this problem (since they'll use the same local port number over
as soon as it's available).

This problem will be fixed in the IRIX releases that have RFC 1323
TCP extensions.


-- 
---
Thomas Skibo     Advanced Networking, Silicon Graphics     skibo@sgi.com

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 22:33:30 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <MLEWIS.93Jan11155619@yoyo.telebit.com> mlewis@telebit.com writes:
>
>> mlewis@telebit.com (Mark S. Lewis) writes:
>>>> I currently attach via SLIP over a leased line using v.32bis/v.42bis
>>>> modems from a Dell machine (on my end) into a smartport on a Telebit Netblazer.
 
>>>> Would I see any significant increase in throughput using this same
>>>> physical connection (v.32bis/v.42bis) but replacing the Dell SLIP
>>>> with a Netblazer on my end -- and connecting my machines via ethernet
>>>> to the Netblazer?
>>>> [...] 
>>>> Larry Snyder                                    internet: larry@gator.rn.com
>>>
>>>No I don't think you would get a significant performance increase by
>>>putting a NetBlazer at both ends.  You are using relatively slow
>>>serial lines limited by V.32bis modulation with whatever compression
>>>you get with V.42bis.

Yikes!  And wrong.

DELL does not know about VJ header compression.  The Netblazer certainly
does.  As such, you will see significant improvements in interactive
performance.

>As for memory leakage, we have come quite a ways.  We have made
>numerous improvements to the memory allocation to help us find leaks.
>At this point, there are only a few rare leaks.  In general, the
>NetBlazer will stay up for months.

Now if I could figure out the algorythm for the flipping modemcap.txt
file and how you really talk to modems for dialing and configuration.  There
are some nasties in there that I've yet to figure out....  ;-)

I do agree, however, that in general the Netblazer is a really nice product
for this use.  It does the job and does it quite well.  Multi-month uptimes
aren't rare at all.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900]

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jan 1993 23:11:34 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

karl@ddsw1.mcs.com (Karl Denninger) writes:

>If you can find a driver for the board, certainly ;-)

I was told that morningstar is working on a SCSI product which
will support up to a T1 on a SCSI buss under Dell 2.2



-- 
Larry Snyder                                    internet: larry@gator.use.com
keeper of the Gator                                   uucp: uunet!gator!larry

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 02:58:10 GMT
From:      mpmadhu@picasso.ocis.temple.edu (Madhusudan Muchalambkar)
To:        comp.protocols.tcp-ip
Subject:   RE:How do I Monitor Sun Outgoing Packets

Refer to etherd and traffic.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1993 15:07:35 -0500
From:      feinstn@newsserver.rest.tasc.com (Harlan W. Feinstein)
To:        comp.protocols.tcp-ip
Subject:   hooking into a PC/TC-IP network via modem

I'm trying to figure out what software would be needed to be able to 
perform services like FTP and Telnet from my PC at home.  I have no 
network connections there, simply a 14.4K modem that I can dial in 
with.  Would I necessarily need to be hardwired to the network?  
Please e-mail me any information if possible.  Thanks in advance.

--Harlan

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Harlan Feinstein        The Analytic Sciences Corporation
  hwfeinstein@tasc.com                        NeXTMail okay
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 11:24:23 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

I use tcpdump a lot, so news that the latest version of Ultrix and
SunOS fix the "can't see packets being sent" problem is great!

What about the localhost device lo0? I have a patch that allows
tcpdump to monitor local connections? Will Ultrix/SunOS support this?

Has there been any improvements on the efficiency of nit in SunOS 5.x?

Also - what sort of accuracy does the timestamp have?

Thanks.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 14:32:52 GMT
From:      hq@sapwdf.UUCP (Harald Kuck)
To:        comp.protocols.tcp-ip
Subject:   EADDRINUSE: which UNIX-process is using my port ?

If 2 processes try to use the same port, one of them will fail
with UNIX-errno EADDRINUSE.

The command netstat tells me the connections between the ports    
on my machine and all other machines, but how can I find out
the processes which are involved ???

Thanks for any help !

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1993 15:05:15 GMT
From:      kroell@pu.informatik.th-darmstadt.de (Christoph Kroell)
To:        comp.protocols.tcp-ip
Subject:   Who knows "General Magic" ( = "GM") ?

Who can tell me something about the (tcp-ip ?)
working group "General Magic" ( = "GM") ?
Or where or how can I get to some information
about this group ?

Please mail to
kroell@iti.informatik.th-darmstadt.de


-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 15:24:27 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   PD slip/cslip for SCO 3.2.4?

Does anyone know of a public domain version of slip/cslip that will run
on SCO Unix 3.2.4?  I dislike their version as it takes over the port
and that port has to be dedicated to slip and nothing else.  I'd like to
be able to use that port as a login port as well.  Thanks for any
assistance.

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jan 1993 18:07:35 GMT
From:      john@gecko.pac.sc.ti.com (John Maline)
To:        comp.protocols.tcp-ip
Subject:   shutdown(s, 2) == close(s)?

I'm having a problem with the semantics of the shutdown() system call.
The references I've checked (Comer/Stevens vol 3, vendor docs...)
don't indicate if a close() is required after shutdown().

I'd assume close is required after shutdown(s, 0) or (s, 1), since
that only closes half of the connection and you've still got a viable
socket handle after the shutdown.  shutdown(s, 2) isn't as obvious to
me, since that closes down both parts of the connection.  Sounds
pretty equivalent to close(s) at that point...

To sum up, the subject says it all: is shutdown(s, 2) equivalent to
close(s) (when done on a socket handle)?

I'm maintaining some code and came across this.  The original coder
seems to think they are equivalent.  I'm wondering if we're "leaking"
file handles.

I was thinking of just replacing the shutdown() calls with close(),
since it's always a 2-way shutdown anyway.  Are there any fine
semantic differences I'm missing (aside from my question of file
handle leaks)?

Please respond by mail.  Thanks for any help.
--
John Maline
jmaline@lobby.ti.com   TI MSG: JWMX
Texas Instruments      PO Box 655012 MS 351  Dallas, Tx 75265  214-995-6692

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 18:32:13 GMT
From:      wjq@uts.amdahl.com (Bill Quigley)
To:        comp.protocols.tcp-ip
Subject:   portable, public domain NIT?

Does anyone know of some kind of portable, public domain NIT-type
program?  I can hack my kernel to put the ethernet in promiscuous
mode and pass every packet to a process, but I don't want to write
all of the rest of the packet interpretation code.

-- 
Flower Cake - Trends in food come and go, but
the popularity of cookies never wanes - easy to make, easy to eat.
Bill Quigley
Amdahl - UTS CCE
wjq@charon.amdahl.com

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1993 21:22:06 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <BARNETT.93Jan13062423@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>What about the localhost device lo0? I have a patch that allows
>tcpdump to monitor local connections? Will Ultrix/SunOS support this?

I can't speak for the parts of DEC that engineer and sell products,
but I would not expect ULTRIX to allow you to monitor lo0 using
tcpdump, at least not anytime soon.

>Also - what sort of accuracy does the timestamp have?

You probably mean resolution, not accuracy.  The accuracy depends on
who set your clock, and how well it keeps time.

On ULTRIX, the resolution is that of the system's interrupt clock.
That's 256 Hz (just under 4msec/tick) on RISC hardware, and (if my
memory serves) 100 Hz on VAXen.  It's possible to play some tricks to
change these values, but I would not normally advise doing so.

ULTRIX does ensure that the timestamps are unique and monotonic, which
is why you will occasionally see tcpdump printing packets that appear
to have been received 1 microsecond apart.

-Jeff

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 12:24:00 ACST
From:      gcdcrgp@state.systems.sa.gov.au
To:        comp.protocols.tcp-ip
Subject:   Reference Sites - IBM TCP/IP+RS/6000

We are looking for a reference site.

We are the South Australian Government computing and communications bureau.
We have an IBM 3090 running MVS/ESA.  We are considering installing IBM's
TCP/IP Version 2.2.  IBM are proposing an RS/6000 to act as the
ethernet-to-channel adapter rather than the usual IBM 3172.

Is anyone using this configuration?  If so , we would like to hear from them
(name, org., phone no, fax no, mail address) to (hopefully) get some warm
feelings about the configuration - does it perform to specs? any problems?
would you do the same thing again? is there anything we should know? etc. 

Thanks for your time

Roger Phillips - Data Communications group

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 93 22:53:08 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: shutdown(s, 2) == close(s)?

In article <JOHN.93Jan13120735@gecko.pac.sc.ti.com>, john@gecko.pac.sc.ti.com (John Maline) writes:
| I'm having a problem with the semantics of the shutdown() system call.
| The references I've checked (Comer/Stevens vol 3, vendor docs...)
| don't indicate if a close() is required after shutdown().

	It is.  Shutdown() merely performs protocol actions and
changes the state of the underlying tcp/ip.  You must dispose of
the file descriptor with close() regardless of the option used
with shutdown().

| To sum up, the subject says it all: is shutdown(s, 2) equivalent to
| close(s) (when done on a socket handle)?

	It isn't.  (I repeat myself because this seems a somewhat
popular area of confusion.)

| I'm maintaining some code and came across this.  The original coder
| seems to think they are equivalent.  I'm wondering if we're "leaking"
| file handles.

	Probably...

| I was thinking of just replacing the shutdown() calls with close(),
| since it's always a 2-way shutdown anyway.  Are there any fine
| semantic differences I'm missing (aside from my question of file
| handle leaks)?

	There are some subtle semantics involving shared descriptors.
There were also some special cases for close() in older unix tcp/ip
implementations.  For most current versions, shutdown(,2) followed
by close() is the same as close() itself (excepting timing issues)
provided there is but a single reference to the descriptor.  If
there are multiple references, the situation changes.
	Consider the extreme case where a process has fork()ed and
parent and child share access to a single underlying socket.  Say
the child is blocked in a read() of the socket.  If the parent
uses shutdown(,2) the child will wake up.  If the parent merely
close()s the socket, the child will remain blocked.

				Dan Lanciani
				ddl@harvard.*

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jan 1993 23:16:14 GMT
From:      rich@tsmnet3.melpar.esys.com (Richard Martin)
To:        comp.protocols.tcp-ip,biz.sco.general
Subject:   routing with 1 interface

Can SCO UNIX ODT 2.0 systems route using 1 ethernet interface??  Basically,
it would be nice if one ethernet card could be connected to one
cable that had two different IP numbers.

I would like to configure the IP number of my machine to be 128.1.1.1 and
still be able to talk to systems that have IP #'s 11.?.?.?.  Is this
possiblie ??  I know it will work with two interface cards...

Thanks in advance...


-- 
################################### <--> ######################################
                               Richard Martin
                E-Systems, Melpar Division - Network Engineering
                     Internet: rmartin@melpar.esys.com

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 93 03:21:02 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <1j215uINN82m@usenet.pa.dec.com>, mogul@pa.dec.com (Jeffrey Mogul) writes:
> I can't speak for the parts of DEC that engineer and sell products,
> but I would not expect ULTRIX to allow you to monitor lo0 using
> tcpdump, at least not anytime soon.
> ...

Why?

The security issues don't seem significanty worse than on a real device.

Is it some kind of implementation problem?


Vernon Schryver,  vjs@sgi.com

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 1993 05:23:46 GMT
From:      ae2@cunixb.cc.columbia.edu (Amiran Eliashvili)
To:        comp.protocols.tcp-ip
Subject:   checking on a UDP broadcast message


Hi all:


	I am trying to find the most efficient way of detecting which
hosts has received an UDP broadcast message. One way that might be
most inefficient is to have all the hosts responding back with an ACK.
This scheme is a bit awkward. I was wondering if there is another way
I could check on the broadcast message. Any suggestions are most
welcomed.

Please reply to: ae2@cunixa.cc.columbia.edu

Many Thanks in Advance.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 1993 05:24:20 GMT
From:      adelman@tgv.com (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: Encapsulation of or translation of DECNET on a TCP/IP backbone

In article <15912@hq.hq.af.mil>, parsons@nic.hq.af.mil writes...
>
>--
>Does anyone know of any methods to either convert DECNET to TCP/IP and back
>again or encapsulate DECNET within TCP/IP.  I need to have two DEC sites
>communicate across a large packet-switched TCP/IP backbone.  Unfortunately, it
>will be a somewhat unreliable network where network congestion and delay are
>prevalent.  DECNET is a requirement because of the applications; TCP/IP is a
>requirement for the backbone since it's someone else's empire and corporate
>policy is to use the backbone.

    Our TCP/IP product for VMS, MultiNet, lets you encapsulate DECnet
in either UDP (low overhead; works best on reasonably reliable networks)
or TCP (more overhead; harder to configure; but what you need for an
unreliable network). Give us a call at 800-TGV-3440 if you'd like
a free evaluation.

								Ken

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1993 19:53:02 -0800
From:      markb@spock.dis.cccd.edu (Mark Bixby)
To:        sci.space.shuttle,sci.space,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Broadcasting shuttle audio over the Internet?

An article posted recently to sci.space.news mentions that some folks at
NASA will be broadcasting NASA SELECT shuttle mission audio over MBONE and
the Internet.  Where can I go to learn more about this audio broadcasting
protocol?  I.E. what RFC numbers, hardware requirements, FTP software
repositories, etc...
-- 
Mark Bixby                         Internet: markb@cccd.edu
Coast Community College District   1370 Adams Avenue
District Information Services      Costa Mesa, CA, USA  92626
Technical Support                  (714) 432-5064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 93 10:07:54 GMT
From:      tsv@elvis.sovusa.com (Igor Tsvetkovsky)
To:        comp.protocols.tcp-ip,comp.sys.sun.apps,comp.sys.sun.misc
Subject:   Rebuilding Sun kernel for multicasting

  I took sourses for ip-multicast from ftp directory
vmtp-ip on gregorio.stanford.edu. For SunOS 4.1.* there exists
sources only for sun4c, but i need them for sun4 (SUN4-260)
and for sun3, too. 

  I try to build multicast kernel on SUN4-260 SunOS 4.1.1, but
there were errors:

        # make

        loading vmunix
        Undefined
        _addmultiaddr
        _delmultiaddr
        _map_regs
        _adddma
        _slaveslot
        _dvmamap
        _getprop
        _report_dev
        _ledriver
        *** Error code 2
        make: Fatal error: Command failed for target `vmunix'

    Can anybody help me?

    Thanks!

Igor Tsvetkovsky
Mail : tsv@elvis.sovusa.com



-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1993 11:18:56 GMT
From:      antonis@helios.ntua.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   ftp/NOOP

Hi

I'm running ftptool (a SPARC executable for ftp) to connect to
an internet host and I get following message

	200 NOOP command successful.
	257 "/" is the current directory.
	200 Type set to A.
	200 PORT command successful.
	425 Can't build data connection: Host is unreachable.

Nevertheless, I get without problems a connection to any of our local
machines (SUNs & DECs), and I've never seen such a message when using
ftp.

Any ideas?

thanks in advance

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

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 93 14:24:47 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <1j215uINN82m@usenet.pa.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes:
>   ULTRIX does ensure that the timestamps are unique and monotonic, which
>   is why you will occasionally see tcpdump printing packets that appear
>   to have been received 1 microsecond apart.

Interesting. I can see how you make sure the timestamps have at least
1 microsecond difference. What about changes in the system clock?

I had to add smarts to a script because I was doing a
tcpdump for more than 24 hours, and the measurement system did an
"rdate" at midnight. The change in time was immediate, and it threw
off my calculations for packets per 60 second slice. (I should be
using ntp, I know.) 


Here is an extreme case, for our amusement.... :-)

	You set the date wrong (January 14 1994)

	Start tcpdump.

	Realize the date was wrong, and correct the date (January 14, 1993)

	Wait a while.

	Stop tcpdump.

I would think there would be some combination (maybe not a year) where
tcpdump would generate two timestamps with the same value.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 1993 15:27:17 GMT
From:      larry@shark.mitra.com (Larry Williamson)
To:        comp.protocols.tcp-ip
Subject:   Efficiency of routing to subnets on one enet cable


Is there any real performance penalty in the following senario?

I put three machines on one ethernet cable. Each machine has only one
ethernet interface.  I put machine one (m1) on one subnet (let's say
192.1.1.0) and machine two (m2) on another subnet (say 192.1.2.0). I
configure the routing table on machine three (m3) to know about both
subnets. Machines m1 and m2 have a default routing entry that uses m3,
ie. "route add default m3 1".

What if any performance penalty is there to this setup as compared to
having m1 and m2 route directly to the other subnet, ie.
    on m1 "route add m2 m1 0"
and on m2 "route add m1 m2 0"

Ping -s shows ICMP Host redirect messages for each ping packet when I
use the default routing through m3. Yet massive ftp transfers don't
seem to be affected by that setup. The tranfer times for moving (in
binary mode) 20Meg files from m1 to m2 is about the same whether I use
a default route through m3, or a direct route to the other subnet.

If it makes any difference, all machines are Sun IPC's run SunOS 4.1.2


-Larry

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 1993 17:03:41 GMT
From:      scrouse@husky1.stmarys.ca
To:        comp.protocols.tcp-ip
Subject:   Wanted: IP-IPX router S/W for PC


I looking for routing software that will run on a PC, and will
1) route both TCP/IP and IPX and 2) route between serial and
ethernet interfaces.
OR
a another solution to our problem.

The Configuration:
We have a couple of off campus offices that require access to our
central systems and some novell mail transfers.  Currently, for each
office we have PCs (running PCbridge) that are hooked into ethernet
on and connect (via modems/leased line) the off campus sites.
The PCs in the off campus offices "did" run most PC applications from their 
hard drives and use the network to connect to our VAXes via telnet.

The Problem:
One of the offices just installed a novell server and now we are finding
that a lot of our PCs are trying to boot from this remote Novell server -
which is a very slow process over a 19200 baud line.

The Possible Solutions:
1) buy a serial card for our Cisco router and use it's SAP routing/filting
capibilities to direct SAP requests.  Problem - $$$$$$
2) get router software to replace PCbridge that has the capability to route
IPX and IP.  Problem - can not find approate software.

If you know of any such software or if you have any suggestions/solutions,
please send messages directly to me as normally don't follow this news
group (I will summarize and post the responses, if there is enough interest).

I should also mention that money is scarce, but a commercial package
in not out of the question.

Steve
===============================================================================
Steve Crouse
VAX Systems Manager        	Internet: SCrouse@Husky1.STMARYS.CA
Saint Mary's University         Bitnet  : SCrouse@STMARYS
Halifax, Nova Scotia            Telphone: (902) 420-5476
Canada  B3H 3C3                 Fax	: (902) 420-5115

Murphy's Law #11 "It is impossible to make something foolproof because
                  fools are so ingenous"
===============================================================================


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1993 17:42:55 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp/NOOP

In article <1j3i70INNccf@pythia.csi.forth.gr> antonis@helios.ntua.gr (Antonis Kyriazis) writes:
>	425 Can't build data connection: Host is unreachable.
>
>Nevertheless, I get without problems a connection to any of our local
>machines (SUNs & DECs), and I've never seen such a message when using
>ftp.

Sounds like you have a packet filter at your gateway, which is rejecting
the server's attempt to connect to your system for the data connection.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 1993 18:49:10 GMT
From:      rhealey@rogue.digibd.com (Rob Healey)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <BARNETT.93Jan13062423@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
|> I use tcpdump a lot, so news that the latest version of Ultrix and
|> SunOS fix the "can't see packets being sent" problem is great!
|> 
	SunOS 5.1, Solaris 2.1, can see packets it sends on the ethernet.
	Don't know about the loopback port though. The snoop command is
	part of the OS and IMHO is better than tcpdump for most network
	snooping purposes. It is VERY good at decoding the guts of an
	ethernet packet in to PLAIN ENGLISH, much easier than trying to
	decode TCP options in one's head by reading hex digits. Snoop
	allows various boolean operations for filtering from the command
	line and let's you catch packets to a file and then analyze them
	later. It's timestamp claims better than 60Hz resolution.

	The REAL plus is snoop decodes NIS+ operations as well as ip, tcp,
	udp, NIS and others. This allows for decent NIS+ debugging.

	Nice tool, I suggest all Solaris 2.1 admins bone up on the command.

|> Has there been any improvements on the efficiency of nit in SunOS 5.x?
|> 
	Dunno. They use the UNIX networking DLPI interface rather than
	NIT per say although the effect is the same. It's a shame USL
	never got ahold of snoop for other SVR4 systems, I'd kill for
	snoop on an Intel box running SVR4... DLPI has some very interesting
	features for accessing network hardware at a low level including
	promiscuous mode, multicasting and network adapter parameters.

|> Also - what sort of accuracy does the timestamp have?
|> 
	Looks like they are using a high resolution timer on it now.

		-Rob

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1993 19:44:55 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: reading what you're writing on Suns

In article <BARNETT.93Jan14092447@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>In article <1j215uINN82m@usenet.pa.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes:
>>   ULTRIX does ensure that the timestamps are unique and monotonic, which
>>   is why you will occasionally see tcpdump printing packets that appear
>>   to have been received 1 microsecond apart.
>
>Interesting. I can see how you make sure the timestamps have at least
>1 microsecond difference. What about changes in the system clock?

I was slightly inaccurate.  ULTRIX ensures that timestamps are unique
and monotonic as long as the system clock is not set backwards using
the settimeofday() system call.

>I had to add smarts to a script because I was doing a
>tcpdump for more than 24 hours, and the measurement system did an
>"rdate" at midnight. The change in time was immediate, and it threw
>off my calculations for packets per 60 second slice. (I should be
>using ntp, I know.) 

Yes, you should be using NTP.  The ULTRIX NTP daemon (/etc/ntpd)
never ever uses settimeofday() to set the clock backwards.

Wise system managers never use rdate, except in /etc/rc* to give
the NTP daemon a clean start.

-Jeff

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 1993 20:26:47 GMT
From:      paulb@hyphen.com (Paul Bournival)
To:        comp.protocols.tcp-ip
Subject:   fcntl() to set non-block mode doesnt seem to work Sunos 413

Hi All!

  I am trying to use the fcntl(2V) call to set the non-blocking mode
on a socket (and, in another spot, on a fd pointing at the audio device.)
Here's exactly what I'm doing:

        if (fcntl(wellKnownFD,F_SETFL,O_NDELAY)<0) {
                fprintf(stderr,"cant set non-block mode for socket.\n");
                exit(1);
        }

   This test proceeds successfully. However, calls to select(2) block while trying
to determine if there's input available on the socket.  I think select, read,
and write should return -1 (and EWOULDBLOCK). Does anyone know what I'm doing
wrong?
   I'm using SunOS 4.1.3 on a Sparc ELC, and GNU C (don't remember the version.)
However, I tried compiling under acc (well respected commercial compiler),
with similar results.
   Thanks in advance for any ideas or help!
Paul Bournival (paulb@hyphen.com    paulb@world.std.com)

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jan 93 22:15:15 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   RPC protocol specifications

I would appreciate if someone could tell me how the RPC protocol 
specifications can be obtained. Are they proprietary, or freely
available on the internet ? (I am interested in the protocol 
specification of the "portmapper").

Thanks, 

Maritza

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1993 23:00:02 GMT
From:      scoggin@delmarva.com (John K. Scoggin, Jr.)
To:        comp.protocols.tcp-ip
Subject:   Network Management Tools for Internets

I am looking for sources to 2 tools mentioned in the Internet System Handbook
(Lynch/Rose) -

	NCNS	- A network performance measurement package from CMU (?)
	NNam	- Internet analysis tool (Merit?)

I have looked on Archie to no avail.  Does anyone know who to contact to
obtain information on these tools?

	- John

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
+---------------------------------------------------------------------+


-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 1993 03:10:48 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC protocol specifications

In article <1993Jan14.221515.22259@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
>I would appreciate if someone could tell me how the RPC protocol 
>specifications can be obtained. Are they proprietary, or freely
>available on the internet ? (I am interested in the protocol 
>specification of the "portmapper").
>
The port mapper protocol specification is in Appendix 1 of RFC 1057.

Bill



-- 
Bill Warner						(317)494-1787
General Consultant					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 1993 03:11:23 GMT
From:      reh@wam.umd.edu (Richard Huddleston)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Subnet fields > 8 bits : question

I'm trying to get an explanation, and references, to a question about
subnet fields on Class B Internet addresses which are greater that 8 bits
in width.  Assume, first, that we *can* define subnets greater than 8
bits ( and I say this because I haven't found an example of this in the
RFCs I've read so far -- although I would love to find a reference! ).
 
Let's say that the network ID portion of the address is 155.155:
 
1001 1011 . 1001 1011
 
and, for the sake of simplicity, that we want to add a 14 bit subnet
field with two bits left over for hosts at that subnet.
 
I'm a little confused as to how the remaining octet numbering would go.
Part of my confusion comes from never having worked with subnet masks
greater than 8 bits, so that the possibility of a 0-filled octet is
accounted for.
 
Is the first subnet / host address like this:
 
1001 1011 . 1001 1011 . 0000 0001 . 0000 00-01 (<--last two bits are host)
(155.155.1.1)
 
this:
1001 1011 . 1001 1011 . 0000 0000 . 0000 01-01
(155.155.0.5)
 
this:
1001 1011 . 1001 1011 . 0000 0001 . 0000 01-01
(155.155.1.5)
 
this:
1001 1011 . 1001 1011 . 0000 0000 . 0000 00-01
(155.155.0.1)
 
or, something else entirely ( and if so, what? )
 
Answers appreciated; references REALLY appreciated!
 
 

-- 
Richard Huddleston
University of Maryland at College Park

Personal opinions

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1993 10:24:34 GMT
From:      kroell@pu.informatik.th-darmstadt.de (Christoph Kroell)
To:        comp.protocols.tcp-ip
Subject:   Mobile tcp-ip? Via satellite or cellular radio?

Hallo world!

I'm working on a lecture on the subject of "mobile datacommunication"
at the Technical University of Darmstadt in Germany witch should
inclose cellular radio and satellite systems as well as
used protocols, software and hardware.

Is there anywhere an approach to use TCP/IP for mobile data transfer
in any mobile communication system of the world ?
Who knows actual literature or working groups , institutes or companys
working on this item ?

If you can give me any pointer on this topic, please mail to
kroell@iti.informatik.th-darmstadt.de .

Thank you in advance for your assistence.

Christoph Kroell.



-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1993 11:47:42 GMT
From:      antonis@intranet.gr  (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: Rebuilding Sun kernel for multicasting


I got similar messages by trying to make it under 4.1.2.

|     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



-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 1993 12:28:22 GMT
From:      anton@analsyn.gts.org (Anton J Aylward)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In the article (<C0r1yp.3o4@ddsw1.mcs.com>) Karl Denninger (karl@ddsw1.mcs.com) posted to biz.comp.telebit.netblazer:
: In article <C0oBxC.Bvr@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
 
: >Also, is it possible to put a v.35 board in a machine running Dell 2.2
: >and do the routing under Unix?
 
: If you can find a driver for the board, certainly ;-)

Thats one BIG if.
I've been looking for a while nwo with no sucess.
I may end up writing my own!


--
Anton J Aylward						
	"The body politic is swerving from left to right and right to
	 left looking for quick fixes for systemic problems."
	   - Paul Palango, Journalist, ex The Globe and Mail

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 1993 15:06:13 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet fields > 8 bits : question

In article <1993Jan15.031123.2686@wam.umd.edu> reh@wam.umd.edu (Richard Huddleston) writes:
>I'm trying to get an explanation, and references, to a question about
>subnet fields on Class B Internet addresses which are greater that 8 bits
>in width.  Assume, first, that we *can* define subnets greater than 8
>bits ( and I say this because I haven't found an example of this in the
>RFCs I've read so far -- although I would love to find a reference! ).
> 
Subnet fields can certainly be greater than 8 bits.  RFC 1122 section 3.2.1.3
states that the minimum size of the host (or subnet) field in an IP address is
2 bits.  So, if the host field is 2 bits then the subnet field must be 14 bits
(for a class B address).

>Let's say that the network ID portion of the address is 155.155:
> 
>1001 1011 . 1001 1011
> 
>and, for the sake of simplicity, that we want to add a 14 bit subnet
>field with two bits left over for hosts at that subnet.
> 
>I'm a little confused as to how the remaining octet numbering would go.
>Part of my confusion comes from never having worked with subnet masks
>greater than 8 bits, so that the possibility of a 0-filled octet is
>accounted for.
> 
>Is the first subnet / host address like this:
> 
>1001 1011 . 1001 1011 . 0000 0001 . 0000 00-01 (<--last two bits are host)
>(155.155.1.1)
> 
>this:
>1001 1011 . 1001 1011 . 0000 0000 . 0000 01-01
>(155.155.0.5)
> 
>this:
>1001 1011 . 1001 1011 . 0000 0001 . 0000 01-01
>(155.155.1.5)
> 
All of the above addresses are valid.  You can number your subnets *any* way
you want.  Which one is "first" and what order you number in is entirely up to
you.

>this:
>1001 1011 . 1001 1011 . 0000 0000 . 0000 00-01
>(155.155.0.1)
> 
This is not a valid host address.  This violates RFC 1122 section 3.2.1.3 which
says that none of the fields in an IP address (network, subnet, or host) can
consist of all zeros or all ones.  (Except in certain strictly defined special
cases, like broadcast addresses.)

Bill


-- 
Bill Warner						(317)494-1787
General Consultant					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 93 20:37:28 GMT
From:      echan@skynet.intel.com (Eldon Chan ~ )
To:        comp.protocols.tcp-ip
Subject:   Vendor numbers for ethernet addresses

Would someone tell me what vendor has ethernet address prefix 
       00:00:81
?
I checked the rfc1340 (Assigned numbers), but it's not in there. Anyone have a
more updated list ?

Thanks much.

-- 
Eldon Chan                   
Intel Corpoartion
Design Technology 
Networking group                   Phone: 408-765-4992
echan@scdt.intel.com               Fax:   408-765-5719

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jan 1993 22:31:36 GMT
From:      stuarts@news.apertus.com (Stuart Stanley)
To:        comp.protocols.tcp-ip
Subject:   IP rollover


Heres an odd thought we were having around here:  Would it be possible
to create an IP rollover service that would allow a person to connect
to a given ip address, that would either reattach the connection to 
a different number (assigned from a bank of numbers) or maybe route all the
packets for the given connection.  Errr, basicaly a IP rotary ala a dial-in
rotary common with modem pools.

I was thinking that it might be possible to make a "router" that picks off
packets destined to IP.address.1 and "patch" the source and destination to
point to the "router" and IP.address.load_shared_ip and then drop the
packet back out onto the wire.  From this, I have three questions:

	1) Can anyone see a reason why this might not work/be wise.  
	    (Other than the doubled network traffic).  

	2) Has anyone seen anything like this before? (where is it if so?)

	3) Does anyone know of any router source for either svr5 or just
		a stock PC that I can pick up from a ftp site?


I will post a summary if I get anything interesting out of this question...

Cheers,

--
"Seems lately that I'm doubling as Storm bait"  !    Stuart Stanley
              Nanci Griffith                    !    stuarts@apertus.com
         (Late Night Grande Hotel)              !    Apertus Technologies
                             (612)-828-0391    <->   Eden Praire, Minnesota

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1993 22:39:27 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet fields > 8 bits : question

In article <1993Jan15.031123.2686@wam.umd.edu> reh@wam.umd.edu (Richard Huddleston) writes:
>and, for the sake of simplicity, that we want to add a 14 bit subnet
>field with two bits left over for hosts at that subnet.

Note that this only allows for two hosts on the subnet, because addresses
with the host field all 0 and all 1 are reserved.

But this may be just the right thing if all the subnets in this network are
point-to-point links.

>Is the first subnet / host address like this:
>1001 1011 . 1001 1011 . 0000 0000 . 0000 01-01
>(155.155.0.5)

Yes.

Just ignore octet boundaries when dealing with addresses with subnet masks.
The IP address is just a 32-bit binary string, and the subnet portion is
just a 14-bit field.  Strictly speaking, the subnet field doesn't even have
to be contiguous, but I've heard of implementations that don't handle
noncontiguous subnet fields well (but I've also heard of implementations
that don't handle non-octet-aligned subnets, either).

>this:
>1001 1011 . 1001 1011 . 0000 0000 . 0000 00-01
>(155.155.0.1)

The problem with this is that it uses subnet 0.  As with host numbers,
all-0 and all-1 subnet numbers are reserved.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 93 23:01:48 GMT
From:      bobw@mge.uucp (bobw)
To:        comp.protocols.tcp-ip
Subject:   Routing with 3 class C net addresses

Hello,

We're currently creating a TCP/IP network to link together 18
different sites. The sites are of different sizes, and they will be
linked together with routers which will connect them via the national
ISDN network. The primary need is to transfer data between the sites.

We recently obtained three class C addresses, and we'll be subneting
within each network address. Since the sites are of different sizes,
to use the address space effectivly, we would like to use a different
subnet mask for two of the three sites. This brings up several
questions.

1. I assume that as long as the same subnet mask is used on a network,
there is no reason why we cannot use different masks on each of the
nets. Is this correct?

2. What do the routers "see"? To get from site one to site two I may
be on a subnet on the same network, or on a subnet on another network.
What would the static routes in the hosts look like, and what do those
in the routers look like?

3. What happens to a domain name? I understand a domain name to be
equated with a network, and not three separate nets.

Thanks for any ideas.

Please respond by e-mail, as I don't often have access to this
newsgroup.

Regards,

Bob
--
Robert Wornan		| uucp: bobw@mge.uucp
MG Entreprises		| internet: bobw@mg-entreprises.fr
42 rue Voltaire		| tel: +33 1 42 04 35 83
92800 Puteaux,	France	
-- 
Robert Wornan		| uucp: bobw@mge.uucp
MG Entreprises		| internet: bobw@mg-entreprises.fr
42 rue Voltaire		| tel: +33 1 42 04 35 83
92800 Puteaux,	France	

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jan 1993 01:15:00 GMT
From:      Michael T. Keefe
To:        comp.protocols.tcp-ip
Subject:   Winqvtnet SLIP help... fine tuning help needed

Thanks to the insightful mail here, I have been able to get Winqvtnet working
over a SLIP connection (modem is a Courier Dual Standard).

I am getting the following error messages when using either the FTP or mail facility in the program:

IP: fragmented packet received, frags not supported
IP: apparent packet length error
IP: bad version number
Packet received for invalid port -- reset sent

Anybody have any ideas how I could fine tune my system to get rid of these error messages?

I am loading in the 3-pre windows files with the following parameters:

       SLIP8250 -w 0x62 -h SLIP 4 0x03f8 38400
       WINPKT.COM  0x60  0x62
       PKTINT.COM

The problem is, I really have no idea where to look in order to correct the above.
Thanks in advance


=======================================
||\/|| || ||/  ||==   Michael T. Keefe
 \  /| || |//  ||      
||  || || |\   ||==     Listening is an art which requires
||  || || |\\  ||       the skilled characteristic of listening
||  || || ||\\ ||==

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 93 15:52:07 GMT
From:      mperlman@nyx.cs.du.edu (Marshal "Airborne" Perlman)
To:        sci.space.shuttle,sci.space,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Broadcasting shuttle audio over the Internet?


messages always help to have text attached to them..
--
|o| Marshal Perlman                             Internet: perlman@cs.fit.edu |o|
|o| Florida Institute of Technology                              IRC: Squawk |o|
|o| Melbourne, Florida                                   Private Pilot, ASEL |o|
|o| 407/768-8000 x8435                            Goodyear Blimp Club Member |o|

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jan 1993 16:41:33 GMT
From:      larry@news.rn.com (Larry Snyder)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

anton@analsyn.gts.org (Anton J Aylward) writes:

>In the article (<C0r1yp.3o4@ddsw1.mcs.com>) Karl Denninger (karl@ddsw1.mcs.com) posted to biz.comp.telebit.netblazer:
>: In article <C0oBxC.Bvr@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
 
>: >Also, is it possible to put a v.35 board in a machine running Dell 2.2
>: >and do the routing under Unix?
 
>: If you can find a driver for the board, certainly ;-)
 
>Thats one BIG if.
>I've been looking for a while nwo with no sucess.
>I may end up writing my own!

I believe I might have mentioned that Morningstar is working on a v.35
connection for the SCSI buss that will support up to a T1.  Should be
real neat -- and they plan on even supporting Dell 2.2!

-- 
Larry Snyder                                    internet: larry@gator.use.com
keeper of the Gator                                   uucp: uunet!gator!larry

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 93 17:16:27 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC protocol specifications

Maritza Ramirez (maritza@espresso.bae.bellcore.com) wrote:
: I would appreciate if someone could tell me how the RPC protocol 
: specifications can be obtained. Are they proprietary, or freely
: available on the internet ? (I am interested in the protocol 
: specification of the "portmapper").

The RPC protocol is in the public domain, although it was invented at
Sun Microsystems.  You can find information in RFCs 1014 and 1057, or
in the Nutshell book, "Power Programming with RPCs" published by
O'Reilly and Associates last year ('92).  I don't know off hand where
you would find out specifically about the portmapper, and I don't think
that these RFCs cover it.

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

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jan 1993 23:55:01 GMT
From:      xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting date and time on PC

In article <1993Jan12.031512.16593@samba.oit.unc.edu> tclark@med.unc.edu (Thomas B. Clark III) writes:

>Does anyone have any experience setting the PC's date and time
>from a UNIX time server using tcp/ip?

Yes, at our and many other universities we do it on most PCs all the time
using PDCLKSET. Here is the readme.1st file:

Jan E LDC


PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.

It can use BOOTP to get IP number and other info.
PDCLKSET talks to the network card via a packet driver.

PDCLKSET can assign the proper normal or dls timezone name to
an environment variable (TZ is used by most systems).

There is also a very powerful buildt in ping/echo client and server giving
important statistics on delay, load and packet loss.

The PDTBUILD program, which is included in the ZIP package, looks
at all ARP broadcasts and generates hardware address tables with all the IP 
hosts on this (sub)net. It detects IP and hardware address duplication.

And still, PDCLKSET is so small (13 KB) you can use it even on 
diskette-only PCs.

For more info, see file PDCLKSET.DOC.

PDCLKxxx.ZIP is available at msdos.ftp.sunet.se:pub/network/pdclkset,
ftp.lu.se:pub/network/pdclkset, wsmr-simtel20.army.mil:PD1:<MSDOS.PKTDRVR>,
oak.oakland.edu:pub/msdos/pktdrvr, wuarchive.wustl.edu:mirrors/msdos/pktdrvr,
nic.funet.fi:pub/msdos/networks/pktdrvr, and probably other Simtel mirror
archives.

Happy timesetting!
                                             

_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458, Telefax: +46 46 138225, Telex: 33533 LUNIVER S
E-mails: Jan.Engvald@ldc.lu.se,  xjeldc@seldc52,  psi%2403732202020::xjeldc

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1993 05:04:09 GMT
From:      ralf@wpi.WPI.EDU (Ralph Valentino)
To:        comp.os.mach,comp.protocols.tcp-ip
Subject:   SLIP under Mach 3.0

Has anyone gotten SLIP to work under Mach 3.0?  /etc/slattach from
2.6MSD reports "ioctl(TIOCSETD): No such device" when run under 3.0
mk77 ux37.

Is there a publicly available version of SLIP that will work with Mach
3.0?  Are there patches available to the kernel or emulator?

-Ralph
===============
Ralph Valentino   (ralf@chpc.org)  (ralf@wpi.wpi.edu)
Hardware Engineer,  Worcester  Polytechnic  Institute
Center for High Performance Computing, Marlborough MA

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jan 1993 12:32:43 GMT
From:      bill@wrangler.WLK.COM (Bill Kennedy)
To:        comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

In article <C0yH19.AF1@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>
>I believe I might have mentioned that Morningstar is working on a v.35
>connection for the SCSI buss that will support up to a T1.

They're not working on it, they've been shipping it for over a year.  It's
called SnapLink and it's V.36, not V.35 (most CSU/DSUs can be ordered with
V.36 or you can get a converter) and it handles an aggregate bit rate of
2.048Mbps through three spigots and a SCSI.

>Should be
>real neat -- and they plan on even supporting Dell 2.2!

They already support it on several platforms.  I used it on SPARC and they
assured me it would work with any of their supported systems.  In the Intel
world that means ISC, SCO, and BSDI, maybe others.  It appears to the
kernel as a raw disk device and the Morning Star drivers handle the details.

A couple of caveats and they're neither complaints nor criticisms.  The
SnapLink is quite small so they use the subminiature D connector for the
SCSI bus.  There are a number of places who make adapter cables, I happen
to like CS Electronics in Tustin, CA.  Also, V.36 and V.35 are not the
same.  V.35 is that boxy looking thing with the screws through it, V.36 is
a DB37.  As if the connector details weren't enough, V.36 is differential
and V.35 isn't.  Be sure that what ever you hook it to is the right one.
I've run SnapLink at T1 speeds and it worked beautifully.  Presumably you
could even do fractional T3 and stay within the 2.048Mbps limit but I have
not tried it.  Finally, make sure you strap it for an appropriate SCSI ID.
It ships (or used to) as ID 3 and that's Sun's default boot disk.

SnapLink isn't a future, you can buy one today if you have an OS they
support and V.36 telecomm gear.  I don't know what they're doing about
Dell 2.2 but I am dead certain they do ISC 3.x and even the old 2.2 (I
bought two licenses for that).  It's a nice package and if you don't
need all of the modem handling goop in a NetBlazer, it's a painless plug
and play solution.  By "painless" I mean that for a simple setup you can
eliminate a lot of stuff you might not otherwise want/need (a router
comes to mind), just hook up the hose and go.
-- 
Bill Kennedy            bill@WLK.COM  | Where there's a will there's a won't.
                                      | NAPA auto parts commercial.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jan 1993 16:37:01 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Address conversion


In article <giT8wB1w165w@major.panix.com> dos@major.panix.com writes:

>What I'm looking for is something along the lines of a router than could
>hold an address translation table (which would, of course, have to be
>generated by hand, but that's no problem), and convert addresses going
>in both directions.

Yes,

I'm looking into this situation too.  However, our requirement for address 
translation is for some different reasons - we are in the health 
field and have potentially thousands of IP entities (PCs, hubs, SNMP 
agents, bridges etc. over 60/100 LANs, but only a small amount of 
(true, ie. registered) Class B address space to work with.  (We've been 
allocated the last 11 bits of a Class B (16 bit) "host" address space).
This allows us 32 LANs with 64 PCs on each (nowhere near enough!)

We are thinking along the lines of pooling the true addresses on 
a first come, first served basis, for internal users who wish to
have real time access (e.g. FTP, Telnet) to the outside world
(ie. the Internet).  WE plan to use a private (non-registered Class A
IP address structure **internally**.  

However, we will need an address translation process, which we think 
could be invoked on a router, particularly one based on UNIX or 
DOS, where one could pass each packet to the "address translator" 
before forwarding it.  I believe it's workable.

Do you have a problem with mapping the number of users on 
your second network, with the size of the "real" address space 
you've been allocated?

Please keep me (or this group) informed of any leads, suggestions
or comments in this matter; I will let you know if we do.

Have you read RFC1335 "Two Tier address structure.... A solution to
..address space exhaustion"  (Wang & Crowcroft, Univ. College, London)?
It's good and throws some light on the issues.


Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      |         (OSI & GOSIP specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jan 1993 17:10:24 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   IP rollover


In article <C0x2Kp.FI9@apertus.com> stuarts@news.apertus.com writes:

>
>I was thinking that it might be possible to make a "router" that picks off
>packets destined to IP.address.1 and "patch" the source and destination to
>point to the "router" and IP.address.load_shared_ip and then drop the
>packet back out onto the wire....


Yes, excellent idea.  An organisation I am working for needs that too.

One real problem is that of late replies (from the Internet), being
sent to the **new** recipient...   This is a real problem with any 
form of random address assignment.  The same as (say) 20 mobile
technicians, of whom 10 need to be out of the base at any time, sharing
 a pool of (say) 10 mobile phones. No user can rely on having the same
phone (or IP address) two days running.....

Could you explain your problem more?


Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      |         (OSI & GOSIP specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jan 1993 18:17:59 GMT
From:      rick@nsscmail.att.com (Rick Calder)
To:        comp.protocols.tcp-ip
Subject:   CSLIP : Exact setups w/ SVR4 slip also ??

	I've scarfed back the cslip for SVR4, but the docs don't give me enough
info on how to set it up.
	Can someone email/post their inetinit.cf file, and the slipd.conf if
they are used ??
	The confusion is that the ifconfig needs to know the interface, yet
there isn't one defined in the inetinit.cf.  Even so, it seems that it
should get set from the slip.hosts and slip.config, but I don't see how.  Sigh.

			thanks in advance,

-- 
		Rick Calder, NCR Systems Support Center - New Jersey
		      [att!]rick!rick     rick@rick.att.com
				attmail!rcalder

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jan 1993 05:41:12 GMT
From:      ae2@cunixa.cc.columbia.edu (Amiran Eliashvili)
To:        comp.protocols.tcp-ip
Subject:   multicasting


Greetings all:


Does anyone have any experience with multicasting with sockets using
UDP? If so, can you please shed some light on this matter --
references, examples or a paragraph or two would be highly
appreciated.


Thanks much

/amiran

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 93 12:23:51 GMT
From:      uclyjjd@ucl.ac.uk (Julian Daley)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Slow ftp transfers with pktmux


Im trying to set up my pc using pktmux to let me load PCNFS and 
then use CUTCP telnet, ftp etc.   

This works fine, except for ftp.

*Without* pktmux, CUTCP's ftp gives me a transfer rate of approx
180 kbytes/sec to or from a Sun unix box, on the local ethernet.

*With* pktmux the transfer rate for PC-unix transfers is approx
60 kbytes/sec, and unix-PC transfers go down to just 9k bytes/sec.

NFS transfer rate isn't effected, about 200k bytes/sec for reads 
from a unix box, 100k bytes/sec for writes.

I realise pktmux is doing some very clever things, but this decrease
in ftp performance does seem a bit dramatic, especially as the NFS 
performance is unaffected.

I'm using
BICC 16 bit ethernet card
ISOLINK packet driver V10.2
PKTD.SYS V4.0.a3
PKTMUX V1.2a

Any ideas ?
Julian.

--
        _____________________________________________________
       | Julian Daley,                     j.daley@ucl.ac.uk |
       | Department Clinical Physics, Guys Hospital, London. |
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jan 1993 13:00:31 GMT
From:      brians@atlastele.com (Brian Sheets)
To:        comp.protocols.tcp-ip,comp.sys.sequent
Subject:   Nameserver help?

I have set up a nameserver on my machine and some weird things are happening and
I was wondering if someone could help me out.

I am running Dynix 3.0.17.10  on an S3 using a dialup slip connection to PSI
The probles I see are, 1) when I lose my connection I can't seem to talk on 
my local ethernet, When I telnet in to the the system  it is very slow with 
a login  prompt. One really weird thing is that "talk" say "target machine does not 
recoginize you". This happens whenever I am using named.


Can someone help me out here???
-- 
Brian Sheets		    _   /|  	"TRUCK?! What truck?"
Support Engineer  	    \`o_O'    	 
Atlas Telecom Inc. 	      ( ) 	   -Raiders of the Lost Ark
brians@atlastele.com           U

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jan 1993 18:33:16 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.telebit.netblazer,comp.protocols.tcp-ip
Subject:   Re: Netblazer

(This is way off the charter of either of these newsgroups, it's
unrelated to the "Subject:" line, and I don't want to sound too
commercial, but I thought I'd clear up a couple of nits...)

In article <1993Jan17.123243.11474@wrangler.WLK.COM> bill@wrangler.WLK.COM (Bill Kennedy) writes:
   In article <C0yH19.AF1@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
      I believe I might have mentioned that Morningstar is working on
      a v.35 connection for the SCSI buss that will support up to a
      T1.

   They're not working on it, they've been shipping it for over a
   year.

His "working on it" was in regard to our Dell port, I think.  And
that's a little optimistic - we haven't started yet, though we have
MST PPP running on other SystemV's and it should be a straightforward
port.  We're considering it, but we don't even have a copy of Dell's
UNIX here.

   It's called SnapLink and it's V.36, not V.35 (most CSU/DSUs can be
   ordered with V.36 or you can get a converter)

Most CSU/DSU makers call it RS-449.

   Presumably you could even do fractional T3 and stay within the
   2.048Mbps limit but I have not tried it.  

I suspect you'd just start seeing more bit losses.  It's just a cheap
little MC68302, don't expect too much from it!
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jan 1993 20:23:33 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Who used TNAMED (IEN-116) any more?  And why?


Some of the 3Com terminal servers use it if you set a certain soft switch.

	I was trying to set up a 3Com terminal server, once, and forgot to
set the switch correctly.  The terminal server, of course, couldn't find
out the IP number of any host on our network.  I bet, though, that some 
IEN116 packets were flying around each time I told the server to initiate
a telnet connection to a named host.  When I told it to use the DNS, everything
woke up.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jan 1993 21:35:11 GMT
From:      rhodes@da_vinci.it.uswc.uswest.com (William Rhodes)
To:        comp.protocols.tcp-ip
Subject:   tn3270 question


I have two questions about tn3270 (tn3270 is a telnet session that provides
IBM 3270 terminal emulation).  My first question is where to find information
about the tn3270 protocol. I pulled code off the net but there was no 
documentation.

My second question pertains to the tn3270 server portion.  General this runs
on a remote gateway having direct access to the main frame host.  I'm trying
to locate public domain code to modify to run on a UNIX server inorder to
convert the tn3270 protocol into SNA.  So far I've only been able to find the 
client portion of tn3270.

Any pointers to the tn3270 server code or documentation on the protocol 
would be greatly appriciated

thanks,

Bill




-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 93 22:03:51 GMT
From:      echan@skynet.intel.com (Eldon Chan ~ )
To:        comp.protocols.tcp-ip
Subject:   Re: Vendor numbers for ethernet addresses

Thanks to all who replied to my message.  It seems there is a more complete file
than rfc1340 at ftp.lcs.mit.edu.

From LEONARD@Arizona.edu Fri Jan 15 16:17:57 1993
Received: by scdt (5.57/10.0i); Fri, 15 Jan 93 16:17:48 -0800
Received: from hermes.intel.com by skynet.intel.com (4.1/SCDT-NMS)
	id AA05838; Fri, 15 Jan 93 16:13:01 PST
Received: from Merlin.Telcom.Arizona.EDU by hermes.intel.com (5.65/10.0i); Fri, 15 Jan 93 16:11:31 -0800
Received: from Arizona.edu by Arizona.edu (PMDF #2381 ) id
 <01GTK04DUQHC8WZKO7@Arizona.edu>; Fri, 15 Jan 1993 17:11:04 MST
Date: 15 Jan 1993 17:11:03 -0700 (MST)
From: Aaron Leonard <LEONARD@Arizona.edu>
Subject: Re: Vendor numbers for ethernet addresses
To: echan@skynet.intel.com
Message-Id: <01GTK04DUQHE8WZKO7@Arizona.edu>
X-Vms-To: IN%"echan@skynet.intel.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Status: RO


In article <C0wxAH.9CH@inews.Intel.COM> you write:
| 
| Would someone tell me what vendor has ethernet address prefix 
|        00:00:81

That vendor code belongs to Synoptics.
| ?
| I checked the rfc1340 (Assigned numbers), but it's not in there. Anyone have a
| more updated list ?

The best list is not in the RFC, but in the file pub/map/EtherNet-codes on
FTP.LCS.MIT.Edu.  I'm appending the 11-Jan-1993 version of this file.

| Thanks much.

You're welcome,

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  "It's not a bug, it's a form of flow control."
  - Jerry Leichter on why crash-prone Unix is a suitable
    platform for NSFNET core routers

List of codes used on 802.3 and EtherNet networks.


Last update: 11-Jan-93



This file contains collected information on the various codes used on
IEEE 802.3 and EtherNet.  There are three "pages", type codes, vendor
codes, and the uses of multicast (including broadcast) addresses.  I
wish to thank the contributors, some are listed below and there are
almost certainly others that I have missed.  A complete up-to-date
copy of this file may always be obtained with anonymous FTP from
FTP.LCS.MIT.Edu with the name pub/map/EtherNet-codes.  Since this
information is from collected wisdom, there are certainly omissions.
I welcome any further additions which can be sent to me at
MAP=EtherNet-codes@LCS.MIT.Edu.


	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology


This document started as a copy of one posted by Walter Urbaniak at
BBN.  Additions and corrections have been freely contributed by the
following (as well as others whose names are forgotten):


Jeff Beadles		Tektronix		jeff@quark.wv.tek.com
Andrew E. Birner	Zenith Electronics	scsabir@tvgurus.hdtv.zenithe.com
Steve Boyd 		DSTO Materials Res. Lab.boyd@mrl.dsto.gov.au
Brent Callaghan		Sun			Brent.Callaghan@eng.sun.com
?? Caloccia (?)		Stratus Computer, Inc.	caloccia@abersoch.sw.stratus.com
Bob Clements		BBN			clements@bbn.com
Matt Crawford		Fermilab		crawdad@fncent.fnal.gov
W. Tait Cyrus		Univ. of New Mexico	cyrus@pprg.unm.edu
Ian Doak		Newcastle Univ. (UK)	I.D.Doak@newcastle.ac.uk
Mohamed el Lozy		Harvard University	ellozy@bess.harvard.edu
Robert M. Enger		ANS			enger@ans.net
Jan Engvald		Lund Univ. Comp. Ctr	Jan.Engvald@ldc.lu.se
Jim Geier		SHARP HealthCare	jcg@sharp.idx.com
Tom Graham		HP			trg@col.hp.com
Andrew R. Gray		Crosfield Electronics	ag@crosfield.co.uk
Bruce Hafford		Gordian			bruce@gordian.com
Patricia Hanagan	FTP Software Inc.	patty@ftp.com
Mente H. Heemstra	State Univ. Groningen	HEEMSTRA@RC.RUG.NL
Anders Hillbo		??			ahi@nada.kth.se
Charles Holmes		TRW, Inc.		cdh@gumby.dsd.trw.com
Stephen Hope		??			sph@logitek.co.uk
Przemek Klosowski	NIST			przemek@rrdstrad.nist.gov
Samuel Lam		CTI			skl@wimsey.bc.ca
Craig Leres		Lawrence Berkeley Labs	leres@ee.lbl.gov
John Robert LoVerso	Xylogics, Inc.		xylogics!loverso@bu-it.bu.edu
Charles T. Lukaszewski	Open Systems Architects	imp@osa.com
Malcolm McKenzie	Aus. Inst. of Marine S.	M_Mckenzie@aims.gov.au
Kurt Melden		Cascade Communications	kam@casc.com
Richard Milward		UNC-Chapel Hill		RICHARD.DVC@mhs.unc.edu
Stephen Northcott (??)	US Navy (??)		snorthc@relay.nswc.navy.mil
Paul O'Neill		Oregon State Univ.	pvo@oce.orst.edu
Bruce Orchard		???			orchard@eceserv0.ece.wisc.edu
Michael Patton		MIT Lab. for Comp. Sci.	MAP@LCS.MIT.Edu
Craig Paul		Univ. Kansas(?)		paul@lane.cc.ukans.edu
Jon Postel		ISI (IANA)		IANA@ISI.Edu
Bill Russell		NYU			russell@nyu.edu
Phillip A. Remaker	cisco Systems		remaker@cisco.com  
Joyce Reynolds		ISI (IANA)		IANA@ISI.Edu
Jay Rosenbloom		Univ. of Wisc.-Madison	jrosen@noc.macc.wisc.edu
Harry Saal		Network General		hjs@lindy.stanford.edu
Michael A. Shiels	???			mshiels@tmsoftware.ca
Bill Sommerfeld		MIT Project Athena	wesommer@athena.mit.edu
Galen Tackett		Lockheed		TACKETT@eisner.decus.org
Chris Tengi		Princeton		tengi@princeton.edu
Brian Toomey		Chipcom Corp.		btoomey@chipcom.com
Robert Ullmann		Prime Computer, Inc.	ARIEL@en-c06.prime.com
Walter Urbaniak		BBN			Urbaniak@BBN.COM
Margot Utterback	Harvard University	utterbac@husc10.harvard.edu
James B. VanBokkelen	FTP Software Inc.	jbvb@ftp.com
R Brett Wormley		Raycom Systems		csun!raycom!brettw
Marc E. Zorn		TRW, Inc.		zorn@gumby.dsd.trw.com
 "Type" Fields


The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after
the preamble) consist of the "Ethernet Type" or "IEEE802.3 Length"
field. The "Ethernet Type" values are managed by XEROX.  Some
assignments are public (see + below), others private.  Current
information includes:  Xerox Public Ethernet Packet Type
documentation(Xerox Courier Vol. 3 Issue 4 October 1988); IEEE802.3
Std; NIC RFC1010; contributions from network managers and vendors.


Note Hex
@    0000-05DC	IEEE802.3 Length Field (0.:1500.)
+    0101-01FF	Experimental
     0200	Xerox PUP (conflicts with 802.3 Length Field range) (see 0A00)
     0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
     0400	Nixdorf (conflicts with 802.3 Length Field)
+*   0600	Xerox NS IDP
     0601	XNS Address Translation (3Mb only)
+*#  0800	DOD Internet Protocol (IP)
+    0801	X.75 Internet
+    0802	NBS Internet
+    0803	ECMA Internet
+    0804	CHAOSnet
+    0805	X.25 Level 3
+*   0806	Address Resolution Protocol (ARP) (for IP and for CHAOS)
     0807	XNS Compatibility
     081C	Symbolics Private
+    0888-088A	Xyplex
     0900	Ungermann-Bass network debugger
     0A00	Xerox IEEE802.3 PUP
     0A01	Xerox IEEE802.3 PUP Address Translation
     0BAD	Banyan Systems
     0BAF	Banyon VINES Echo
     1000	Berkeley Trailer negotiation
     1001-100F	Berkeley Trailer encapsulation for IP
     1234	DCA - Multicast
*    1600	VALID system protocol
     1989	Artificial Horizons ("Aviator" dogfight simulator [on Sun])
     3C00	3Com NBP virtual circuit datagram (like XNS SPP) not registered
     3C01	3Com NBP System control datagram not registered
     3C02	3Com NBP Connect request (virtual cct) not registered
     3C03	3Com NBP Connect repsonse not registered
     3C04	3Com NBP Connect complete not registered
     3C05	3Com NBP Close request (virtual cct) not registered
     3C06	3Com NBP Close response not registered
     3C07	3Com NBP Datagram (like XNS IDP) not registered
     3C08	3Com NBP Datagram broadcast not registered
     3C09	3Com NBP Claim NetBIOS name not registered
     3C0A	3Com NBP Delete Netbios name not registered
     3C0B	3Com NBP Remote adaptor status request not registered
     3C0C	3Com NBP Remote adaptor response not registered
     3C0D	3Com NBP Reset not registered
     4242	PCS Basic Block Protocol
     4321	THD - Diddle
%    5208	BBN Simnet Private
     6000	DEC unassigned, experimental
     6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
     6002	DEC Maintenance Operation Protocol (MOP) Remote Console
     6003	DECNET Phase IV, DNA Routing
     6004	DEC Local Area Transport (LAT)
     6005	DEC diagnostic protocol (at interface initialization?)
     6006	DEC customer protocol
     6007	DEC Local Area VAX Cluster (LAVC), System Communication Architecture (SCA)
     6008	DEC unassigned (AMBER?)
     6009	DEC unassigned (MUMPS?)
+    6010-6014	3Com Corporation
     7000	Ungermann-Bass download
     7001	Ungermann-Bass NIUs
     7002	Ungermann-Bass diagnostic/loopback
     7003	Ungermann-Bass ??? (NMC to/from UB Bridge)
     7005	Ungermann-Bass Bridge Spanning Tree
     7007	OS/9 Microware
     7009	OS/9 Net?
+    7020-7029	LRT (England) (now Sintrom)
     7030	Racal-Interlan
     7031	Prime NTS (Network Terminal Service)
     7034	Cabletron
     8003	Cronus VLN
     8004	Cronus Direct
     8005	HP Probe protocol
+    8006	Nestar
+    8008	AT&T/Stanford Univ.	Local use
     8010	Excelan
+    8013	Silicon Graphics diagnostic
+    8014	Silicon Graphics network games
+    8015	Silicon Graphics reserved
+    8016	Silicon Graphics XNS NameServer, bounce server
+    8019	Apollo DOMAIN
+    802E	Tymshare
+    802F	Tigan, Inc.
+    8035	Reverse Address Resolution Protocol (RARP)
+    8036	Aeonic Systems
     8037	IPX (Novell Netware?)
     8038	DEC LanBridge Management
     8039	DEC DSM/DDP
     803A	DEC unassigned (Argonaut Console?)
     803B	DEC unassigned (VAXELN?)
     803C	DEC unassigned (NMSV? DNA Naming Service?)
     803D	DEC Ethernet CSMA/CD Encryption Protocol
     803E	DEC Distributed Time Service
     803F	DEC LAN Traffic Monitor Protocol
     8040	DEC unassigned (NetBios Emulator?)
     8041	DEC unassigned (MS/DOS?, Local Area System Transport?)
     8042	DEC unassigned
+    8044	Planning Research Corp.
+    8046	AT&T
+    8047	AT&T
+    8049	ExperData
+    805B	VMTP (Versatile Message Transaction Protocol, RFC-1045) (Stanford) [was Stanford V Kernel,
experimental]
+    805C	Stanford V Kernel, version 6.0
+    805D	Evans & Sutherland
+    8060	Little Machines
+    8062	Counterpoint Computers
+    8065	University of Mass. at Amherst
+    8066	University of Mass. at Amherst
+    8067	Veeco Integrated Automation
+    8068	General Dynamics
+    8069	AT&T
+    806A	Autophon
+    806C	ComDesign
+    806D	Compugraphic Corporation
+    806E-8077	Landmark Graphics Corporation
+    807A	Matra
+    807B	Dansk Data Elektronik
+    807C	Merit Internodal (or Univ of Michigan?)
+    807D-807F	Vitalink Communications
+    8080	Vitalink TransLAN III Management
+    8081-8083	Counterpoint Computers
     8088-808A	Xyplex
+    809B	EtherTalk (AppleTalk over Ethernet)
+    809C-809E	Datability
+    809F	Spider Systems Ltd.
+    80A3	Nixdorf Computers
+    80A4-80B3	Siemens Gammasonics Inc.
+    80C0-80C3	DCA (Digital Comm. Assoc.) Data Exchange Cluster
+    80C6	Pacer Software
+    80C7	Applitek Corporation
+    80C8-80CC	Intergraph Corporation
+    80CD-80CE	Harris Corporation
+    80CF-80D2	Taylor Instrument
+    80D3-80D4	Rosemount Corporation
     80D5	IBM SNA Services over Ethernet
+    80DD	Varian Associates
+    80DE-80DF	TRFS (Integrated Solutions Transparent Remote File System)
+    80E0-80E3	Allen-Bradley
+    80E4-80F0	Datability
+    80F2	Retix
+    80F3	AppleTalk Address Resolution Protocol (AARP)
+    80F4-80F5	Kinetics
+    80F7	Apollo Computer
+    80FF-8103	Wellfleet Communications
     8107-8109	Symbolics Private
     812B	Talaris
+    8130	Waterloo Microsystems Inc.
+    8131	VG Laboratory Systems
+    8137	Novell (old) NetWare IPX (ECONFIG E option)
+    8138	Novell, Inc.
+    8139-813D	KTI
     814C	SNMP over Ethernet (see RFC1089)
     814F	Technically Elite Concepts	Network Professor
     817D	XTP
     81D6	Lantastic
     8582	Kalpana
     8888	HP LanProbe test?
+    9000	Loopback (Configuration Test Protocol)
     9001	3Com (Formerly Bridge Communications), XNS Systems Management
     9002	3Com (Formerly Bridge Communications), TCP/IP Systems Management
     9003	3Com (Formerly Bridge Communications), loopback detection
     AAAA	DECNET?		Used by VAX 6220 DEBNI
%    FF00	BBN VITAL-LanBridge cache wakeups

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
+ These protocols are mentioned by Xerox in their October 1988 issue of
  COURIER (page 8-9) as the publicly assigned numbers.  Only vendors are
  listed by Xerox, not what protocols.  For more information about type field
  assignments, contact: Pam DuPuy, Xerox Systems Instuture, (408)737-4652.
@ According to the October 1988 issue of COURIER (page 8), "if it is less
  than 600H, the packet is assumed to be an 802.3 packet; if it is greater
  than 600H, the packet is flagged as an Ethernet packet."
 Vendor Addresses

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme (e.g AA0003; 02xxxx).

000002	BBN (was internal usage only, no longer used)
00000C	Cisco
00000E	Fujitsu
00000F	NeXT
000010	Hughes LAN Systems (formerly Sytek)
000011	Tektronix
000015	Datapoint Corporation 
000018	Webster (?)
00001A	AMD (?)
00001B	Novell
00001D	Cabletron
000020	DIAB (Data Intdustrier AB)
000021	SC&C
000022	Visual Technology
000029	IMC
00002A	TRW
00003C	Auspex
00003D	AT&T
000044	Castelle
000046	ISC-Bunker Ramo, An Olivetti Company
000049	Apricot Ltd.
00004B	APT			A.P.T. Appletalk WAN router
00004F	Logicraft 386-Ware P.C. Emulator
000052	ODS
000055	AT&T
00005A	SK	(Schneider & Koch in Europe and Syskonnect outside of Europe)
00005A	Xerox 806 (unregistered)
00005D	RCE
00005E	U.S. Department of Defense (IANA)
00005F	Sumitomo (?)
000062	Honeywell
000065	Network General
000069	Silicon Graphics(?)
00006B	MIPS
00006E	Artisoft, Inc.
000077	MIPS(?), Interphase(?)
000079	Net Ware (?)
00007A	Ardent
00007B	Research Machines
00007D	Harris (3M) (old)
00007F	Linotronic
000080	Dowty Network Services	[Also shows as "Harris (3M) (new)" and/or "Imagen(?)" elsewhere]
000081	Synoptics
000084	Aquila (?), ADI Systems Inc.(?)
000086	Gateway (?), Megahertz Corporation(?)
000089	Cayman Systems		Gatorbox
00008E	Jupiter(?), Solbourne(?)
000093	Proteon
000094	Asante			MAC
000095	Sony/Tektronix
000097	Epoch
000098	Cross Com
00009F	Ameristar Technology
0000A0	Sanyo Electronics
0000A2	Wellfleet
0000A3	Network Application Technology (NAT)
0000A4	Acorn
0000A5	Compatible Systems Corporation
0000A6	Network General (internal assignment, not for products)
0000A7	Network Computing Devices (NCD)		X-terminals
0000A8	Stratus Computer, Inc.
0000A9	Network Systems
0000AA	Xerox			Xerox machines
0000AC	Apollo
0000AF  Nuclear Data		Acquisition Interface Modules (AIM)
0000B0	RND (RAD Network Devices)
0000B3	CIMLinc
0000B4	Edimax
0000B5	Datability		Terminal Servers
0000B7	Dove			Fastnet
0000BB	????????????????? seems to speak appletalk
0000BC	Allen-Bradley
0000C0	Western Digital now  SMC (Std. Microsystems Corp.)
0000C6	HP Intelligent Networks Operation (formerly Eon Systems)
0000C8	Altos
0000C9	Emulex			Terminal Servers
0000D0	Develcon Electronics, Ltd.
0000D1	Adaptec, Inc.		"Nodem" product
0000D4	PureData
0000D7	Dartmouth College (NED Router)
0000D8	3Com? Novell?		PS/2
0000DD	Gould
0000DE	Unigraph
0000E2	Acer Counterpoint
0000E8	Accton Technology Corporation
0000EE	Network Designers Limited(?)
0000EF	Alantec
0000F0	Samsung
0000F3	Gandalf
0000F4	Allied Telesis, Inc.
0000F6	A.M.C. (Applied Microsystems Corp.)
0000F8	DEC (?)
0000FD	High Level Hardware (Orion, UK)
000102	BBN			BBN internal usage (not registered)
000143	IEEE 802
000163	NDC  (National Datacomm Corporation)
000168	W&G  (Wandel & Goltermann)
0001C8	Thomas Conrad Corp.
000852	Technically Elite Concepts
000855	Fermilab
001700	Kabel
00400B	Crescendo (?)
004010	Sonic			Mac Ethernet interfaces
004015	Ascom (?)
004027	Sigma (?)
00402B	TriGem
00402F	XDI (?)
004095	Eagle Technologies
00409D	DigiBoard		Ethernet-ISDN bridges
0040C5	Micom Communications Corp.
0040C8	Milan Technology Corp.
0040FB	Cascade Communications Corp.
00608C	3Com (1990 onwards)
00800F	SMC (Standard Microsystem Corp.)
008010	Commodore
008017	PFU
008019	Dayna Communications	"Etherprint" product
00801B	Kodiak Technology
008021	Newbridge Networks Corporation
008024	Kalpana
008029	Microdyne Corporation
00802D	Xylogics, Inc.		Annex terminal servers
00802E	Plexcom, Inc.
008033	Formation (?)
008034	SMT-Goupil
008035	Technology Works
00803E	Synernetics
00803F	Hyundai Electronics
008051	ADC Fibermux
008052	Network Professor
00805C	Agilis(?)
00807C	FiberCom
008087	Okidata
00808A	Summit (?)
00808C	Frontier Software Development
008096	HDS (Human Designed Systems)	X terminals
0080A1	Microtest
0080A3	Lantronix
0080AD	Telebit
0080B2	NET  (Network Equipment Technologies)
0080C0	Penril (?)
0080C2	IEEE			802.1 Committee
0080C7	Xircom, Inc.
0080C8	D-Link	(also Solectek Pocket Adapters)
0080D0	Computer Products International
0080D3	Shiva			Appletalk-Ethernet interface
0080D4	Chase Limited
0080D6	Apple Mac Portable(?)
0080D8	Network Peripherals
0080E3	Coral (?)
0080F1	Opus
0080F7	Zenith Communications Products
00AA00	Intel
00B0D0	Computer Products International
00DD00	Ungermann-Bass		IBM RT
00DD01	Ungermann-Bass
00DD08	Ungermann-Bass
020406	BBN			BBN internal usage (not registered)
020701	MICOM/Interlan		DEC (UNIBUS or QBUS), Apollo, Cisco
026060	3Com
026086	Satelcom MegaPac (UK)
02608C	3Com			IBM PC; Imagen; Valid; Cisco; Macintosh
02CF1F	CMC			Masscomp; Silicon Graphics; Prime EXL
02E6D3	BTI (Bus-Tech, Inc.)	IBM Mainframes
080001	Computer Vision
080002	3Com (formerly Bridge)
080003	ACC (Advanced Computer Communications)
080005	Symbolics		Symbolics LISP machines
080006	Siemens Nixdorf		PC clone
080007	Apple
080008	BBN
080009	Hewlett-Packard
08000A	Nestar Systems
08000B	Unisys
08000D	ICL (International Computers, Ltd.)
08000E	NCR/AT&T
08000F	SMC (Standard Microsystems Corp.)
080010	AT&T [misrepresentation of 800010?]
080011	Tektronix, Inc.
080014	Excelan			BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC (National Semiconductor Corp.)
08001A	Data General
08001B	Data General
08001E	Apollo
08001F	Sharp
080020	Sun
080022	NBI (Nothing But Initials)
080023	Matsushita Denso
080025	CDC
080026	Norsk Data (Nord)
080027	PCS Computer Systems GmbH
080028	TI			Explorer
08002B	DEC
08002E	Metaphor
08002F	Prime Computer		Prime 50-Series LHC300
080036	Intergraph		CAE stations
080037	Fujitsu-Xerox
080038	Bull
080039	Spider Systems
08003B	Torus Systems
08003E	Motorola		VME bus processor modules
080041	DCA (Digital Comm. Assoc.)
080044	DSI (DAVID Systems, Inc.)
080045	???? (maybe Xylogics, but they claim not to know this number)
080046	Sony
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
080051	Experdata
080056	Stanford University
080057	Evans & Sutherland (?)
080058	???			DECsystem-20
08005A	IBM
080067	Comdesign
080068	Ridge
080069	Silicon Graphics
08006A	ATTst (?)
08006E	Excelan
080070	Mitsubishi
080074	Casio
080075	DDE (Danish Data Elektronik A/S)
080077	TSL (now Retix)
080079	Silicon Graphics
08007C	Vitalink		TransLAN III
080080	XIOS
080081	Crosfield Electronics
080083	Seiko Denshi 
080086	Imagen/QMS
080087	Xyplex			terminal servers
080089	Kinetics		AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision		XyVision machines
08008E	Tandem
08008F	Chipcom Corp.
080090	Retix, Inc.		Bridges
10005A	IBM
1000D4	DEC
1000E0	Apple A/UX		(modified addresses for licensing)
400003	Net Ware (?)
475443	GTC (Not registered!)	(This number is a multicast!)
484453	HDS ???
800010	AT&T [misrepresented as 080010? One source claims this is correct]
AA0000	DEC			obsolete
AA0001	DEC			obsolete
AA0002	DEC			obsolete
AA0003	DEC			Global physical address for some DEC machines
AA0004	DEC			Local logical address for systems running DECNET
C00000	Western Digital (may be reversed 00 00 C0?)
EC1000	Enance Source Co., Ltd.	PC clones(?)
 Ethernet Multicast (including Broadcast) Addresses and uses

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

01-00-1D-00-00-00	-802-	Cabletron PC-OV PC discover (on demand)
01-00-1D-42-00-00	-802-	Cabletron PC-OV Bridge discover (on demand)
01-00-1D-52-00-00	-802-	Cabletron PC-OV MMAC discover (on demand)
01-00-5E-00-00-00	0800	DoD Internet Multicast (RFC-1112)
through
01-00-5E-7F-FF-FF
01-00-5E-80-00-00	????	DoD Internet reserved by IANA
through
01-00-5E-FF-FF-FF
01-00-81-00-00-02	????	Synoptics Network Management
01-80-C2-00-00-00	-802-	Spanning tree (for bridges)
01-80-C2-00-00-01	-802-	802.1 alternate Spanning multicast
through
01-80-C2-00-00-0F
01-80-C2-00-00-14	-802-	OSI Route level 1 (within area) IS hello?
01-80-C2-00-00-15	-802-	OSI Route level 2 (between area) IS hello?
01-80-24-00-00-00	8582	Kalpana Etherswitch every 60 seconds
01-DD-00-FF-FF-FF       7002    Ungermann-Bass boot-me requests
01-DD-01-00-00-00       7005    Ungermann-Bass Spanning Tree
03-00-00-00-00-10       80D5    (OS/2 1.3 EE + Communications Manager)
03-00-00-00-00-40       80D5    (OS/2 1.3 EE + Communications Manager)
09-00-02-04-00-01?	8080?	Vitalink printer messages
09-00-02-04-00-02?	8080?	Vitalink bridge management
09-00-07-00-00-00	-802-	AppleTalk Zone multicast addresses
through
09-00-07-00-00-FC
09-00-07-FF-FF-FF	-802-	AppleTalk broadcast address
09-00-09-00-00-01	8005	HP Probe
09-00-09-00-00-01	-802-	HP Probe
09-00-09-00-00-04	8005?	HP DTC
09-00-0D-XX-XX-XX	-802-	ICL Oslan Multicast
09-00-0D-02-00-00	????	ICL Oslan Service discover only on boot
09-00-0D-02-0A-38	????	ICL Oslan Service discover only on boot
09-00-0D-02-0A-39	????	ICL Oslan Service discover only on boot
09-00-0D-02-0A-3C	????	ICL Oslan Service discover only on boot
09-00-0D-02-FF-FF	????	ICL Oslan Service discover only on boot
09-00-0D-09-00-00	????	ICL Oslan Service discover as required
09-00-1E-00-00-00	8019?	Apollo DOMAIN
09-00-26-01-00-01?	8038	Vitalink TransLAN bridge management
09-00-2B-00-00-00	6009?	DEC MUMPS?
09-00-2B-00-00-01	8039	DEC DSM/DDP
09-00-2B-00-00-02	803B?	DEC VAXELN?
09-00-2B-00-00-03	8038	DEC Lanbridge Traffic Monitor (LTM)
09-00-2B-00-00-04	????	DEC MAP End System Hello?
09-00-2B-00-00-05	????	DEC MAP Intermediate System Hello?
09-00-2B-00-00-06	803D?	DEC CSMA/CD Encryption?
09-00-2B-00-00-07	8040?	DEC NetBios Emulator?
09-00-2B-00-00-0F	6004	DEC Local Area Transport (LAT)
09-00-2B-00-00-1x	????	DEC Experimental
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets (All bridges)
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets (All local bridges)
				1 packet per second, sent by the
				designated LanBridge
09-00-2B-02-00-00	????	DEC DNA Level 2 Routing Layer routers?
09-00-2B-02-01-00	803C?	DEC DNA Naming Service Advertisement?
09-00-2B-02-01-01	803C?	DEC DNA Naming Service Solicitation?
09-00-2B-02-01-02	803E?	DEC Distributed Time Service
09-00-2B-03-xx-xx	????	DEC default filtering by bridges?
09-00-2B-04-00-00	8041?	DEC Local Area System Transport (LAST)?
09-00-2B-23-00-00	803A?	DEC Argonaut Console?
09-00-39-00-70-00?	????	Spider Systems Bridge Hello packet?
09-00-4C-00-00-00	-802-	BICC 802.1 management
09-00-4C-00-00-02	-802-	BICC 802.1 management
09-00-4C-00-00-06	-802-	BICC Local bridge STA 802.1(D) Rev6
09-00-4C-00-00-0C	-802-	BICC Remote bridge STA 802.1(D) Rev8
09-00-4C-00-00-0F	-802-	BICC Remote bridge ADAPTIVE ROUTING (e.g. to Retix)
09-00-4E-00-00-02?	8137?	Novell IPX (BICC?)
09-00-56-00-00-00	????	Stanford reserved
through
09-00-56-FE-FF-FF
09-00-56-FF-00-00	805C	Stanford V Kernel, version 6.0
through
09-00-56-FF-FF-FF
09-00-77-00-00-00	-802-	Retix Bridge Local Management System
09-00-77-00-00-01	-802-	Retix spanning tree bridges 
09-00-77-00-00-02	-802-	Retix Bridge Adaptive routing
09-00-7C-01-00-01	????	Vitalink DLS Multicast
09-00-7C-01-00-03	????	Vitalink DLS Inlink
09-00-7C-01-00-04	????	Vitalink DLS and non DLS Multicast
09-00-7C-02-00-05	8080?	Vitalink diagnostics
09-00-7C-05-00-01	8080?	Vitalink gateway?
09-00-7C-05-00-02	????	Vitalink Network Validation Message
09-00-87-80-FF-FF       0889    Xyplex Terminal Servers
09-00-87-90-FF-FF       0889    Xyplex Terminal Servers
0D-1E-15-BA-DD-06	????	HP
80-01-43-00-00-00	-802-	Bridge
80-01-43-00-00-08	-802-	Bridge Management
80-01-43-00-00-28	-802-	ISO 10589 level-1 Intermediate Stations
80-01-43-00-00-48	-802-	Loadable Device
80-01-43-00-00-88	-802-	Load Server
80-01-43-00-00-A8	-802-	ISO 10589 level-2 Intermediate Stations
80-01-43-00-80-00	-802-	FDDI RMT Directed Beacon
80-01-43-00-80-08	-802-	FDDI status report frame
90-00-D4-00-00-20	-802-	OSI Network Layer Intermediate Stations
90-00-D4-00-00-A0	-802-	OSI Network Layer End Stations
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through
AB-00-03-FF-FF-FF
AB-00-03-00-00-00	6004	DEC Local Area Transport (LAT) - old
AB-00-04-00-xx-xx	????	Reserved DEC customer private use
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
				System Communication Architecture (SCA)
C0-00-00-00-00-01	-802-	Active Monitor
C0-00-00-00-00-02	-802-	Ring Parameter Monitor
C0-00-00-00-00-04	-802-	Network Server Heartbeat
C0-00-00-00-00-08	-802-	Ring Error Monitor
C0-00-00-00-00-10	-802-	Configuration Report Server
C0-00-00-00-00-20	-802-	Synchronous Bandwidth Manager
C0-00-00-00-00-40	-802-	Locate - Directory Server
C0-00-00-00-00-80	-802-	NETBIOS
C0-00-00-00-01-00	-802-	Bridge
C0-00-00-00-02-00	-802-	IMPL Server
C0-00-00-00-04-00	-802-	Ring Authorization Server
C0-00-00-00-08-00	-802-	LAN Gateway
C0-00-00-00-10-00	-802-	Ring Wiring Concentrator
C0-00-00-00-20-00	-802-	LAN Manager
C0-00-00-00-80-00	-802-
   through			user-defined
C0-00-40-00-00-00	-802-
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)
FF-FF-00-60-00-04	81D6	Lantastic
FF-FF-00-40-00-01	81D6	Lantastic
FF-FF-01-E0-00-04	81D6	Lantastic

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0804	CHAOS
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	0BAD	Banyan
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
FF-FF-FF-FF-FF-FF	8035	Reverse ARP
FF-FF-FF-FF-FF-FF	807C	Merit Internodal (INP)
FF-FF-FF-FF-FF-FF	809B	EtherTalk
FF-FF-FF-FF-FF-FF	9001	3Com (ex Bridge) Name Service
FF-FF-FF-FF-FF-FF	9002	3Com PCS/TCP Hello, Approx. 1 per minute per w/s


-- 
Eldon Chan                   
Intel Corpoartion
Design Technology 
Networking group                   Phone: 408-765-4992
echan@scdt.intel.com               Fax:   408-765-5719

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jan 1993 22:16:33 GMT
From:      mishkin@apollo.HP.COM (Nathaniel Mishkin)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC protocol specifications

In article <1993Jan16.171627.4522@visionware.co.uk>, chris@visionware.co.uk (Chris Davies) writes:
>Maritza Ramirez (maritza@espresso.bae.bellcore.com) wrote:
>: I would appreciate if someone could tell me how the RPC protocol 
>: specifications can be obtained. Are they proprietary, or freely
>: available on the internet ?
>
>The RPC protocol is in the public domain, although it was invented at
>Sun Microsystems. 

Y'know, it's not like I like to be petty or anything, or that I can't
live with a little looseness in terminology, but one thing that just
sends me off the deep end is when people use the terms "RPC" and "Remote
Procedure Call" as synonyms for Sun's RPC.  Many other RPC systems have
come before and after Sun's.  (The term "RPC" was in wide use before
Sun ever implemented an RPC system.)  Sun seems to tend to call their
RPC system either "Sun RPC" or "ONC RPC".

Of course, I'm also a guy who never could understand how the generic
phrase "personal computer" (or "PC") became synonymous with "IBM compatible
PC".

Flames to /dev/null.  Thank you.
-- 
                    -- Nat Mishkin
                       Distributed Computing Program
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 1993 00:49:47 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: RPC protocol specifications


Someone else commented:
>>The RPC protocol is in the public domain, although it was invented at
>>Sun Microsystems. 

In article <C12LvM.7st@apollo.hp.com> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes:
> Y'know, it's not like I like to be petty or anything, or that I can't
> live with a little looseness in terminology, but one thing that just
> sends me off the deep end is when people use the terms "RPC" and "Remote
> Procedure Call" as synonyms for Sun's RPC.  Many other RPC systems have
> come before and after Sun's.  

Nat,

  It is very simple.  The ONLY freely distributable online
specification for RPC was put out there by Sun.  Had HP put out such a
spec first, folks would use RPC to mean the HP version.  Same exact
story with NFS.  NFS is not the world's best distributed file system,
but it was the ONLY one specified openly in an RFC so that anyone on
the planet could implement it.

  The way to win at the open systems vendor game is to be completely
open with specifications (e.g. NFS, RPC as RFCs online) and just build
the best implementation of that spec.  Licensing specs and sample
implementations is at best a poor second cousin and HP as a group has
not learned this yet (though you individually might understand this).
  
  ANYONE on the planet can write an informational status RFC
describing ANY information, specification, or protocol that they wish.
There is even a long tradition of "April Fool's" RFCs that are mostly
humour.  HP should write some RFCs on things and use the RFC mechanism
to place specifications in the open world.  You'd be surprised how
effective that mechanism is at getting your technology adopted and
supported from the grass roots of the networking world.

  I'm not impressed with sour grapes, especially from one of the
founding firms of the Closed Software Foundation (i.e. OSF).

Ran
atkinson@itd.nrl.navy.mil


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 93 10:07:14 EST
From:      dos@major.panix.com (Dave O'Shea)
To:        comp.protocols.tcp-ip
Subject:   Re: Address conversion

proyse@peeras.demon.co.uk (Phil Royse) writes:

> >What I'm looking for is something along the lines of a router than could
> >hold an address translation table (which would, of course, have to be
> >generated by hand, but that's no problem), and convert addresses going
> >in both directions.
> 
> However, we will need an address translation process, which we think 
> could be invoked on a router, particularly one based on UNIX or 
> DOS, where one could pass each packet to the "address translator" 
> before forwarding it.  I believe it's workable.

I'm certain it is; obviously there would be some limitations - if an
address is transmitted as part of the data, it would not get translated.
As long as the person at the SNMP console is aware of this, tere's no
problem. (though I could see it confusing the bejeezus out of a certain
topology-mapping program!)

But no luck; I've checked with all the major vendors, and not one of
them seems to have a box that will do this kind of address translation.

> Do you have a problem with mapping the number of users on 
> your second network, with the size of the "real" address space 
> you've been allocated?

Neither, really - it's simply that there's a small group which picked
out some bogus addresses a Long Time Ago, and changing it would be more
trouble than it's worth - they would simply have to stay unconnected.

> Please keep me (or this group) informed of any leads, suggestions
> or comments in this matter; I will let you know if we do.

Will do!

> Have you read RFC1335 "Two Tier address structure.... A solution to
> ..address space exhaustion"  (Wang & Crowcroft, Univ. College, London)?
> It's good and throws some light on the issues.

Only briefly, and it does offer an interesting work-around - but not
suited to the "canned" applications we have here that expect "standard"
addresses.


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 1993 06:59:23 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: Who used TNAMED (IEN-116) any more?  And why?

In article <jpc.726775541@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
>I've noticed (via log_tcp) a few random connections from a couple of
>machines to the obsolete (or so I thought) IEN-116 trivial name service
>port.
>
>Who would want to use trivial name service?

Prime's TCP implementation still uses IEN-116, or does on the
version we have here. For some reason, they never quite made it
to DNS.



-- 
David Boyes      In the event I am captured or killed, Rice University
dboyes@rice.edu  and the Office of Networking and Computing Systems
                 will deny any knowledge of my opinions.

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 93 11:04:54 GMT
From:      cambler@zeus.calpoly.edu (Christopher J. Ambler, Phish)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Need help with TCP 1.1.1b (SCO UNIX)

Machine: 386/40
OS: SCO UNIX sys V 3.2.2
TCP: 1.1.1b (yeah, I know, it's old)

The problem is that telnet, finger, and ping work fine. FTP, however,
exhibits the following error message:

  NOTICE: tcp sum: src cccccccc, sum cccccccc

where cccccccc is replaced with a number. A netstat -s shows that for
each message, I'm getting a "discarded for back checksums" packet in
the tcp portion.

This also happens over NNTP telnet sessions (port 119), but NOT during
interactive telnet sessions.

My first thought is that it's the speed I'm at. I'm running over ISDN,
at 38.4BPS into a serial card, and running SLIP. But, the serial card
has a 16550, and SHOULD accept the speed.

Can anyone shed any light on the situation? I'm VERY frustrated at
this point, after spending all night getting CNews & NNTP up and
running :-)

Thanks in advance!!
-- 
SO WE'RE SUPPOSED TO PLAY IN    | cambler@zeus.calpoly.edu |   Think Snow!
CURITIBA IN 18 HOURS, BUT OUR   | (805) 756-6634/ISDN      |-------------------
BUS IS BEING HELD HOSTAGE BY    | Because all you of       | Stop that! You'll 
THE LOCAL PROMOTERS. -- INSOC   | Earth are IDIOTS!!       | go blind!

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 93 16:33:17 EST
From:      MACE@HDQCMS2H.UTSD.ATT.COM
To:        comp.protocols.tcp-ip
Subject:   Anyone know of a good LPR/LPD Server?

We have 10 LaserJet printers which we would like to connect to a LPD
server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
 
We would rather not use LPD on various machines directly connected to
the printers, since we would lose access to the printer when the machine
went down (was re-booted or powered off).
 
The connections would be serial (RS-232), with one connection being
parallel.
 
We have looked at the Lantronix equipment, but that does not really
offer LPD; since we have a diverse user community, we want to use the
LPR and LPRMON software that is provided with the TCP/IP implementations.
 
Does anyone have any suggestions?
--------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ
--------------------------------------------------------------------------

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 1993 12:13:54 GMT
From:      "Scott Guthery" <p00197@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   SMTP for UCX?

Anybody know of a SMTP that works with DEC's UCX (VAX/VMS) package?

Thanks, Scott


-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 1993 19:38:27 GMT
From:      nfb@mitre.org
To:        comp.protocols.tcp-ip
Subject:   Communicating With Wang Systems

     I have a task of providing communications between a
Wang VS system and a Sun workstation, and I am in the process
of getting information on the Wang TCP/IP - telnet (limited)
offering.  I would really like more than just the SMTP and telnet
that this gives, but that could be a start.
     I would much appreciate hearing from people that have done
similar things with Wang systems and can offer their experiences,
as well as leads to groups or people I can contact for assistance.
Also, feel free to suggest a more appropriate news group to post
this message to.
     Thanks.
Norman F. Brickman
Internet:  nfb@mitre.org

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 1993 22:36:13 GMT
From:      johnr@pacdata.com (John Reed)
To:        comp.protocols.tcp-ip
Subject:   Need bootp client code

Can a kind soul tell me where to find an example implementation of
bootp client code?

I have looked on uunet, but only found the server code (bootp.2.1.tar.Z).


Thanks.



JR

-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr@pacdata.com             |
   \------------------------------------------------------------------/

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jan 1993 22:37:59 GMT
From:      jswanson@csfb1.fir.fbc.com (James Swanson)
To:        comp.protocols.tcp-ip
Subject:   Looking for a sliding-frame file transfer package

I am looking for a sliding frame file transfer facility to use over an
internet network.  Probably a UDP/IP based thing.

Does anyone know of anything that would help?  Maybe some PD routines to
help?

Thanks.

-- 
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1993 14:04:47 -0800
From:      smiller@aludra.usc.edu (Stephen B. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Port Numbers & The RPC Portmapper

In article <1993Jan20.162611.25831@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
>
>
>I am trying to look for a solution to the problem of determining an 
>unknown remote port number. I will appreciate any comments on the 
>following situation:
>
> [text deleted, see earlier posting]
>
>Maritza
>

I am beginning to work an identical problem here, but have not come up with
much more than you.  I have considered trying the dynamic update features in
the BIND 4.8.3 code, but they are so poorly documented that I might be better
off writing my own application.  My situation is further complicated by then
need to change the port number assignments dynamically, which might be done
by deregistering and reregistering with the portmapper.  If anyone else has
ideas please feel free.....

Steve Miller - smiller@aludra.usc.edu



-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 93 01:40:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP for UCX?

In article <2936527978.2.p00197@psilink.com>, guthery@slcs.slb.com writes...
#Anybody know of a SMTP that works with DEC's UCX (VAX/VMS) package?
# 
#Thanks, Scott

	1. TGV MultiNet's SMTP package works with DEC UCX or their
	   own IP.  (1-800-TGV-3440, Sales@TGV.COM)

	2. PMDF from Innosoft International (sales@innosoft.com)

	3. MX which is public domain at an FTP site near you.

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
Yow!  I just went below the poverty line!

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 02:32:55 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Who used TNAMED (IEN-116) any more?  And why?

In article <1993Jan18.202333.28115@osuunx.ucc.okstate.edu>,
 martin@datacomm.ucc.okstate.edu (Martin McCormick) wrote:
>Some of the 3Com terminal servers use it if you set a certain soft switch.

Cisco terminal servers and routers can also be configured to use it.
If you configure the box to use both DNS and IEN-116, it will query
the IEN-116 universe if it couldn't get an answer from the DNS universe.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 04:35:29 GMT
From:      lo@ipc5.lat.oz.au (Anthony C C Lo)
To:        comp.protocols.tcp-ip
Subject:   TLI Programming on SunOS


Hello all,

Recently, I've been trying to write communication programs using the 
SunOS 4.1.1 Transport Layer Interface (TLI). I'm using asynchronous 
mode. The SunOS manuals mentioned about asynchronous execution mode,
and the examples given made some assumptions like "/dev/tivc" which
is fake. 

Does anybody have experience with this and be able to program the 
TLI? Any ideas and suggestions are most welcome.

Thanks in advance.


Anthony LO
Dept. of Computer Science &
Computer Engineering,
La Trobe University,
Bundoora 3083
Australia.

E-mail: lo@latcs1.lat.oz.au


-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 11:13:25
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 question

In article <C12Jyn.M72@da_vinci.it.uswc.uswest.com> rhodes@da_vinci.it.uswc.uswest.com (William Rhodes) writes:

    ...My first question is where to find information about the tn3270
    protocol....

There is no formal spec.  RFC 1123 has a brief mention of the underlying
mechanism (see sections 3.2.7 and 3.3.2) but doesn't connect it with
the name "tn3270".  Note that RFC 1041 **DOES NOT* describe current
"tn3270" practice.  There has been some effort towards a formal spec,
possibly with extensions to deal with things the current protocol doesn't
handle, like attached printers, but there's not even a draft yet.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 93 07:28:14 GMT
From:      alana@vpbuild.vp.com (Alan Anderson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Server defunct processes


	I am having a problem with defunct processes from clients
	connecting to the following server code. Stevens refers to the
	zombie processes for a concurrent server but I can't find where
	he solves the problem. If anyone can help with this problem I
	would greatly appreciate it. We are currently running NPROC @
	750 processes and can't get through 1 day.

?? would running the server under inetd solve the problem ??

	Please just mail me any ideas, if you need to see the client
	code, I will mail it to you.

	Thanks

	Alan Anderson
	Varco-Pruden Buildings
	6000 Poplar, Suite 400
	Memphis, TN 38119

	alana@vpbuild.vp.com

Header/declaration stuff was here....

  if ((s = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
    printf("Could not open stream socket.");
    exit(1);
  }
  
  bzero(&sin, sizeof(sin));
  sin.sin_family = AF_INET;
  sin.sin_addr.s_addr = htonl(INADDR_ANY);
  sin.sin_port = htons(SERV_TCP_PORT);
  
  if (bind(s, &sin, sizeof(sin)) == -1) {
    printf("Could not bind local address.");
    exit(1);
  }
  
  if (listen(s, 5) == -1) {
    printf("Could not listen to socket.");
    exit(1);
  }
  
  while(1) 
    {
    
      /*
       *	Wait for a connection
       */
      
      clilen = sizeof(cli_addr);
      if ((ns = accept(s, (struct sockaddr *) &cli_addr,
		       &clilen)) == -1) {
	printf("Error from accept.");
	exit(1);
      }
    
      if ((pid = fork()) <  0) {
	printf("Error from fork.");
	exit(1);
      }

      if (pid == 0) 
	{		/* This is the child	*/
	  while(1) 
	    {
	      if ((pid = readline(ns, buffer, 
				  sizeof(buffer))) == -1) 
		{
		  printf("Error from read.");
		  exit(1);
		}
	      buf = strtok(buffer, sep);
	      switch (buf[0]) 
		{
		  
		case 'S':
		  goto bail_out;

Other instructions are processed here...

		default:
		  printf(" Un-Identified call to server, buffer = <%s> \n", 
			 buffer);
		  break;	
		}
	    }
	bail_out:
	  printf("Bail Out was called, child is dead \n");
	  close (ns);
	  exit(0);
	}
   close (ns);
    }
 exit(0);
}

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 93 09:02:56 GMT
From:      ishikawa@personal-media.co.jp (Chiaki Ishikawa)
To:        comp.org.ieee,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Question: How to register a company for Ethernet product?


A colleague of mine is trying to find out how to register the company
I work for in order to obtain a unique ID that is burned into ROM
(EPROM, and others) for a network product.

He vaguely recalls that either IEEE or some organizations have a
registration mechanism to hand out unique IDs to hardware product
manufacturers. The ID, I understand, helps to make sure the low-level
network board have unique identification.

Will any kind soul let me know where and who to contact to proceed
with this registration?

Since this may not be much of an interest to many readers, I would
appreciate if you could send an e-mail to my e-mail address.

Thank you in advance.

 Chiaki Ishikawa,  Personal Media Corp.,  MY Bldg, 1-7-7 Hiratsuka,
 Shinagawa, Tokyo 142, JAPAN. FAX:+81-3-5702-0359, Phone:+81-3-5702-0351
 UUNET: ishikawa@personal-media.co.jp

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 12:35:16 GMT
From:      duru@cc.ec-lyon.fr (Thalie)
To:        comp.protocols.tcp-ip
Subject:   SNMP

Does someone know where I could get doc about SNMP protocol (I already have RFCs about SNMP).
Please e-mail me any answer (I don't read newsgroups very often, since I only
have telnet access to them), thanks

Emmanuel Duru ("Thalie")
duru@cc.ec-lyon.fr
Ecole Centrale de Lyon
36 avenue Guy de Collongue
69130 Ecully - France

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 12:55:53 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TELNET terminal types

jbvb@vax.ftp.com  (James B. VanBokkelen) writes:

>PC/TCP defaults to RFC 1060, but we let users configure their own
>names if they choose.  It would be nice if people paying for "support"
>from the various Unix vendors submitted this problem as a bug - the
>actual work of adding aliases wouldn't take them more than 1 day of a
>junior engineer's time, and the Internet would become a *lot* better.

I agree, but I'm sure that a lot of people do what we have: add the RFC
name to /etc/termcap and terminfo our own server. Elapsed time: 10
minutes, of which most spent consulting terminfo manuals :-)
Alternative is a bug report, which would take a lot longer and probably
be ineffective. No, we haven't logged a bug report.

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
PIPEX is a division of Unipalm Ltd. - phone 0223 424616.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 15:05:30 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: Need help with TCP 1.1.1b (SCO UNIX)

cambler@zeus.calpoly.edu (Christopher J. Ambler, Phish) writes:
> Machine: 386/40
> OS: SCO UNIX sys V 3.2.2
> TCP: 1.1.1b (yeah, I know, it's old)
> 
> The problem is that telnet, finger, and ping work fine. FTP, however,
> exhibits the following error message:
> 
>   NOTICE: tcp sum: src cccccccc, sum cccccccc
> 
> where cccccccc is replaced with a number. A netstat -s shows that for
> each message, I'm getting a "discarded for back checksums" packet in
> the tcp portion.
> 
> This also happens over NNTP telnet sessions (port 119), but NOT during
> interactive telnet sessions.
> 
> My first thought is that it's the speed I'm at. I'm running over ISDN,
> at 38.4BPS into a serial card, and running SLIP. But, the serial card
> has a 16550, and SHOULD accept the speed.
> 
> Can anyone shed any light on the situation? I'm VERY frustrated at
> this point, after spending all night getting CNews & NNTP up and
> running :-)

One possibility is that since FTP accesses the disk while TELNET, PING and
FINGER do not, interrupts may be disabled for too long. As a result some
bytes may be missed.

Regards,
-Roger
(I speak for myself)


-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 15:08:47 GMT
From:      zambrano@dit.upm.es (Jose Manuel Martinez Zambrano)
To:        comp.protocols.tcp-ip
Subject:   Q: XDP UDP RTP protocols info needed


I'm looking for any references/papers or public domain implementations of the 
RTP, UDP and RTP protocols.

Actually we're beginning the analisis and specification of a distributed and
multimedia educational application and any information on these or anothers
protocols suitable for the task are welcome.

Please, mail me and i'll summarize.

Thanks in advance,

		Jose.
--
+--------------------------------------+------------------------------------+
|  Jose Manuel Martinez Zambrano       |  email: zambrano@dit.upm.es        |
|  Dpto. Ingenieria Sist. Telematicos  |                                    |
|  E.T.S.I.Telecomunicacion            |  Telf: +34 1 5495700  ext:445      |
|  Ciudad Universitaria                |  Fax:  +34 1 3367333               |
|  E-28040 MADRID                      |  Tlx:  47430 ETSIT E               |
+--------------------------------------+------------------------------------+

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 15:16:25 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP

  There is discussion of SNMP in comp.protocols.snmp for sites
carrying the INET distribution.

  SNMP documents are available online as part of the RFC series
of documents.  Each RFC ftp archive has an rfc-index online with
descriptions so that you can find which RFCs are of interest to you.

Well connected RFC repositories include, but aren't limited to:
	nic.ddn.mil
	nnsc.nsf.net
	ftp.nisc.sri.com
	ftp.uu.net

  There is ongoing work on SNMP version 2 which will probably appear
during 1993 as RFCs.  These revisions include new mechanisms for
security, bulk transfer, etc.



-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 93 15:33:21 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Defunct processes left by server process.

One of our programmers has written a server using sockets for transferring
data to our application.  The only problem is that when the server exits, it
leaves a defunct process out there that takes an entry in the process table
with the process table eventually filling.  Eventually we have to reboot the
system to clear all the defunct processes.  Anyone know why it would leave
these defunct processes and what we can do to get rid of them??

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 93 16:26:11 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   Determining Port Numbers & The RPC Portmapper



I am trying to look for a solution to the problem of determining an 
unknown remote port number. I will appreciate any comments on the 
following situation:

Let suppose that we have a client application that in a given moment 
needs to know the server application's port number in a remote machine 
to communicate with it over TCP/IP. Let's say that the client and 
server applications are based on tli or socket calls.

In order to determine the server's port number, I was considering to 
use an approach similar to the RPC's portmapper, in which a server 
registers with a portmapper and gets a port, and then the client 
contacts that portmapper in a well known port to find out the port 
for the server application.

I was wondering if it would be possible for those client and server 
applications (which are not RPC applications) to use the RPC portmapper 
itself for this purpose (without using RPC calls, only tli/socket calls), 
given that the applications can generate an unique program number and 
version to be used as a reference.

If that is possible, does anyone knows ...

 a) which is the sequence of steps that must be done to register the 
    server application with the RPC portmapper ?

 b) which is the sequence of steps to obtain the server's port number 
    from the client side ?

Thanks,

Maritza


-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 93 17:37:34 GMT
From:      jpr@olbela.olivetti.be (Morant Jean-Pierre)
To:        biz.sco.general,biz.sco.opendesktop,comp.protocols.tcp-ip
Subject:   bootp on SCO tcp 1.2.0 (or lower)


Hello !
I've read somewhere that an implementation of "bootp" for SCO is available
on the net. Do someone know where I can find it ?

By the way, another one : I don't know much about the specification of the lli
drivers, but is it possible to access them to set the MAC address of the 
ethernet board ? (with some special ioctl or something like that ...)

If it is possible, do someone know of a tool doing this ?

Thanks for your help.
E-mail me, I'll post a summary.

-- 
Voice	: + 32 2 210 9353
Fax	:              87
E-mail	: ...ub4b!olbela!jpr	(office)
	  jpm@jpm.lbo.be	(home)

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      20 JAN 93 17:56:21 GMT
From:      keele@skyfox
To:        comp.protocols.tcp-ip
Subject:   3C509 pkt. drivers ?

Hello,

Does anyone know if there are packet drivers around for the new 
3C509 Etherlink III cards ? I have not seen them in the usual 
DRIVERS.ZIP file.

Thanks.

///Ross

A. Ross Keele                 | Keele@Sask.Usask.CA
Dept. of Psychology           | 46 Arts Building
University of Saskatchewan    | (306) 966-6696

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 93 18:16:56 GMT
From:      exudnw@exu.ericsson.se (Dave Williams)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   backbone routers and topology

This may be in some FAQ somewhere, but I can't find it.

I'd like to hear from any large sites that have routers configured as 
backbones.  There's lots of marketing hype from the router companies
on why you "need" to do this, but very little in the way of hard info
on configuration, performance and pitfalls.

Our current configuration consists of about 400 SPARC clients fed by 13 Sun
4/490 servers. Each server has multiple NC400 Network Co-processors (one per
client network), 2 IPI controllers and 6-8 IPI disks (sime Saber's, some Elites).

We are currently setup in a straight hierarchical topology that looks something 
like this: 

                                                                           
                            
                   server backbone (ethernet)                                               
     +-----------------------+----------------------+-----> to existing router 
     |                       |                      |      (3270, x.25, etc.)
     |                       |                      |        
 +-------+               +-------+              +-------+   
 | 490   |               |  490  |              |  490  |
 |  1    |               |   2   |              |   n   |
 +-+-+-+-+               +-+-+-+-+              +-+-+-+-+ 
   | | |  NC400 I/F's      | | |                  | | |    

  client                   client                 client                         
  networks                 networks               networks                                    
                                                                           
                                                                            
                                                                               
We typically put a maximum of 25 diskless w/s on each client network and get
about 60 clients per server.  We run NIS, DNS, automounter, etc. and the whole
thing works pretty well. We are currenly in the process of adding about 200 
disks to make about half of our client population dataless, the remainder is 
Sun SLC's :~(

We started questioning this layout when we noticed our "server backbone" was
hitting high % of possible lan bandwidth at peak hours of the day. We already
had common data replicated on multiple servers but it's too big to copy to
all of them. We thought about this for a bit and came up with the following 
possible solutions:

1) Put a large router (Cisco AGS+, Alantec, Wellfleet, etc.) in place of the 
   server backbone. These typically have near-gigabit backplanes and have *got* 
   to be faster than our current Ethernet 10 MB/sec "governor".

2) Connect the server's client networks to both the clients and the router
   and turn off routing in the servers. We did some informal tests and found
   that a single client could cause 10% server CPU load just routing a single 
   "find" command. I've always heard that Suns made poor routers, but could 
   never find any hard data on the subject.

3) Use the router as an FDDI connection to a single server containing all 
   replicated filesystems. We thought this could be a SS10/41 with multiple
   fast SCSI disks. This would free up all the space currently taken up by
   replicated data spread over all the servers while providing for faster 
   access and better configuration control.

   One question that looms is whether the replicated (read mostly) data server
   should use multiple ethernet I/F's, one to each client network (using more 
   than one server) or use FDDI straight into the router.  We don't have a lot
   of FDDI experience to guide us.

   Is the answer the same for database (read-write, non-NFS) servers as it is for 
   "read mostly" (NFS) nodes?  Which is better (for NFS and/or socket DB access), 
   multiple ethernet segments in a "matrix" topology spread over each client 
   network or single FDDI interfaces from each server into the router?

We would end up with something like this:

                            
                         "old" server backbone 
           (Left intact for sanity and backup if router ever blows)                                               
      +--------------------------+-------------------------+-------------+                                                                      
      |                          |                         |             | 
      |                          |                         |             |
   +-------+                  +-------+                 +-------+        | 
   | 490   |                  |  490  |                 |  490  |        |
   |  1    |                  |   2   |                 |   n   |        |
   +-+-+-+-+                  +-+-+-+-+                 +-+-+-+-+        |
     | | |   NC400 I/F's        | | |                     | | |          |  
    client                     client                    client          | 
    networks                   networks                  networks        | 
     | | |                      | | |                     | | |          |  
 +---+-+-+----------------------+-+-+---------------------+-+-+----+     | 
 |    enet                       enet                      enet    |     |
 |                                                             enet+-----+
 |                         router "backbone"                       |
 |                                                      FDDI/CDDI  |
 +-----------------------------+----------------------------++-----+ 
                               |                            ||       
                           X.25,3270                  +-----++----+ 
                              etc.                    | replicated|
                                                      |   data    |
                                                      | server(s) |
                                                      |           |
                                                      +-----------+


Are we on the trail of something good here or have we all been locked up in
the hacketorium too long?  

Specifically:

1) Is turning off routing on the servers a *good* thing?

2) What will break?

3) One question that looms is whether the replicated (read mostly) data server
   should use multiple ethernet I/F's, one to each client network (using more 
   than one server to cover all of the client networks) or use FDDI straight 
   into the router.  We don't have a lot of FDDI experience to guide us.

   Is the answer the same for database (read-write) servers as it is for "read 
   mostly" nodes?  Which is better (for NFS and/or socket DB access), multiple 
   ethernet segments in a "matrix" topology spread over each client network
   or a single FDDI interface into the router for each type of server?

4) What are we overlooking?

5) Are there any other large sites doing this kind of stuff?


Any comments/suggestions appreciated.


= exudnw@exu.ericsson.se       (214)907-7928                            =
= David Williams              "You can't win, you can't break even,     =
= Ericsson Network Systems     and you can't quit"                      =
= Richardson, TX 75081                                  my opinions...  =    
--
= exudnw@exu.ericsson.se                                                =
= David Williams              "You can't win, you can't break even,     =
= Ericsson Network Systems     and you can't quit"                      =
= Richardson, TX 75081                                  my opinions...  =

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 93 19:06:52 GMT
From:      tbjorkho@james.abo.fi (Tom Bj|rkholm AT)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP byte-stream connection


Dear all,

Could someone please point me in the right direction. I have the following 
problem:

I would like to implement a two directional byte stream between a program
running on a Sun Sparc and a device (plug in card) in a PC/XT. Could 
someone point me in the right direction? Is there a good manual or book
on the subject? Or has someone even an example source code?

WHAT I HAVE:

A Sun Sparc IPX running SunOS Release 4.1.2 (GS_ACCT_IPC_SS). The Sparc
is connected to an ethernet LAN with the TCP/IP protocol. The LAN is
divided into subnets by bridges and a router (it is connected to internet
in fact). 

Connected to an other segment of the LAN is a PC/XT. The PC is an Olivetti 
M290 (8086). The PC has a 3Com 3C501 ethernet card. In the PC is also the
device/plug in card that I want to access from the Sparc. (The card is
a MicroWay Monoputer card). The PC has 640 MB RAM, a 20 MB hard disk,
a 360 kbyte floppy drive and is running DOS 5.0. The PC/XT will be a 
dedicated server for this.

WHAT I KNOW:

I know basic C programming both under Unix and DOS. I do not have any 
problem to get a DOS C program to communicate with the device (Monoputer).

WHAT I NEED TO LEARN:

- The TCP/IP packet protocol
- How to write a Unix program that connects to another computer on the 
  net and maintains a byte-stream connection with that computer.
- How to access the 3Com 3C501 card from a DOS C program.
- How to write a DOS C program that accepts a network connection from
  another computer on the network, and maintains a byte-stream connection
  with that computer.

Thanx in advance,

Tom
---
--
Tom Bjorkholm
Process Design Laboratory             Phone: +358 21 654 863
Department of Chemical Engineering    Fax:   +358 21 654 479
Abo Akademi University                Internet: tbjorkho@ra.abo.fi
Biskopsgatan 8                           or:    tbjorkholm@finabo.abo.fi
SF-20500 Abo                          Bitnet:   TBJORKHOLM@FINABO
FINLAND                               Nordunet: ABOVAX::TBJORKHOLM

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 93 20:23:01 GMT
From:      todd@uvmark.uucp (Todd Cooper)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Anyone ever use NetWare MultiProtocol Router v2.0?

We are considering using a cheap local router by buying a PC and using
NetWare's router software NetWare MultiProtocol Router v2.0.  This is much
less expensive than buying a hardware based router (Cisco, Wellfleet, 3Com, 
etc.). It will also probably be easier to maintain in house (i.e. swapping
boards, etc.).

Has anyone used this routing software for IP routing?

We do not want a bridge, we are interested in doing IP routing.

An e-mail reponse would be better, thanks.
-- 
+++++ Just leaving a boring signature. ++++++++++++++++++++++++++++++
Todd Cooper         (uvmark%todd@merk.com uunet!merk.com!uvmark!todd)
Snail Mail: Vmark Software, 30 Speen Street, Framingham, MA 01701 USA

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jan 1993 21:05:29 GMT
From:      danson@lgc.com (Doug Anson)
To:        comp.protocols.tcp-ip
Subject:   World-Wide (WAN) Network configuration questions..

Hi:

We are a medium size company who is struggling with the costs of 
implementing world wide networks. We currently have links using common 
carriers (AT&T, MCI, etc) to most locations. We plan to use CISCO routers 

with 64KB lines to our NON U.S. locations. We feel that this in a minimum 

acceptable bandwidth for our applications, some of which are X-WINDOWS 
based. We would like higher bandwidth, but costs are unacceptably high.
Currently the non U.S. locations are; London, Singapore, Calgary and 
Caracas. To offset costs we have implemented multiplexors from Republic 
Telecom that compresses and multiplexes voice and data together.

I am soliciting input to the following questions:

1. Do you have experience subleasing bandwidth from larger companies. Who 

are they. What are the legal ramifications of doing that?

2. Do you have any experience using external data compression devices to 
increase bandwidth? Are these devices practical for interactive use?

3. Do you have experience "OUTSOURCEING" networks like this? If so, what 
are the costs, relative to leasing lines from the carriers?

4. Do you have any experience with "BANDWIDTH ON DEMAND" setups?

5. Do you have any other suggestions for us?

Thanks in advance for any comments, suggestions...

Joe Norton
Manager of Telecommunications
Landmark Graphics Corporation
(713)560-1227
jnorton@lgc.com

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 93 03:19:58 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   3C509 pkt. drivers ?

In article <20JAN93.17562179@skyfox> keele@skyfox writes:

   Does anyone know if there are packet drivers around for the new 
   3C509 Etherlink III cards ? I have not seen them in the usual 
   DRIVERS.ZIP file.

They're in beta test, but you're welcome to try using it.  No guarantees,
of course.  It's ftp.msen.com:pub/vendor/crynwr/3c509g.zip.  Please tell
me if it doesn't work for you.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 1993 03:50:48 GMT
From:      tclark@med.unc.edu (Thomas B. Clark III)
To:        comp.protocols.tcp-ip
Subject:   NetManage

I would appreciate it if anyone could send me the
internet address or phone number for NetManage.

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 1993 10:12:08
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:

    We have 10 LaserJet printers which we would like to connect to a LPD
    server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
    ...
    We have looked at the Lantronix equipment, but that does not really
    offer LPD; since we have a diverse user community, we want to use the
    LPR and LPRMON software that is provided with the TCP/IP implementations.
     
A number of the DOS TCP/IP vendors offer LPD servers of varying
capabilities (B&W, Sun, FTP Software at least).  Ours is sold as a
separate product, and handles multiple simultaneous printers, spools
while printing, allows you to define multiple virtual printers with
different initializations on a single physical printer, etc. (the
same spooler is bundled into our OS/2 product).  There is also a
freeware LPD, which I think can be found on tacky.cs.olemiss.edu.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 1993 08:11:53 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   bug in ttcp: SO_RCVBUF, accept


I noticed the following weird behavior using ttcp and the 4.3BSD TCP.
(Actually a Mach 3.0 system but the binaries and the TCP code are
4.3BSD Unix).

I wanted ttcp to advertise receive windows larger than 4k so I invoked
it as follows: 

	ttcp -r -s -b 32768 -l 16384

However, packet traces were showing that the receive windows were
always 4k.  For the arguments above, ttcp does the following syscalls:

	fd = socket(AF_INET,SOCK_STREAM,0);
	setsockopt(fd,SOL_SOCKET,SO_RCVBUF,...); /* 32k rcv window */
	listen(fd,...);
	fd = accept(fd,...)

In the TCP I'm using, the accept'ed connection doesn't pick up the
modified sockbuf parameters from the parent socket and therefore the
accept'ed connection has the 4k default receive window size.  If I
change the order of calls to the following, the accept'ed connection
advertises 32k receive windows.

	fd = socket(AF_INET,SOCK_STREAM,0);
	listen(fd,...);
	fd = accept(fd,...)
	setsockopt(fd,SOL_SOCKET,SO_RCVBUF,...); /* 32k rcv window */

So my question is this.  Is the second syscall sequence what ttcp
*should* have been doing or should the accept'ed socket have inherited
the sockbuf parameters from the parent socket (and therefore my TCP is
buggy).

-- 
Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
"A unix signature isn't a return address, it's the ASCII equivalent of
a black velvet clown painting. It's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who."

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 21 Jan 1993 14:11:40 EST
From:      Tom Williams <TW@UMAB.BITNET>
To:        comp.protocols.tcp-ip
Subject:   setsockopt problem

I've got a problem using the BSD socket interface.  I'm trying to
set the time out for the read function using  the setsockopt function:

   int  sock,  time = 10;
   rc  = setsockopt(sock,SOL_SOCKET,SO_RCVTIMEO, (char *)&time,
       sizeof time);

I've previously called socket(), and it has executed correctly.  When
I call setsockopt(), I get rc = -1, and errno = 22 (EINVAL, invalid
arguement according to errno.h).

Any ideas on what I'm doing wrong?

Thanks,
    Tom

+----------------------------------------------------------------------------+
| "Work and play are words used to describe the same thing under different   |
|  conditions."                                                              |
|                                                            - Mark Twain    |
| Bitnet: TW@UMAB     Internet: TW@UMAB.UMD.EDU     Phonenet: (410)706-4134  |
| SnailNet: 100 N. Green Street, Baltimore, MD  21201                        |
 +----------------------------------------------------------------------------+

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 93 18:55:25 EST
From:      MACE@HDQCMS2H.UTSD.ATT.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <930121101208@cream.ftp.com>
jbvb@vax.ftp.com  (James B. VanBokkelen) writes:
 
>In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>
>    We have 10 LaserJet printers which we would like to connect to a LPD
>    server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
>    ...
>    We have looked at the Lantronix equipment, but that does not really
>    offer LPD; since we have a diverse user community, we want to use the
>    LPR and LPRMON software that is provided with the TCP/IP implementations.
>
>A number of the DOS TCP/IP vendors offer LPD servers of varying
>capabilities (B&W, Sun, FTP Software at least).  Ours is sold as a
>separate product, and handles multiple simultaneous printers, spools
>while printing, allows you to define multiple virtual printers with
>different initializations on a single physical printer, etc. (the
>same spooler is bundled into our OS/2 product).  There is also a
>freeware LPD, which I think can be found on tacky.cs.olemiss.edu.
>
>James B. VanBokkelen            2 High St., North Andover, MA  01845
>FTP Software Inc.               voice: (508) 685-4000  fax: (508) 794-4488
>
 
I was looking for a standalone device, rather than a process running
on a set of PCs to drive the printers... Black-Box has indicated that they
expect to have one in around March... I was hoping that there was something
with a proven track record, instead of having to be on the bleeding edge...
Thanks!
--------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ
--------------------------------------------------------------------------

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 93 15:20:43 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC protocol specifications

In article <1993Jan16.171627.4522@visionware.co.uk>, I wrote,
>The RPC protocol is in the public domain, although it was invented at
>Sun Microsystems. 

Nathaniel Mishkin (mishkin@apollo.HP.COM) wrote:
: one thing that just sends me off the deep end is when people use the
: terms "RPC" and "Remote Procedure Call" as synonyms for Sun's RPC.
 ..
: Many other RPC systems have come before and after Sun's.
 ..
: Sun seems to tend to call their RPC system either "Sun RPC" or "ONC
: RPC".

Sorry.  I do usually try to get my terminology correct.

(I assumed that the original posting was to do with Sun RPC as that's
what I've been working with lately.)  As always, context is vital.

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

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 1993 15:54:57 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Port Numbers & The RPC Portmapper

In article <1jki9vINNmr9@aludra.usc.edu> smiller@aludra.usc.edu (Stephen B. Miller) writes:
>In article <1993Jan20.162611.25831@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
>>
>>
>>I am trying to look for a solution to the problem of determining an 
>>unknown remote port number. I will appreciate any comments on the 
>>following situation:
>>
>> [text deleted, see earlier posting]
>>
>>Maritza
>>
>
>I am beginning to work an identical problem here, but have not come up with
>much more than you.  I have considered trying the dynamic update features in
>the BIND 4.8.3 code, but they are so poorly documented that I might be better
>off writing my own application.  My situation is further complicated by then
>need to change the port number assignments dynamically, which might be done
>by deregistering and reregistering with the portmapper.  If anyone else has
>ideas please feel free.....
>
>Steve Miller - smiller@aludra.usc.edu
>
>

registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the
port #.  svc_unregister() removes the entry.  pmap_getport() looks up a prog#/
version# on a host.  You must of course know the host name, prog# and version#
in advance.  Be careful about having the same prog# with different version #s.
Portmapper returns the port of a program with a match on prog #, but will give
you the latest (I believe) version # if it doesn't find an exact match.

Dig through the man pages, the info is skinny but most of it is there.  There is
also a book called "The Art of Distributed Application"  by John R. Corbin.
It is supposed to give lots of detail about Portmapper  It is part of the Sun
Tech Reference Library, published by Springer-Verlag.


Ron



-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 1993 17:10:13 GMT
From:      alech@hpindda.cup.hp.com (Alec Henderson)
To:        comp.protocols.tcp-ip
Subject:   Re: NetManage

tclark@med.unc.edu (Thomas B. Clark III) asks:

>I would appreciate it if anyone could send me the
>internet address or phone number for NetManage.

Internet:  support@netmanage.com
Phone:     408-973-7171

Regards,
Alec Henderson

Telephone: 408-447-3965         	Hewlett-Packard
FAX:       408-447-3660			Information Networks Division
E-mail:    alech@cup.hp.com	       	19420 Homestead Road MS 43L9
HPDesk:    Alec Henderson/HP6600/1B	Cupertino, CA  95014  (USA)

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jan 1993 23:36:55 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Large Windows and Delayed Acking


  I have been playing around with a TCP implementation trying to get
the throughput up and discovered an interesting anomaly with large
windows. The setup I have is a program which is an infinite data
source sending to the discard port (port 9) on a remote machine over
ethernet. I am merely measuring the bandwidth and occassionally reporting
that to the user -- nothing complicated.
  What I have found is that with large windows (say 16kb) the sending
TCP stops sending at about 4k and waits for the receiving TCP to
send an ACK. The receiving TCP, however is using a defered acking
scheme which tries to delay sending ACK until a larger window is
consolidated into one packet. The metric it is using is 1/2 the
buffer size, and the delayed ack period is on the order of 100ms.
  I can understand why a sending TCP might be leary of sending *so*
much data without hearing an ack, but my question is what algorithm
is the sending TCP using to determine how much data it will send
before going into this quiesent state? Is there an appropriate
RFC which I should read which describes this situation? Is the
behavior of the sending TCP correct?

  (BTW, I noticed that the IBM/AIX which extends a 16k window 
   has the same problem with a Sun running 4.1.2, so the problem
   is not unique to the TCP I'm futzing with...)
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 93 23:38:57 GMT
From:      kate@wavefront.wti.com (Kathy Samec)
To:        comp.protocols.tcp-ip
Subject:   Slip and SGI machines

I will have to set Slip up on a SGI Indigo soon and would like to know
what software will run in this environment. Will cslip work? Also, Who 
can I contact to get a slip connection to the internet in the NYC area?

thanks
-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec			- Everything is beautiful and
Santa Barbara Studios		  Nothing hurt.
kate@wti.com					-Stoney Stevenson

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 93 23:52:14 GMT
From:      kate@wavefront.wti.com (Kathy Samec)
To:        comp.protocols.tcp-ip
Subject:   More Slip

One more enquiry about slip. Is a particular modem necessary??

-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec			- Everything is beautiful and
Santa Barbara Studios		  Nothing hurt.
kate@wti.com					-Stoney Stevenson

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 93 00:42:03 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Port Numbers & The RPC Portmapper

In article <1993Jan21.155457.27880@panther.mot.com>, ronf@panther3.panther.mot.com (Ron Feigen) replies:
|> 
|> [text deleted, see earlier posting]
|> 
|> 
|> registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the
|> port #.  svc_unregister() removes the entry.  pmap_getport() looks up a prog#/
|> version# on a host.  You must of course know the host name, prog# and version#
|> in advance.  Be careful about having the same prog# with different version #s.
|> Portmapper returns the port of a program with a match on prog #, but will give
|> you the latest (I believe) version # if it doesn't find an exact match.
|> 
|> 
|> [text deleted, see earlier posting]
|> 
|> Ron
|> 


I was just wondering if it is possible to connect and send commands to the 
RPC portmapper without using RPC calls (svc_xxx or pmap_xxx) but tli or 
socket calls. That approach of connecting and sending commands is possible
when working with some services. For example, I have some source code that 
sends commands to an ftp server after establishing a connection with it on 
its well known port 21. That program follows the same approach as when we 
use a telnet connection to send control commands to ftp (see example).

--o--

Example:
                    ___________________ ftp's well known port
                   /
$ telnet itsname 21
Trying 128.96.133.64 ...
Connected to itsname.
Escape character is '^]'.
220 itsname FTP server ready.  _____________ ftp server accepts connection
USER maritza
331 Password required for maritza.
PASS mypass123
230 User maritza logged in.
HELP
214-The following commands are recognized (* =>'s unimplemented).
   USER     PORT     RETR     MSND*    ALLO     DELE     SITE*    XMKD     CDUP
   PASS     PASV     STOR     MSOM*    REST*    CWD      STAT*    RMD      XCUP
   ACCT*    TYPE     APPE     MSAM*    RNFR     XCWD     HELP     XRMD     STOU
   REIN*    STRU     MLFL*    MRSQ*    RNTO     LIST     NOOP     PWD
   QUIT     MODE     MAIL*    MRCP*    ABOR     NLST     MKD      XPWD
QUIT
221 Goodbye.
Connection closed by foreign host.
$

Note that when using this approach, the commands that the ftp server
recognize are the low level commands described on the RFC959 (e.g.,
PORT, PASV, RETR, STOR).

--o--

The question is: Is it possible to connect and send commands to the RPC 
portmapper using tli or socket calls ?

The protocol specifications for the portmapper (appendix A of the RFC1057) 
does not say anything about the low level commands that the portmapper 
recognizes.

Does anyone knows which low level commands must be given to the portmapper
server after a connection is established to (1) register an application, 
and (2) get the assigned port from a client application ?


Thanks,

Maritza

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 93 01:30:35 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Port Numbers & The RPC Portmapper

>registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the
>port #.

No, it doesn't.  The portmapper doesn't assign port numbers (take a look
at RFC 1057, which describes the portmapper's RPC protocol; there ain't
no call in there that *chooses* a port number and *assigns* it to a
server - there's just a PMAPPROC_SET call to bind an *already-allocated*
port number to a particular program and version number and Internet
protocol number); other code does (for example, the UDP or TCP
implementation, at least in UNIX systems).

If all you want to do is just register a port number with the portmapper
as being bound to some particular program and version number for some
particular protocol, you can do so with "pmap_set()".

The advantage of using "pmap_set()" rather than "registerrpc()" is that
you don't set up all the rest of the RPC mechanism; given that the
original poster didn't *want* to drag in the rest of the RPC mechanism,
that's probably what they want.

>svc_unregister() removes the entry.

So does "pmap_unset()", and it also doesn't pester the rest of the RPC
mechanism.

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 93 01:33:45 GMT
From:      alen@crash.cts.com (Alen Shapiro)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for OS/2, I need to disable the DOS mem-load HELP**!!

Hi netters, I have OS/2 1.33 (extended) with IBMs TCP-IP drivers. They
load (using config.sys) into both OS/2 and DOS. I only need to run
telnet sessions on the OS/2 side, I need the 180k used by these drivers
on the DOS side when the DOS window is activated.

Is there a mechanism (hack or not) to unload these drivers from DOS
and still allow OS/2 TCP-IP to survive?

Are there public domain TCP-IPs that run under OS/2 that take less than
80kb on the DOS side or do not load there at all?

Help is urgently needed on this one...thanks in advance.

please email to
	alen@crash.cts.com
and I'll summarise for the net.


-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 93 02:17:36 GMT
From:      birchall@pilot.njin.net (Shag)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   PC<->Unix connection, free/cheap?

My current connection:
	PC -normal dialup-> Cisco -> Sparc-II

My desired connection:
	PC -better dialup-> Cisco -> Sparc-II

I'm interested in establishing a PC-Unix connection over a dialup line,
with the connectivity listed above.  Any protocol (Xremote, SLIP, CSLIP,
maybe PPP) is an option, preference given to those which I could run an
X-server over.

I've had the opportunity to look at a few products so far:

CUTCP	-	Advantages: PD, cheap, not picky about what else it will run
		with.  Disadvantages: Not on the list of things that other
		picky programs will run with. :)

PC-Xview -	Advantages: X-windows, easy to configure.  Disadvantages: 
		Expensive, doesn't support PD connection protocols, works 
		best with X-Remote, which is also expensive.

PCTCP -		Advantages: Widely used, well known, terribly comprehensive.
		Disadvantages: Not PD, difficult to configure.

The Cisco in question currently supports X-Remote connections, but doesn't
have SLIP active.  I can bug The Powers That Be to turn on SLIP if that's my
only choice... X-windows would be very nice, though.

My PC is a '286, not capable of running Windows or Linux (sorry, for those
who were about to suggest those! ;), with 4 megs of RAM (well, it's capable
of running Windows, but I'm one of those annoying people that actually likes
software to execute at a usable speed! ;), 80mb hard drive (50mb free), VGA
greyscale, and a v.32bis/42bis (14400) modem.

Any ideas?  Throw 'em at me.

I'd really prefer e-mail responses to this (reply, don't followup), thanks...

-Shag
-- 
birchall@pilot.njin.net, shag@glia.biostr.washington.edu, birchall@njin.bitnet
  Operator of ShagNet - Rutgers/NJIN dialup access for Burlington County, NJ
     Happy and informative user of a PPI 14400 FaxModem and GeoWorks Pro
       Editor of the Queensryche E-mail Digest - "Screaming in Digital"

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 03:46:13 GMT
From:      amehta@minerva.cis.yale.edu (Anand R. Mehta)
To:        comp.protocols.tcp-ip
Subject:   Help with ka9q

Hello all.

I am currently trying to set up a PPP link between a NeXT and a PC, which
is on the campus ethernet.  I have the NeXT PPP implimentation working, but
cannot get the PC up.  I believe that the packet driver is installed
correctly (NCSA telnet will use it), and that the problem is one of
configuring the PC routing tables, etc.  I have not even tried ka9q with
PPP, as I cannot get it to work over ether.

Could someone who has configured ka9q to work (even without ppp) please
email me a copy of their *.net file so that I can have a look at what is
going on?  Also, any tips on where to find more documentation would be
greatly appreciated.

What I would like to have eventually is this:

============PC============ether
             |
             |
             ppp
             |
            NeXT

with ka9q routing packets between the NeXT and the rest of the world.

Any help that you can give me would be greatly appreciated.

-Anand 
Academic Computing Services
Yale University
(203) 436-1437

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 93 04:00:39 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Port Numbers & The RPC Portmapper

>I was just wondering if it is possible to connect and send commands to the 
>RPC portmapper without using RPC calls (svc_xxx or pmap_xxx) but tli or 
>socket calls.

Well, yes, it is possible - after all, ultimately, the code that
implements RPC calls generally does so using sockets or TLI calls....

I.e., yes, you can do it, but the commands you send to it are just RPC
calls, so the only way to avoid using the RPC routines is to do just
what they do....

>The protocol specifications for the portmapper (appendix A of the RFC1057) 
>does not say anything about the low level commands that the portmapper 
>recognizes.

Yes, it does.  It gives a description, "in RPC Language", of the port
mapper protocol.  If the fact that the description is given "in RPC
Language" doesn't tell you that the port mapper is an RPC service, the
fact that section 7.4.2 says, in as many words:

   Broadcast calls use the Port Mapper RPC service to achieve their
   semantics.  See Appendix A for more information.

should sure give you a clue that it's an RPC service....

I.e., no, this isn't like an SMTP or FTP server, wherein you can just
type commands at it; it's an RPC server that's just like any other RPC
server, except that it has to have a well-known port number - after all,
it's kind of hard to ask the portmapper what the port number of the
portmapper is if you don't *already* know what its port number is.

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 93 17:00:24 -0600
From:      robin@vax1.mankato.msus.edu
To:        comp.protocols.tcp-ip
Subject:   LPR and Fortran flow control RFC 1179

*********   Help    ********   Help   ********    Help    ********
I am trying to implement an LPR client using RFC 1179.  When trying to 
send fortran flow control to the server machine, I send a control file
with an 'r'+file+LF.  What exactly should I be sending as file???
Currently, I am sending the name of the df (same as is being sent by
the 03 (receive data file) subcommand.  So to sumerize I'm sending the
following data:

/*connect to remote host*/
[02]<queue>[LF]
[02]<size of control file> cfA100POJ1[LF]     /*POJ1 = hostname, 100 = JobNo */
CAS400-1.Mankato.MSUS.Edu[LF]
HAS400-1.Mankato.MSUS.Edu[LF]
J<Jobname>[LF]
L<Userid>[LF]
N<Source name>[LF]
P<Userid>[LF]
rdfA100POJ1[LF]
/*wait for ack here*/
[03]<size of data file> dfA100POJ1[LF]
<insert entire data file here>
[0]
/*wait for ack here*/
/*disconnect*/

For output we get a complete printout on the host... but the fortran flow
control is NOT interpreted and the "1" "0" "+".. etc. are printed.

Please reply directly to:

j3gum@vax1.mankato.msus.edu
AND
robin@vax1.mankato.msus.edu



THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU 

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 09:35:51 +0000
From:      phil@calibra.demon.co.uk (Philip A Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: NetManage

In article <6200055@hpindda.cup.hp.com> alech@hpindda.cup.hp.com writes:

>tclark@med.unc.edu (Thomas B. Clark III) asks:
>
>>I would appreciate it if anyone could send me the
>>internet address or phone number for NetManage.
>
>Internet:  support@netmanage.com
>Phone:     408-973-7171
>
>Regards,
>Alec Henderson
>
>Telephone: 408-447-3965                 Hewlett-Packard
>FAX:       408-447-3660                 Information Networks Division
>E-mail:    alech@cup.hp.com             19420 Homestead Road MS 43L9
>HPDesk:    Alec Henderson/HP6600/1B     Cupertino, CA  95014  (USA)
>

-- 
Philip A Smith

                                 U
                  D              N
                  O     T   N    I
                  S P E C I F (I X )
                        P   S
                        I
                  S U P P O R T


        SPECIF(IX) FOR SEAMLESS DOS UNIX INTEGRATION

        For anyone else interested in a genuine Windows DLL TCP
        and client server NFS product please contact:

        UK. Specifix 0629 732982

        In the USA.
        NetManage Inc. Tel :0101 408 973 7171  Fax:0101 408 257 6405

        Email: Joseph L'Italien. Director of International Sales.
               Dan Geisler. Director of Marketing
        
        info@netmanage.com

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1993 12:24:13 GMT
From:      andreas@informatik.rwth-aachen.de (Andreas Fasbender)
To:        comp.protocols.tcp-ip
Subject:   Sequence Numbers in TCP/IP

Can somebody answer a stupid question:

What is the reason for the difference in the lenght of the window-field
(16)
and the sequence-number-field (32 bit). Using 16-bit-numbers for sequencing
and acknowledging could spare 4 byte in each packet.
Hope this isn¬ęt a faq.

Thanks
Andreas


:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
:    Andreas Fasbender       Institute of Computer Science IV     :
:                            Aachen University of Technology      :
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 14:26:37 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence Numbers in TCP/IP

Andreas Fasbender (andreas@informatik.rwth-aachen.de) wrote:
: Can somebody answer a stupid question:
: 
: What is the reason for the difference in the lenght of the window-field
: (16)

The window is how much the other end is prepared to accept (65535 implies
infinite). (this is bigger than the maximum packet size on every network
I have ever seen)

: and the sequence-number-field (32 bit). Using 16-bit-numbers for sequencing
: and acknowledging could spare 4 byte in each packet.

Sequence measures how much has been sent.

Both of these are measured in octets (8 bit bytes), it is quite reasonable
to expect a TCP link to send more that 64K octets in one session.
: Hope this isn+t a faq.
: 
--

-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 16:28:17 GMT
From:      amolitor@nmsu.edu (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: Large Windows and Delayed Acking

In article <1993Jan21.233655.29402@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>
>  What I have found is that with large windows (say 16kb) the sending
>TCP stops sending at about 4k and waits for the receiving TCP to
>send an ACK. The receiving TCP, however is using a defered acking
>scheme which tries to delay sending ACK until a larger window is
>consolidated into one packet. The metric it is using is 1/2 the
>buffer size, and the delayed ack period is on the order of 100ms.
>  I can understand why a sending TCP might be leary of sending *so*
>much data without hearing an ack, but my question is what algorithm
>is the sending TCP using to determine how much data it will send
>before going into this quiesent state? Is there an appropriate
>RFC which I should read which describes this situation? Is the
>behavior of the sending TCP correct?

	Sounds like the sender's computing a congestion window
around 4K. See, say, Steven's _Internetworking with TCP/IP_ or
probably rfc793 somewhere or other. Steven's has a good exposition.

	The point is that TCP makes a guess at a good sending
window size based on latency of packets, and uses the minimum
of that window size and the remote's advertisement as the real
window. This is used to avoid congestion. It might even be that
the delayed ACK cause the sender to compute an artificially
small congestion window (4K seems small to me).

	One must keep in mind that TCP is polite. If the goal is
to hammer your media to death, TCP is the wrong protocol. Not, by
the way, to suggest that this is your goal.

	Andrew

>		Michael Thomas	(mike@gordian.com)

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 18:19:10 GMT
From:      jdoyle@phy.umassd.edu (Jim Doyle)
To:        comp.os.mach,comp.protocols.tcp-ip
Subject:   Re: SLIP under Mach 3.0

In <1japc9INNh14@bigboote.WPI.EDU> ralf@wpi.WPI.EDU (Ralph Valentino) writes:

>Has anyone gotten SLIP to work under Mach 3.0?  /etc/slattach from
>2.6MSD reports "ioctl(TIOCSETD): No such device" when run under 3.0
>mk77 ux37.

	It sounds like your Unix server is not properly configured for
SLIP. TIOCSETD is the ioctl argument that you use to change the line
discipline on a tty. My guess is that when slattach opens the tty
line and tries to set SLPDISC the kernel cant find that discipline
descriptor in its switch table. 

	We have problems here with MK78/UX39 SLIP - I have been meaning
to port in CSLIP v2.6 to it but just have been too tired / too busy to
get to it. It should be a pretty easy thing. If you wanna try to beat me
to the punch you can get it from ftp.ee.lbl.gov  - use the BSD4.3
installation as a guide. You basically gotta add some things to 
tty_conf.c to make it jive.

--
Jim Doyle
Univ. of Massachusetts - Dept. of Computer Science
doyle@cs.umass.edu


-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 18:32:07 GMT
From:      jswanson@csfb1.fir.fbc.com (James Swanson)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with termcap/terminfo needed

|> I have an application running on 2 different flavours of Unix.  The applicati
 on
|> uses function keys F1 to F4.  The are defined as generating ESC-@ ESC-A ESC-B
|> ESC-C.  On one system they are passed in to the application as the appropriat
 e
|> function keys and on the other arrive separately as ESC and then @/B/C etc.
|> All the terminal definitions are exactly the same.
|> This looks like a timing problem.  Is there a code that can be modified to
|> fix this or is my problem somewhere else ? (Like in the application which is
|> Informix and about which I know sweet **??!!)
|>
|> AdvThx
|>
|> --
|> Jo Baker, D9                        |email: jo@siesoft.co.uk
|> Siemens Nixdorf, Oldbury,           |Tel:   +44 344 850450
|> Bracknell, Berks, RG12 4FZ          |Fax:   +44 344 850096

I had this exact problem using Informix on AIX 2.0.  This symptom would
occur only when I was accessing AIX through a psuedo terminal (telnet or
rlogin).  I tried to get help from Informix and AIX, but each said the other
was crewing up (suprise!).
The problem is caused by timing, as you suspected, in the AIX pseudo-
terminal driver.  If the ESC and the @/A/etc. are received in separate
packets, they will be delivered separately to the application.  The application
is supposed to wait long enough after an ESC for the following character
to determine if it is an escape sequence (there must be a better way).  In
the case of AIX, and possibly other systems, the time between delivery of
the 2 packets is too long.

Finally, I solved this by writting a "wrapper" around the Informix application.
The wrapper would read from stdin and "bunch-up" any escape sequences before
delivering them to the application in one "write()".

The wrapper:
        opened the "tty" in a mode that allowed all cahracters to pass
        Forked a child which exec()'d the Informix application
        The wrapper tied its stdout to the child's stdin
        The wrapper passed every character to the application
        if the wrapper saw an ESC, it checked for a follow-on character
          with a reasonable timeout
        If none came, the ESC was passed
        If one did come, the ESC and the follow-on were passed together
          in the same buffer.

The wrapper can be tweeked to get the best timeout value, optimize character
throughput by reading with NOWAIT, etc.

I wish I still had the code to share with you, but this was two jobs ago
and I have lost track of it.

Hope this helps.




-- 
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 19:23:50 GMT
From:      jswanson@csfb1.fir.fbc.com (James Swanson)
To:        comp.protocols.tcp-ip
Subject:   Re: Distributed NFS

|>> Looking for a method of replicating NFS file systems...
 !>
|> There's already a product available that does this called  the Isis Reliable
 Network File System
|> from Isis Distributed Systems Inc.  Their mail address is ids@isis.com.
|>

Thsnks for your suggestion.  I already reviewed the ISIS product.  It has
several shortcomings:
        It will only export 1 file system for the entire network.
        It will not premit any other NFS mounted systems to be exported from
          the same server.
        It still has some nasty bugs.

I need to be able to use the "automounter" and "secure NFS" packages as well.
I think the best solution will include a mechanism to maintain synchroni-
zation without imposing too many non-standard restrictions.  As I mentioned
before, I would like to find a way to use the BIOD or NFSD daemons to
s: 

Subject: Re: Distributed NFS

|>> Looking for a method of replicating NFS file systems...
 !>
|> There's already a product available that does this called  the Isis Reliable
 Network File System
|> from Isis Distributed Systems Inc.  Their mail address is ids@isis.com.
|>

Thanks for your suggestion.  I already reviewed the ISIS product.  It has
several shortcomings:
        It will only export 1 file system for the entire network.
        It will not premit any other NFS mounted systems to be exported from
          the same server.
        It still has some nasty bugs.

I need to be able to use the "automounter" and "secure NFS" packages as well.
I think the best solution will include a mechanism to maintain synchroni-
zation without imposing too many non-standard restrictions.  I would like to 
find a way to use the BIOD or NFSD daemons to provide this funcitonality.

-- 
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 19:34:32 GMT
From:      mgic <mgic@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip
Subject:   Problem with RPC and inetd


I am having a problem getting my RPC service started using inetd.  I am working
on a SparcStation 2 and using Sun's rpcgen to generate my client and server
'stubs'.  The RPC client and server work fine if I start the server up myself
but when I try to start it using inetd, the client just returns without a
message.  I have,
	1. Used rpcgen with the -I option. (to enable inetd support)
	2. Made an entry in the /etc/inetd.conf file for the service.
	3. Made an entry in the /etc/rpc file for the service.
Also, running rpcinfo shows the service listed as being a service known to
the portmapper.

What am I doing wrong?

Anand Prahlad
mgic@mixcom.com
-- 

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jan 1993 21:14:25 GMT
From:      jswanson@csfb1.fir.fbc.com (James Swanson)
To:        comp.unix.aix,comp.edu,comp.protocols.tcp-ip
Subject:   Re: HELP NEEDED TO MAKE ETHERNET AND TOKEN RING COEXIST ON RS6K

In article <1993Jan21.164446.21646@oucsace.cs.ohiou.edu>, sivkumar@dolphins.ent.ohiou.edu (Krish Sivakumar) writes:
|> We have a IBM RS6000 530H running TCP/IP under AIX 3.2.3
|> The machine is fully configured and operational with ethernet.
|> We are trying to set up a local token ring using the 
|> Token Ring Adapter in the same Machine and planning to use the
|> ethernet as the Token Ring's Gateway to the outside world.
|> 
|> We are not quite sure how to go about doing this. Initial attempts ended
|> up in the ethernet getting rendered inactive
|> 
|> Any suggestions, comments, ideas, solutions or thoughts are more than welcome.
|> Thanks
|> -- 
|> -----------------------------------------------------------------------
|> - Krish Sivakumar			Drive Defensively, Buy a tank -
|> - Dept. of Mechanical Engineering      	-------------------------------
|> - Ohio University,			-     /\   /\


It should be a simple matter to define each of the network adapters to have
a different address and put 2 addresses for your host in the host file.  You
may need to assign a different subnet to each network card rather than simply
a different host address, but one or the other should work fine.  This is a
standard feature of IP.

Once the network cards are set up, you infrom the other nodes that they may
route through the dual-ported node to access the folks on the other side.

-- 
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jan 1993 00:25:17 GMT
From:      kent@humu.nosc.mil (Kent K. Kuriyama)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Multiple class 'C' addresses versus single class 'B'

I would like to get comments regarding the problems of using multiple
class 'C' addresses vice a single class 'B' addresses.  Obviously
this is an issue because the NIC is hesitant in granting the rapidly
diminishing number of class 'B' addresses.

We intend to have approximately 2000 IP addresses with typically 50
address per sub-net.  Using class 'C' address we are looking at 40 sub-
nets or approximately 10 'C' addresses.

Questions:

1)  What kind of management problems will we run into if we use class
'C' vice 'B'?  It seems to me that use of multiple class 'C' addresses
would not change the number of routers required - the number of sub-nets
dictates that.

2)  Someone mentioned that linking up a bunch of 'C' addresses will
require the use of some external gateway protocol (make sense - we need
to route between class 'C' networks) on our routers.  Is this a big
deal?  Is EGP a feature only available on expensive routers?

3)  Are there any advantages to getting a contiguous set of class 'c'
addresses (e.g. 192.101.190,191,192, . . . etc)?

4)  Would there be any problem in implementing a single domain name
DNS over multiple class 'C' addresses?

Thanks.

Kent Kuriyama
kent@nosc.mil

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 93 00:27:37 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence Numbers in TCP/IP

>The window is how much the other end is prepared to accept (65535 implies
>infinite). (this is bigger than the maximum packet size on every network
>I have ever seen)

Yes, but, as far as I know, it's not required that the sending TCP stuff
everything into one packet, and there's a "TCP Big Window" option
mentioned in RFC1106, to increase the maximum window size beyond 64K. 

There's also an RFC, RFC1110, entitled "A Problem with the TCP Big
Window Option"; both date back to mid-1989, and not being a full-time
networking weenie, I don't know what the state of Big Windows in TCP is
(except that I seem to remember Vernon Schryver talking about cranking
the window size up when using FDDI, in order to light the fibre up, so I
suspect there's at least a semi-stable standard for Big Windows).

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 93 02:45:51 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence Numbers in TCP/IP

In article <16594@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
|> >The window is how much the other end is prepared to accept (65535 implies
|> >infinite). (this is bigger than the maximum packet size on every network
|> >I have ever seen)
|> 
|> Yes, but, as far as I know, it's not required that the sending TCP stuff
|> everything into one packet, and there's a "TCP Big Window" option
|> mentioned in RFC1106, to increase the maximum window size beyond 64K. 
|> 
|> There's also an RFC, RFC1110, entitled "A Problem with the TCP Big
|> Window Option"; both date back to mid-1989, and not being a full-time
|> networking weenie, I don't know what the state of Big Windows in TCP is
|> (except that I seem to remember Vernon Schryver talking about cranking
|> the window size up when using FDDI, in order to light the fibre up, so I
|> suspect there's at least a semi-stable standard for Big Windows).

RFC 1323 is the latest RFC describing big windows.  It is basically an
update to RFC's 1072 (window scaling, time-stamps for rtt measurement,
and selective acknowledgements) and 1185 (using the same time-stamps for
rejecting old, duplicate segments).  The selective acknowledgement was
dropped from 1323 because it was felt that more research needed to be
done.

RFC 1106 was another method of getting >64K windows.  I don't know much
about it.  The problem with big windows described in RFC 1110 (that a 32-bit
sequence number isn't good enough with 30-bit windows) was addressed in RFC
1185 and refined in RFC 1323.

RFC 1323 is pretty solid.  SGI's next major OS release will include a
TCP that can do RFC 1323 (both window scaling, and time-stamps).

Vernon nearly saturates an FDDI ring with a couple of Indigos and a single
TCP connection with a 60K window (no window scaling needed).  But, he likes
to crank up the window to 128K+ to squeeze the last 0.2 MBytes/s out.
Since the "big windows" will be available soon, you'll be able to try this
at home.


-- 
---
Thomas Skibo         Advanced Networking, Silicon Graphics     skibo@sgi.com

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jan 1993 03:44:53 GMT
From:      vish@ngc.com (Vish Mulchand)
To:        comp.protocols.tcp-ip
Subject:   TCP Testing

I am curious to know how TCP/IP is being tested. I would be interested in
almost anything related to testing of TCP/IP and this would include 
automated TCP testers, conformance tests, test cases/suites, philosophies
experiences and other information that might prove to be useful.

Regards
Vish Mulchand
vish@thor.ngc.com
(415) 688-2849 

-- 
Vish Mulchand
Network General Corporation
vish@thor.ngc.com
(415)688-2849

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 93 16:30:20
From:      braudes@proto.Read.TASC.COM (Bob E. Braudes)
To:        comp.protocols.tcp-ip
Subject:   Re: Large Windows and Delayed Acking

What is the incoming buffer size advertised by the receiver?  If it is
4K, like it sounds, then the sender will stop sending after this 4K
has been sent and not acknowledged.

Bob Braudes
TASC


-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jan 1993 11:35:44 GMT
From:      amolitor@moink.nmsu.edu (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   TCP congestion/Nagle's algorithm


	Darn it, I think I put my foot in my mouth. After poking
through rfc896 (in which Nagle introduces his algorithm for
solving the 'small packet' problem) and comparing with Karn's
NOS TCP implementation, I find myself confused.

	First, I misunderstood congestion windows. My apologies
to whoever it was I responded to a day or so ago, blithely
dismissing throughput problems as 'sounds like a small congestion
window.'

	Second, Nagle seems to be saying that a TCP should not
send new data while unack'd data is outstanding, while Karn's
code seems to not send new data while unack'd data is outstanding
*unless* there is a max segment sized chunk to go out.

	Karn's version seems right, since it allows proper
streaming, while Nagle's seems to reduce the sliding window
to a stop and wait arrangement. Is Karn's algorithm in Nagle's
remarks, disguised as a tacit assumption that one always sends
all the data one has, in multiple segments? He seems to be implying
that as soon as one gets an ack, one sends all the data one has
on hand. This is still not quite Karn's implementation, I think.

	Andrew

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jan 1993 12:05:52 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Multiple class 'C' addresses versus single class 'B'

Kent K. Kuriyama (kent@humu.nosc.mil) wrote:
: I would like to get comments regarding the problems of using multiple
: class 'C' addresses vice a single class 'B' addresses.  Obviously
: this is an issue because the NIC is hesitant in granting the rapidly
: diminishing number of class 'B' addresses.
: 
: We intend to have approximately 2000 IP addresses with typically 50
: address per sub-net.  Using class 'C' address we are looking at 40 sub-
: nets or approximately 10 'C' addresses.

There is something called supernetting, which is analogeous to subnetting
which allows a group of class C addresses to be treated as one entity.

: 
: Questions:
: 
: 1)  What kind of management problems will we run into if we use class
: 'C' vice 'B'?  It seems to me that use of multiple class 'C' addresses
: would not change the number of routers required - the number of sub-nets
: dictates that.
: 
: 2)  Someone mentioned that linking up a bunch of 'C' addresses will
: require the use of some external gateway protocol (make sense - we need
: to route between class 'C' networks) on our routers.  Is this a big
: deal?  Is EGP a feature only available on expensive routers?
: 
: 3)  Are there any advantages to getting a contiguous set of class 'c'
: addresses (e.g. 192.101.190,191,192, . . . etc)?

You do need a continious group for the supeneting, the group must be
a power of 2 (2,4,8,...)

: 
: 4)  Would there be any problem in implementing a single domain name
: DNS over multiple class 'C' addresses?
: 
: Thanks.
: 
: Kent Kuriyama
: kent@nosc.mil

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jan 1993 13:20:41 GMT
From:      christes@socrates.umd.edu (Skip Christensen)
To:        comp.unix.aix,comp.edu,comp.protocols.tcp-ip
Subject:   Re: HELP NEEDED TO MAKE ETHERNET AND TOKEN RING COEXIST ON RS6K

In article <C19xo1.D61@csfb1.fir.fbc.com> uunet!csfb1!jswanson writes:
>In article <1993Jan21.164446.21646@oucsace.cs.ohiou.edu>, sivkumar@dolphins.ent.ohiou.edu (Krish Sivakumar) writes:
>|> We have a IBM RS6000 530H running TCP/IP under AIX 3.2.3
>|> The machine is fully configured and operational with ethernet.
>|> We are trying to set up a local token ring using the 
>|> Token Ring Adapter in the same Machine and planning to use the
>|> ethernet as the Token Ring's Gateway to the outside world.
>|> 
>|> We are not quite sure how to go about doing this. Initial attempts ended
>|> up in the ethernet getting rendered inactive
>|> 
>|> Any suggestions, comments, ideas, solutions or thoughts are more than welcome.
>|> Thanks
>|> -- 
>|> -----------------------------------------------------------------------
>|> - Krish Sivakumar			Drive Defensively, Buy a tank -
>|> - Dept. of Mechanical Engineering      	-------------------------------
>|> - Ohio University,			-     /\   /\
>
>
>It should be a simple matter to define each of the network adapters to have
>a different address and put 2 addresses for your host in the host file.  You
>may need to assign a different subnet to each network card rather than simply
>a different host address, but one or the other should work fine.  This is a
>standard feature of IP.
>
>Once the network cards are set up, you infrom the other nodes that they may
>route through the dual-ported node to access the folks on the other side.
>
>-- 
>Jim Swanson
>First Boston Corporation
>5WTC - 9th floor
>New York, NY 10048
>(212)322-1085

I agree - I've installed a model 340 with its built-in Ethernet (one
address), a second Ethernet (another addreess) and a dual-ring FDDI
(with its own address).  No problem.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1993 14:28:11 GMT
From:      rv@deins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Multiple class 'C' addresses versus single class 'B'

In article <1993Jan23.002517.22830@nosc.mil>, kent@humu.nosc.mil (Kent K. Kuriyama) writes:
  > I would like to get comments regarding the problems of using multiple
  > class 'C' addresses vice a single class 'B' addresses.  Obviously
  > this is an issue because the NIC is hesitant in granting the rapidly
  > diminishing number of class 'B' addresses.
  > 
  > We intend to have approximately 2000 IP addresses with typically 50
  > address per sub-net.  Using class 'C' address we are looking at 40 sub-
  > nets or approximately 10 'C' addresses.
don't forget that in both the host and the subnet field of an IP address
you should NOT use the values 0 and -1 (all ones).
This implies that the subnetting a class C network can be done in only
the folowing ways:

bit split	# of subnets	max # addr/subnet	total max # usable addrs

0:8		1		254			254
1:7	** illegal **
2:6		2		62			124
3:5		6		30			180
4:4		14		14			196
5:3		30		6			180
2:6		62		2			124
7:1	** illegal **
0:8	** nonsense **

Of course things look different when CIDR is fully available (i.e. you
use a supernet of 2*n class Cs and can ignore the 24:8 split of class C).

  > Questions:
  > 
  > 2)  Someone mentioned that linking up a bunch of 'C' addresses will
  > require the use of some external gateway protocol (make sense - we need
  > to route between class 'C' networks) on our routers.  Is this a big
  > deal?  Is EGP a feature only available on expensive routers?
no, for routing within your "routing domain" you can use the same interior
gateway protocols as you would use within a single B.  Exterior gateway
protocols like EGP (if starting to use one, better try going for BGP)
are only needed between different autonomous systems - i.e. network compounds
with a separate administratgion and routing policy.

  > 3)  Are there any advantages to getting a contiguous set of class 'c'
  > addresses (e.g. 192.101.190,191,192, . . . etc)?
YES;  supernetting - need a power of two with a common prefix

  > 4)  Would there be any problem in implementing a single domain name
  > DNS over multiple class 'C' addresses?
NO - IP addresses and domain names are two COMPLETELY independant name spaces!
The domain name service usually is used to provide a mapping between (some)
IP addresses and domain names;  this mapping can be defined in any way you want.

--
Ruediger Volk
Universitaet Dortmund, Informatik IRB				DE-NIC
Postfach 500 500
D-W-4600 Dortmund 50
Germany

E-Mail: rv@Informatik.Uni-Dortmund.DE
Phone:  +49 231 755 4760                 Fax:  +49 231 755 2386

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 93 16:43:58 GMT
From:      alen@crash.cts.com (Alen Shapiro)
To:        comp.protocols.tcp-ip
Subject:   IBM OS/2 TCP-IP uses DOS (low) memory? HELP ME PLEASE!!

I'm in a bind...

I have OS/2 v1.33 (can't use 2.0 due to lack of suitable device drivers)
I have an application that runs on a LAN (IBM Adaptor card) under OS/2
and talks with another application on DOS (can't put the DOS app. on
OS/2 due to lack of device drivers!!)

The OS/2 side needs to open a telnet session with a remote host. I have
IBMs TCP-IP (latest release = 2.1.1 (or thereabouts)).

The problem is that IBMs TCP-IP uses DOS memory for its 2 drivers IFNET
and INET. Each driver uses 100k and another 140k seems to be unavailable
to DOS (even with a fairly cut-down CONFIG.SYS). With 340k out of 640k
unavailable to DOS, I can't run my 360k DOS application.

QUESTIONS:
1) Why is 140k out of 640k unavailable to DOS with even a minimal
   CONFIG.SYS (i.e. no TCP-IP or LAN drivers)? ... Can this be changed?
   (RMSIZE is = 640 in CONFIG.SYS)
2) Can the TCP-IP drivers be persuaded to load high and thus be unavailable
   to DOS (and not use its memory) (I only need telnet from OS/2)?
3) Are there any TCP-IP packages (commercial or not) that either take a
   small chunk of DOS memory or none at all?
4) Are there utilities that will show me which drivers are using how much
   memory?

Please help me...I'm in a maze of twisty passages all alike!!

--alen
Please email to
	alen@crash.cts.com
I'll summarize for the net.



-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jan 1993 04:27:07 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Moving from coax to 10BaseT

In a recent column in OST James Gaskin suggests that system administrators
should be converting ethernets from coax to 10BaseT and *not* investing
anything more in coax.  I put two questions to the readers of this group:

1) Do you concur with Mr. Gaskin that coax is dead or dying?

2) What options are available for small (less than a dozen nodes) networks
currently running coax and wanting to move to 10BaseT?  For example, I
understand that 10BaseT topology has all nodes wired to hubs - are there hubs
available which are cost effective for small networks?

I look forward to your replies...

Frank.
--
___________________________________________________________________
Frank I. Reiter                 Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jan 1993 23:10:44 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  

hmm, how nice of OST.  don't suppose they mentioned that you should kill
your unix boxes and put up OS/2, NT or Netware?  or even better, putting in
an AS/400, cause it so easy to get one, "just point and order".

>I put two questions to the readers of this group:
>
>1) Do you concur with Mr. Gaskin that coax is dead or dying?

for new buildings, dead, except for the possibiliy of backbone pulls of
thick coax to connect wiring centres, but then you might consider fiber.
'
for existing buildings, if you are pulling new cable, pull UTP.  you
will probably save some money on media.  you will spend it later in hubs.

twisted pair gives you more options, ethernet, token ring, CDDI (copper version
of FDDI), etc.

as far as converting coax to twisted pair, it's your call. if what you have
works, keep it.  you can connect 10baseT and thinnet networks.

>2) What options are available for small (less than a dozen nodes) networks
>currently running coax and wanting to move to 10BaseT?  For example, I
>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>available which are cost effective for small networks?

hubs come in many sizes, 4, 8, 12, 16 port stan alone, racks which take 8/12,
16 port cards, etc.
another selection you can make is "manageable" hubs.  hubs with SNMP management
tend to be almost double the cost (my experience) but worth it.

i find that coax is cool for tabletop/workbecnch testing, or workgroups that
have reasonable airspace around them.

having UTP throughout the building now allows us to wire 10baseT, Starlan1,
tokenring, RS232 and other stuffwith the same wire.  life is much better.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416-506-0654 ]
[                      longer life through colder blood                       ]

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jan 1993 23:36:27 GMT
From:      dvv@hq.demos.su (Dima Volodin)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: Netblazer

xcuse me for deviating, anyway:

We're running a slip link from here in Moscow to Alternet in VA, USA. Runs
OK, but: I had to turn V.42/V.42bis off. Reason? It looks like V.42 window
is too small for the huge roundtrip echo delay time (>=.5sec) we experience.
When V.42/V.42bis was enabled, all we could have from ftp and friends was
500-700 bytes/sec, with V.42 turned off we have more pleasant 1100-1300
bytes/sec. Pity we cannot use V.42bis. Anyone knows how to make V.42 window
larger on Telebit and/or ZyXEL?


Dima
 

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 1993 05:31:09 GMT
From:      tga@oar.net (Germann Associates)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM OS/2 TCP-IP uses DOS (low) memory? HELP ME PLEASE!!

In article <alen.727807438@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes:
>I'm in a bind...
>
>I have OS/2 v1.33 (can't use 2.0 due to lack of suitable device drivers)
>I have an application that runs on a LAN (IBM Adaptor card) under OS/2
>
>QUESTIONS:
>1) Why is 140k out of 640k unavailable to DOS with even a minimal
>   CONFIG.SYS (i.e. no TCP-IP or LAN drivers)? ... Can this be changed?
>   (RMSIZE is = 640 in CONFIG.SYS)


Because the kernal and most of the device drivers in OS/2 1.x had to load
low.  This was to support the DOS box.  Some of the device drivers are
dual mode (i.e.  they are user by both the DOS compatibility coffin and
the OS/2 sessions themselves).

And no, there ain't no way to change it.  Guess you're SOL.


>2) Can the TCP-IP drivers be persuaded to load high and thus be unavailable
>   to DOS (and not use its memory) (I only need telnet from OS/2)?

Nope

>3) Are there any TCP-IP packages (commercial or not) that either take a
>   small chunk of DOS memory or none at all?

I'll defer this and the next to the rest of the net......

>4) Are there utilities that will show me which drivers are using how much
>   memory?
>
>Please help me...I'm in a maze of twisty passages all alike!!
>
>--alen
>Please email to
>	alen@crash.cts.com
>I'll summarize for the net.
>
>


-- 
============================================================================
Eric Germann                "You see things; and you say 'Why'  But I dream
The Germann Associates       things that never were; and I say 'Why not?'"
eric@tga.com                -- "Back to Methuselah"  G.B. Shaw 1921 

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 1993 20:29:50 -0800 (PST)
From:      Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

Just to add a side note to thinnet vs. 10BaseT argument.

I have a computer zoo in my residence.  The connectivity between the zoo
critters is thinnet, for two reasons:
 1) I'm too cheap to buy a hub
 2) one of the critters is a sweet old dinosaur who, when she gets the right
    connecting cable and a bit of programming, will think she is talking
    thicknet (albeit coerced to thinnet).

In spite of the limited scope of my thinnet, I have spent entirely too much
time debugging it.

If I were to do it again, I'd probably make it 10BaseT and figure some way to
coerce the dinosaur to play the 10BaseT game.


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 1993 09:03:31 GMT
From:      geertj@ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   solaris FTP bug (was: Re: Determining Port Numbers....)

maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:

>Example:
>                    ___________________ ftp's well known port
>                   /
>$ telnet itsname 21
>Trying 128.96.133.64 ...
>Connected to itsname.
>Escape character is '^]'.
>220 itsname FTP server ready.  _____________ ftp server accepts connection
>USER maritza
>331 Password required for maritza.
>PASS mypass123
>230 User maritza logged in.
>HELP
>214-The following commands are recognized (* =>'s unimplemented).
>   USER     PORT     RETR     MSND*    ALLO     DELE     SITE*    XMKD     CDUP
>   PASS     PASV     STOR     MSOM*    REST*    CWD      STAT*    RMD      XCUP
>   ACCT*    TYPE     APPE     MSAM*    RNFR     XCWD     HELP     XRMD     STOU
>   REIN*    STRU     MLFL*    MRSQ*    RNTO     LIST     NOOP     PWD
>   QUIT     MODE     MAIL*    MRCP*    ABOR     NLST     MKD      XPWD
>QUIT
>221 Goodbye.
>Connection closed by foreign host.
>$

Please note that Maritza probably used a solaris 5.1 machine to display this;
you can tell because the response to the HELP command is incorrect.
The last line of the response should start with 214<space> to show that
this is the last line of the response.

There are probalby going to be zillions if machines that have this problem.
Has anybody found yet where SUN moved the FTP help response file?

Geert Jan


-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 1993 09:51:34 GMT
From:      geertj@ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

Frank@mindlink.bc.ca (Frank I. Reiter) writes:

>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  I put two questions to the readers of this group:
>1) Do you concur with Mr. Gaskin that coax is dead or dying?

No, most certainly not. 10baseT is point-to-point. Which means that you
have to have a separate connection between the HUB and every apparatus
in your office. In my case, this would mean that I'd fill more than one
hub, just for my own equipment!

Coax has the big advantage that a new tap can be easily made by adding
another T and a piece of coax to the existing wiring.

10baseT is best if you have to run an office of non-technical people that
move around a lot and don't know they have to jumper their ethernet tap
if they move. Also, if they are sluggish about their cables and break
one once a while, 10baseT can be a lifesaver. (coax would mean that you
have to hunt for the defective tap every time, like a defect light bulb
in a christmas tree).

However, for an office of techies, often having more than one device
on their bench, I still very much prefer coax.

And then, one should not make an ethernet string too long anyway.
No more than 5 people depend on a single string to work here. Also, those
five are able to fill that segment quite severely so it's no use putting
up much machines.

Coax isn't 'dead'. It's just that for some applications, there are 
alternatives these days.

Geert Jan


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1993 19:47:10 -0500
From:      ian@agranat.Agranat.com (Ian Douglas Agranat)
To:        comp.protocols.tcp-ip
Subject:   IP Multicasting across routers

I am designing a proprietary application for which IP multicasting across 
routers may be desirable.  I am curious if anyone has any information regarding:

	1. Which router vendors support RFC 1112 for routing IP multicast 
	   packets across subnets?

	2. What kind of performance penalty or processing overhead is typically
	   associated with IP multicasting both within a host and within the
	   routers?

	3. What kinds of applications use IP multicasting today?  How widely
	   used are they?

	4. What policies exist for the registration of well-known IP multicast
	   addresses?

I don't have time to read this group often, so please send replies directly to
me at ian@Agranat.COM.

Any help would be greatly appreciated.


-- Ian Douglas Agranat
   Agranat Systems, Inc.
   ian@Agranat.COM

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 93 13:52:28 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes:
>Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>
>>In a recent column in OST James Gaskin suggests that system administrators
>>should be converting ethernets from coax to 10BaseT and *not* investing
>>anything more in coax.  I put two questions to the readers of this group:
>>1) Do you concur with Mr. Gaskin that coax is dead or dying?
>
>No, most certainly not. 10baseT is point-to-point. Which means that you
>have to have a separate connection between the HUB and every apparatus
>in your office. In my case, this would mean that I'd fill more than one
>hub, just for my own equipment!

	You aren't limited to single-star topolgies.  Buy small
(10-12 port) hubs and chain them together with AUI cables.  If you're
starting from scratch, 10BaseT is the way to go, IMHO.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
What does it profit a man if he gains the whole world, but still runs DOS?

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 1993 14:08:43 GMT
From:      smb@research.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article <1993Jan25.095134.25886@ica.philips.nl>, geertj@ica.philips.nl (Geert Jan de Groot) writes:
> Coax has the big advantage that a new tap can be easily made by adding
> another T and a piece of coax to the existing wiring.
> 
> 10baseT is best if you have to run an office of non-technical people that
> move around a lot and don't know they have to jumper their ethernet tap
> if they move. Also, if they are sluggish about their cables and break
> one once a while, 10baseT can be a lifesaver. (coax would mean that you
> have to hunt for the defective tap every time, like a defect light bulb
> in a christmas tree).

This is exactly why I much prefer 10BaseT, even for technical folks.
Briefly, 10BaseT is much easier to *manage*.  You can isolate faults
much more quickly.  Each segment is independent, and you're not relying
on the quality of vampire taps.  From experience, they're often difficult
to get right.  And failures are hard to find.  Besides, no matter how good
your technical people are, you're still vulnerable to random electricians
accidentally cutting your coax, and mending it with wire nuts and black
tape.  (No, I'm not making this one up....)

There's a second major advantage to 10BaseT -- you can install lots more
``just in case'' wiring.  Twisted pair cable is cheap; you can afford to
have lots of it in the walls of offices you don't think need more
connections.  If and when you need them, you can just cross-connect at
a patch panel.  You can't do that with coax -- at best, you can put
15 wire cables into the wall.  But those are much more expensive, and
you still have to install a transceiver.  (Well, yes, you could have
a patch panel of multi-port transceivers in your wiring close, but
the distance limitations will get you.)

For folks who really need many offices with multiple connections,
thin-wire coax might be an acceptable compromise.  You still get to
isolate segments, and you still get the advantages of a patch panel
and relatively cheap wire.  I fear, though, that thin-wire coax might
be a dinosaur.  10BaseT has most of its advantages, uses cheaper, multi-
purpose wire, and more standard components.  Its one disadvantage -- that
you need a separate hub port for each device -- is offset by the continuing
drop in hardware prices.  I tend to doubt that much new thin-wire gear
is going to show up on the market.

Thickwire coax is, in my opinion, useful primarily in machine rooms.
The configuration is comparatively static; electrically, it's a high-
noise environment, and you don't want to put all your file server eggs
in one active basket.  Even so, a failed coax can put you off the air
much longer than it takes to swap out a failed hub.

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1993 16:44:44 GMT
From:      schuetz@fm11ap01.tu-graz.ac.at (Alexander Schuetz)
To:        comp.protocols.tcp-ip
Subject:   Please tell a newbie the differences betw FSP and FTP and ...


Hi dudes, 

I hope you don't mind some FAQs (?) from a newbie, do you? Well, I need
some technical info about FTP, FSP, TELNET and stuff like that....

1.) What is FSP exactly? I know and have seen FTP already and been told
    that FSP is kinda similar. What are the differences? Is there a program
    "FSP.EXE" for the IBMPC, similar to the "FTP.EXE" from FTP software?
    Or, is there a public domain version? 
    If not, is there atleast a UNIX version? Is is shareware anyway?
    If it *is* shareware, on which FTP site, in which subdir might I
    find it? If not, where can I find info, anyway?

2.) Our "tn.exe" (telnet) preferres to make fuss. Sometimes I can easily
    connect to an FTP site, but at the same time TN would't want to 
    connect. ("Host unrechable, destination unreachable"). Strange...
    In general, TELNET seems not to want to connect as easily as FTP. 

Any help is greatly appreciated, E-mail answers preferred 'coz I cant
sift through all the news everyday.

Thanks
        Alex (schuetz@fm11ap01.tu-graz.ac.at)







-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1993 01:07:09 -0500
From:      tal@plts.uucp (Tom Limoncelli)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In <1993Jan24.231044.16138@xenitec.on.ca> merce@xenitec.on.ca (Jim Mercer) writes:

>having UTP throughout the building now allows us to wire 10baseT, Starlan1,
>tokenring, RS232 and other stuffwith the same wire.  life is much better.

This the the crux of the matter.  Making life easier.  10baseT does
have a lot of advantages in that regard.  My favorite is the ability to
run "n" UTP lines to each office and you can use them for "n" of the
following: phone, 10baseT, appletalk, serial, second phone, serial
line, [I'm sure others can add to this list.]

However, converting an old office building that's already wired for one
kind of networking to any other is a whole 'nother matter.  No 2-page
article in a throw-away networking magazine can tell you what's right
for you.  I would never convert an entire building from one networking
technology to another without a LOT of thought about what my needs might
be in the next i years (where i is different depending on your
corporate culture).

I think the real question is "Why are industry pundits starting to
recommend 10baseT all over the place?"  I think the answer to that is
simple:  They know that all the new machines coming out have it built
in.  Look at the back of all the new SparcLX/SparcClassic, the DEC
Alpha, HP, etc.[*] and guess what's there.  Also, they know that
by the time a person needs to convert from 10baseT to the next level
of networking [CDDI?] someone will have developed a way to run
it over UTP.  (or so we all hope :-) ).

I laugh in December when every industry pundit writes a column of
"predictions for next year".  Most of what they list are things that
they've been told under non-disclosure but they don't name the company.
For example, "This will be the year for ISDN" was a good prediction
for 1993 since anyone with a couple non-disclosure agreements could 
tell you that EVERY new machine has ISDN hardware because EVERY
computer company thinks that Mitch's EFF is going to get congress
to pass their ISDN package.  Nostradamus?  Bah.  He just had
the right connections.

Tom

Footnote: [*] I would have listed the Sparc 10 but that would be
unrealistic since everyone knows that they aren't really shipping.  Oh
sure, Sun shipped a few so their press-releases can say that they're
shipping, but talk to anyone that has ordered one and you'll find that
they've been told "next week" for the last 3 months.  I doubt they'll
ship in quantity for another year and by then Sun should have developed
a chip who's design wasn't DOA.  ...but that's just my opinion.
If you want to have fun with a Sun salesthing:  Next time they tell
you "next week" bet them dinner that it won't arrive in the next 7 days.
-- 
Tom Limoncelli -- tal@plts.uucp (home) -- tal@warren.mentorg.com (work)
Moderator of ne-social-motss and the Drew University Alumni/ae mailing lists.
"There is nothing wrong with America that cannot be cured by what is
right with America." --Bill Clinton's inaugural address, 1/20/93

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 93 18:29:38 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes:
>No, most certainly not. 10baseT is point-to-point. Which means that you
>have to have a separate connection between the HUB and every apparatus
>in your office. In my case, this would mean that I'd fill more than one
>hub, just for my own equipment!

In my building, they just give each engineer an eight port 10baseT
fan-out unit (i guess the official term is "micro repeater").  I've
got two in my office.  Am i breaking some 10baseT rule?

>10baseT is best if you have to run an office of non-technical people...

Actually, i've seen no correlation between "non-technical people" and
coax failure.  If anything, the more technical the people, the more
often they try to modify the cabling.  With coax, the failure rate seems
to be almost directly proportional to the frequency of modifications,
and the difficulty of finding a failure increases geometrically in
relation to the number of people that make modifications.

I was really mystified a couple of years ago when they started pulling
miles of 10baseT to replace our "perfectly good" coax, but in retrospect
i must admit that our networks are much more stable than with the coax.

						don provan
						donp@novell.com

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1993 19:09:55 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP congestion/Nagle's algorithm

In article <1993Jan23.113544.5652@nmsu.edu> amolitor@moink.nmsu.edu (Andrew Molitor) writes:
>	Second, Nagle seems to be saying that a TCP should not
>send new data while unack'd data is outstanding, while Karn's
>code seems to not send new data while unack'd data is outstanding
>*unless* there is a max segment sized chunk to go out.

I thought the latter is what Nagle said, too, but I just went and reread
it, and I think you're right.  He doesn't talk about sending immediately
when one can send a full packet.  RFC 1122 amends the 896, though, and
1122 does say that one should not wait for an ack before sending an MSS-
sized packet.

Perhaps what happened is Jacobson's Slow Start and Congestion Avoidance
algorithms provided a better way to solve the broader congestion problem,
so Nagle's algorithm is now used only for smaller-than-MSS packets.

RFC 1122 has a nice description of how all of the different "when to send"
algorithms, including Nagle's, fit together.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 93 20:48:39 GMT
From:      joeg@novell.com (Joe Gervais)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article <1993Jan25.182938.6414@novell.com> donp@novell.com (don provan) writes:
>In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes:
>>No, most certainly not. 10baseT is point-to-point. Which means that you
>>have to have a separate connection between the HUB and every apparatus
>>in your office. In my case, this would mean that I'd fill more than one
>>hub, just for my own equipment!
>
>In my building, they just give each engineer an eight port 10baseT
>fan-out unit (i guess the official term is "micro repeater").  I've
>got two in my office.  Am i breaking some 10baseT rule?

IEEE allows 4 repeaters between any two end stations.  I've seen two common
approaches.  For the site with the technical people that insist on using
thinnet or 10base2 in their offices or labs because it's "easier to work
with", 10baseT is used to feed the lab or office, and a 10baseT to 10base2
repeater is installed.  MIS gets the advantage of individual manageable
segments to each office or lab, and the engineers get to keep their coax,
but Bob removing a terminator or BNC tee in his office will not break the
LAN in John's office.

The second approach is the one Don mentioned, which is to structure the LAN
so each office or LAB can have one more layer of repeaters.

A legal topology diagram that abides by the 4 repeater, no more than 3 
tapped coax segments is as follows:

                     10base5 or 10base2 backbone
                   -------------------------------
                        |          |         |
                     --------  --------  --------
 Wiring Closets      | rptr |  | rptr |  | rptr |
                     --------  --------  --------
               _______| |          |         |<----FOIRL or 10baseT
-  -  -  -  - | -  -  - | -  -  -  | -  -  - | - -
              |         |          |         |     
          --------   --------  --------  --------
 Labs /   | rptr |   | rptr |  | rptr |  | rptr | 
 Offices  --------   --------  --------  --------
          |  |  |    |  |  |   |  |  |   |  |  |<---any media

If you draw the topology as a tree, with a coax backbone, you can go down
two levels of repeaters maximum, and the links between the two levels of 
repeaters must be link segments, or you will exceed the 3 populated coax
segment rule.  Note that with this topology, a large total number of
repeaters can be used, because you aren't restricted to how many repeaters
off the backbone segment, or how many repeaters off the first layer of
repeaters, just as long as between any two DTEs, you don't traverse more
than 4 repeaters.  The problem I've usually seen is using 10baseT hubs
and making three layers of repeaters, which puts five repeaters in the path
between two DTEs.  So Don, please be sure your second micro-repeater is not
daisy-chained off the first, and you're probably okay.

Joe Gervais
Joe_Gervais@Novell.com

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jan 1993 23:16:55 GMT
From:      TOVSRUD@gribb.hsr.no (Tovsrud, Kjell Ove     1-94)
To:        comp.protocols.tcp-ip
Subject:   What is TCP/IP ?

Can sombody out there give me a better discription about TCP/IP ?
I have to learn what this is !!!

Thanks!

Kjell Ove	

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 00:28:14 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM>, MACE@HDQCMS2H.UTSD.ATT.COM writes:
>We have 10 LaserJet printers which we would like to connect to a LPD
>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
> 
>We would rather not use LPD on various machines directly connected to
>the printers, since we would lose access to the printer when the machine
>went down (was re-booted or powered off).
> 
>The connections would be serial (RS-232), with one connection being
>parallel.
> 
>We have looked at the Lantronix equipment, but that does not really
>offer LPD; since we have a diverse user community, we want to use the
>LPR and LPRMON software that is provided with the TCP/IP implementations.

Hmm. That's funny. I have the Lantronix EPS1 here that does LPD
and it works fine.


		-John Kalucki
		johnk@gordian.com


-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 93 08:03:54 EST
From:      MACE@HDQCMS2H.UTSD.ATT.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <1993Jan26.002814.1015@gordian.com>
johnk@gordian.com (John Kalucki) writes:
 
>
>In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM>, MACE@HDQCMS2H.UTSD.ATT.COM writes:
>>We have 10 LaserJet printers which we would like to connect to a LPD
>>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
>>
>>We would rather not use LPD on various machines directly connected to
>>the printers, since we would lose access to the printer when the machine
>>went down (was re-booted or powered off).
>>
>>The connections would be serial (RS-232), with one connection being
>>parallel.
>>
>>We have looked at the Lantronix equipment, but that does not really
>>offer LPD; since we have a diverse user community, we want to use the
>>LPR and LPRMON software that is provided with the TCP/IP implementations.
>
>Hmm. That's funny. I have the Lantronix EPS1 here that does LPD
>and it works fine.
>
>
>                -John Kalucki
>                johnk@gordian.com
>
 
According to Lantronix, their unit really does RTEL, which can be made
to appear to be LPD.  The problem is that you must use Lantronix supplied
software (not standard LPR software), and that software is only supported
for Unix.  Since we have DOS, Windows, OS/2 and VM/CMS Lantronix indicated
that we were out of luck.  They said that they would be providing true
LPD support in 2Q93, but still only supported for Unix (since the
microcode upload is only supported on Unix).  Thanks for the reply, though!
--------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ
--------------------------------------------------------------------------

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 03:38:09 GMT
From:      karl@empirical.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT


>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  I put two questions to the readers of this group:
>
>1) Do you concur with Mr. Gaskin that coax is dead or dying?
>
>2) What options are available for small (less than a dozen nodes) networks
>currently running coax and wanting to move to 10BaseT?  For example, I
>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>available which are cost effective for small networks?

I lead the Interop "wipe out thinnet" brigade.  I strongly agree that 
thinnet should go the way of punched cards.

About the *only* remaining use for thin-net any more is where you have a 
cluster of machines, say a collection of X terminals, all in one room.  When 
we design and build Interop, that is the only way we will use cheapernet.

(We now use fiber-optic Ethernet rather than thick coax for the long runs.)

I would never run thin-net through a wall and I would never put it where 
high reliability is required.  Because coax (whether thick or thin) does not 
limit termination or shorting problems, it tends to break whenever a user 
gets it into his mind to move something.

10-Base-T, on the other hand, is much more robust.  The wire itself is more 
solid.  (And if you use the standard 4-pair stuff, you get two spare pairs, 
just in case.)  If you use level 4 or level 5 wire, you can run it quite a 
long distance.  The RJ45 connectors tend to be pretty solid, much more so 
than most coax connectors (at least with respect to how they connect to the 
cable itself.)

10-Base-T hubs also often have very nice properties -- they can block out 
screeming (jabbering) hosts, block hosts which are sending mal-formed 
packets, enforce security, etc.  They often gather interesting statistics 
about which hosts are using the net, etc.

The 10-Base-T link state light itself is worth many man-hours of saved labor 
whenever a user calls up and says "my machine isn't talking on the net."

On some hubs you can also disable retiming.  This can increase your repeater 
budget, and hence allow end-users to put in their own fan-out boxes.

			--karl--



-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 05:36:46 GMT
From:      wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: Netblazer

>We're running a slip link from here in Moscow to Alternet in VA, USA. Runs
>OK, but: I had to turn V.42/V.42bis off. Reason? It looks like V.42 window
>is too small for the huge roundtrip echo delay time (>=.5sec) we experience.
>When V.42/V.42bis was enabled, all we could have from ftp and friends was
>500-700 bytes/sec, with V.42 turned off we have more pleasant 1100-1300
>bytes/sec. Pity we cannot use V.42bis. Anyone knows how to make V.42 window
>larger on Telebit and/or ZyXEL?

Such a feature would be nice.

Another thing that would be useful is a way to push (flush) the
current v.42 packet out of the modem.  This would be very useful at
the end of TCP packets, to cut down on a bit of the delay.  

I wonder if any modem manufacturers is doing work in this regard.

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 06:00:55 GMT
From:      liu@samui.trl.OZ.AU (Richard Liu)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   tn3270 emulation over PPP or slip lines

  I am  asking this question on behalf of a colleague. Is it possible
to run a tn3270 block mode emulation over asynchronous dial up slip
or PPP lines ? Is this the way to go ? Is there a better option.
The requirment is to have access via dial up slip or PPP lines to 
3720 hosts as well as unix hosts.




-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 07:19:09 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence Numbers in TCP/IP

In article <andreas-220193121931@i2pc5.informatik.rwth-aachen.de>
   andreas@informatik.rwth-aachen.de (Andreas Fasbender) writes:
>What is the reason for the difference in the lenght of the window-field
>(16) and the sequence-number-field (32 bit).
>Using 16-bit-numbers for sequencing
>and acknowledging could spare 4 byte in each packet.

First, let me acknowledge that I understand the question. Since these
quantities are of the same dimension, they could be expected to be in
the same units.

(1) When the protocol was specified, the typical longhaul link speed
    was 56 kbps, and the maximum bytes-in-flight tended to work out to
    around 2000, so 64KB of window seemed adequate.
    Today, we are trying to run this across the country (300 ms round
    trip delay) on Gigabit pipes, so 64 KB of window is too little.
    An addendum to TCP allows larger windows to be specified.
(2) On a gigabit link, even the sequence numbers might wrap around
    during the packet lifetime. The "large windows" TCP extension
    includes PAWS - protection against wrapped sequence.

It would not be unreasonable to specify 64 bits for each of these fields
in a new protocol suite (or count both in frames instead of bytes - the
ISO way).
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 07:22:51 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR and Fortran flow control RFC 1179

In article <1993Jan22.170024.2775@vax1.mankato.msus.edu>
   robin@vax1.mankato.msus.edu writes:
>For output we get a complete printout on the host... but the fortran flow
>control is NOT interpreted and the "1" "0" "+".. etc. are printed.

The file is printed as transmitted. How would the print server host know
that this file came from FORTRAN ?

You need the format the FORTRAN Format Control (not flow control, that
means something else entirely) in a filter on the sending side.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 07:30:42 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Multiple class 'C' addresses versus single class 'B'

In article <1993Jan23.002517.22830@nosc.mil>
   kent@humu.nosc.mil (Kent K. Kuriyama) writes:
>We intend to have approximately 2000 IP addresses with typically 50
>address per sub-net.  Using class 'C' address we are looking at 40 sub-
>nets or approximately 10 'C' addresses.

Right now is a really bad time to have to make this kind of decision.
Today, it will be really painful to run with the C's; next year most
routers will probably start to know how to do this.

>Questions:
>
>1)  What kind of management problems will we run into if we use class
>'C' vice 'B'?  It seems to me that use of multiple class 'C' addresses
>would not change the number of routers required - the number of sub-nets
>dictates that.

Mostly yes.

>2)  Someone mentioned that linking up a bunch of 'C' addresses will
>require the use of some external gateway protocol (make sense - we need
>to route between class 'C' networks) on our routers.  Is this a big
>deal?  Is EGP a feature only available on expensive routers?

Currently, the only routing protocol that understands subnet masks is
OSPF. New versions under development by router vendors extends this
capability to
	RIP version 2
	BGP version 4

>3)  Are there any advantages to getting a contiguous set of class 'c'
>addresses (e.g. 192.101.190,191,192, . . . etc)?

If you get the multiple C's, be sure to get a block that's aligned on a
power of 2; eg 192.208.16.0 - 192.208.31.255. When the newer protocols
are in place, this will allow your network to only take up one route
entry in the backbone.
>
>4)  Would there be any problem in implementing a single domain name
>DNS over multiple class 'C' addresses?

No problem.


-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 08:20:27 GMT
From:      cfor@ciba-geigy.ch (Rainer Foeppl)
To:        comp.protocols.tcp-ip
Subject:   Telnet VT100/VT200 for TCP/IP on MVS (IBM large Systems)


Hello
We have TCP/IP on MVS installed on our IBM Mainframes. IBM supports for Telnet
only linemode or their own 3270 Datastream.
But there is an independent vendor who sells the telnet interface for VT100 and
VT200 type terminals.

Is anybody out there aware of such a software-product and can give me the
address / phone # from the vendor ?

Thank you very much for your help
R. Foeppl
Ciba-Geigy AG
Address cfor@ciba-geigy.ch
Fax +41-61-675585

-- 
Rainer Foeppl
email: cfor@ciba-geigy.ch

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 93 13:31:45 EST
From:      reganm@bluemoon.use.com (Mark T Regan)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP ?

TOVSRUD@gribb.hsr.no (Tovsrud, Kjell Ove     1-94) writes:

> Can sombody out there give me a better discription about TCP/IP ?
> I have to learn what this is !!!
> 
> Thanks!
> 
> Kjell Ove	

Check your local library or see if you can get a copy of "Internetworking
with TCP/IP" by Douglas E. Comer, ISBN 0-13-468509-9.
?

Mark T. Regan
   
NAXI8EM on IBMLINK
USNAT6R9 on IBMMAIL
X.400: C=US;ADMD=IBMX400;PRMD=IBMMAIL;SURNAME=REGAN;GIVENNAME=REGANM

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 09:15:12 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP ?

TOVSRUD@gribb.hsr.no writes:
> Can sombody out there give me a better discription about TCP/IP ?
> I have to learn what this is !!!

Better than what?

My favorite starting point is Comer's "Internetworking with TCP/IP",
available from Prentice Hall. Get it from your nearest bookstore...

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

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 15:33:37
From:      art@midnight.midnight.com (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   If you run 2+ nets on 1 wire, please read


I've seen a lot of talk about people on the net running more than one network
on the same wire. I'd like to ask someone a bunch of possibly niave questions
and rather than waste more bandwidth, I'm asking if you do this if you could
send me your email address and let me send you my questions. Thanks.

--


...............................................................................
  Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154 
  art@midnight.com : Phone 617/890-1001 Fax 890-0028 -- Network Consulting --


-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 12:42:20 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   MacTCP and window size

This may be an FAQ (though I've looked in the MacTCP information
produced by Eric Behr at spider.math.ilstu.edu but can't find anything
relevant) and if so I apologise.

We have a number of Macs running various versions of NCSA Telnet (with
and without MacTCP), Eudora etc..  We have one particular one, a IIfx
with an Apple ethernet card, which occasionally fails to make IP
connections to other hosts; not all the time, just sometimes.  It is
using MacTCP and the problem occurs with both Telnet and Eudora.  For
the interested what actually happens is that the host accepts the TCP
connection and then resets it.  The sequence is as follows:

1) Mac sends initial TCP connect packet (SYN) offering window of 1218
   bytes and TCP option of MSS of 536. 

2) Host responds (ACK and SYN) with its own window size of 4096 and MSS
   of 1480. 

3) Mac then ACKs this packet with its window still set at 1218 and no
   further TCP options. 

4) Host sends RST flag to reset the call.

I presume the host has decided that it can't cope with the combination
of a TCP window size of 1218 and an MSS of 1480.  We get exactly the
same behaviour when using either NCSA Telnet or Eudora.  On other
occasions, i.e.  when the thing works, the same Mac advertises a window
of 4221, as do other Macs using MacTCP, and everything works
beautifully. 

Since this seems to be independent of the specific application I assume
it's a MacTCP problem, possibly a shortage of memory.  Unfortunately I
don't know of any way of configuring memory for MacTCP (presumably it
uses the System heap) and can only guess that there's a general shortage
of System memory at the moments when this problem happens.  I'll
continue to investigate (though the machine is actually 2 miles away
from my office!) but if anyone has come across this sort of behaviour
I'd be interested in knowing. 

As I said it's a IIfx and Inter*Poll says System B1-7.0.1, Finder
B2-7.0, LaserWriter 7.1.1, Responder 201, AppleTalk 56, AppleShare 7.0. 
I don't know which version of MacTCP.


Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 13:34:34 GMT
From:      wdrdjh@thor.cf.ac.uk (Dr D J Harvey 92)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip address assignments

We are currently setting up a small tcp/ip network.

Although there are no plans to connect to the rest of the world at
present, I fell that it would be prudent to use unique, rather than
random, IP addresses, to allow for future possibilities.

How would I go about obtaining a class C network address (254
addresses), and does it cost ?

-- 
Dave Harvey  
(harveydj@cardiff.ac.uk)  tel: +44 222 552588
Dept Radiology, University Hospital of Wales, Heath Park, Cardiff CF4 4XW, UK

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 14:33:48 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP ?

Tovsrud, Kjell Ove     1-94 (TOVSRUD@gribb.hsr.no) wrote:
: Can sombody out there give me a better discription about TCP/IP ?
: I have to learn what this is !!!
: 
: Thanks!
: 
: Kjell Ove	

There are RFC's describing the formal spec (they can be fairly heavy going).
There is also a guide, which originates from Rutgers uni, which describes
the operation and the packet level constructs.

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 18:30:11 GMT
From:      skarupp@eng.clemson.edu (sudhager karuppaih)
To:        comp.protocols.tcp-ip
Subject:   MTU-discovery

Keywords: mtu

i am doing some work on MTU- discovery (to find the minimum MTU from the sender to 
the receiver using a probe frame so that the datagram need not be fragmented by the 
gateways along the route)

i have material from RPC that are 2 years old, so if any one has a  knowledge of
recent research in this field please send me a mail as to where i can find them.

your co-operation is greatly appreciated,

please send reply to 

skarupp@eng.clemson.edu




-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 18:55:14 GMT
From:      pietro@nova.bellcore.com (Pietro Manzoni)
To:        comp.protocols.tcp-ip
Subject:   Generic IP address

Is there anybody who knows if it's possible to send a message specifing a
generic address.

I'm not talking of multicast, I'm just wondering if it could be possible
to send a datagram without specifing a destination address.

This type of datagram should be interpreted as: the first host that receives
the datagram is the destination host...


Thanks for any help.

-- Pietro

+------------------------------------------------+
|Pietro Manzoni                                  |
|email: pietro@nova.bellcore.com                 |
+------------------------------------------------+

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 19:29:44 GMT
From:      4carroll_j@spcvxb.spc.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Compressed slip packet driver?


 Hi,
 
 	Can anyone tell me where I might find a compressed slip packet driver?
 
 Thanks
 Jim Carroll
 

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 20:57:03 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

don provan
> In my building, they just give each engineer an eight port 10baseT
> fan-out unit (i guess the official term is "micro repeater").  I've
> got two in my office.  Am i breaking some 10baseT rule?

No.  10baseT rules say you can have up to four repeaters between any two
nodes; five if one is a fiber repeater.  (Four if all the repeaters are
fiber repeaters.)  Since all the 10baseT repeaters I know about have
both 10baseT and 10base2 (ThinCoax), there should be no problem
migrating an old network to 10bT.  Drop a repeater off the coax and plug
10bT devices into the repeater's 10bT ports.  In fact, HP recommends
using 10b2 as the backbone of its 10bT repeaters and bridges.

- Steve Kao

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 93 22:30:12 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: tn3270 emulation over PPP or slip lines

In article <1993Jan26.060055.11756@trl.oz.au> liu@samui.trl.OZ.AU (Richard Liu) writes:
   Is it possible to run a tn3270 block mode emulation over
   asynchronous dial up slip or PPP lines?

If your tn3270 (or any other) application works over any other IP
network, it will work over a SLIP or PPP link.  Only the performance
will differ.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jan 1993 22:44:29 GMT
From:      salkield@csqx.cs.rhbnc.ac.uk (Tom Salkield)
To:        comp.protocols.tcp-ip
Subject:   Info wanted on TCP/IP vs OSI 7 layer


I am posting on behalf of a friend who needs to compare the layers of
the internet protocol suite with the OSI seven layer model as part of
his course assignment.

I was wondering whether any reports exist, possibly available by
anonymous ftp, on this subject ?

Many thanks,

Tom
--
Information Security Group              |  mail: salkield@cs.rhbnc.ac.uk
Computer Science Department             |  uucp: ...!mcvax!uknet!rhbnc!salkield
Royal Holloway, University of London    |  talk: +44 784 443436 (direct)
Egham, Surrey TW20 0EX, England         |   fax: +44 784 443420

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 1993 01:10:41 GMT
From:      duane@anasazi.com (Duane Morse)
To:        comp.protocols.tcp-ip
Subject:   EAGAIN error with poll() -- what resource is too small?

The poll() system call may return -1 with errno set to EAGAIN.  I have
two questions regarding this condition.

First, is there a kernel resource which has run dry which can be
increased by some tuning parameter to prevent this?

Second, how should software handle this condition?  For instance, can
the software depend on getting a SIGPOLL signal later if poll was unable
to tell the software what to examine in the first place?
-- 

Duane Morse	e-mail: duane@anasazi.com
(602) 861-7609

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 1993 02:14:43 GMT
From:      root@kilowatt (Kilowatt admin)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: Netblazer

>>We're running a slip link from here in Moscow to Alternet in VA, USA. Runs
>>OK, but: I had to turn V.42/V.42bis off. Reason? It looks like V.42 window
>>is too small for the huge roundtrip echo delay time (>=.5sec) we experience.
>>When V.42/V.42bis was enabled, all we could have from ftp and friends was
>>500-700 bytes/sec, with V.42 turned off we have more pleasant 1100-1300
>>bytes/sec. Pity we cannot use V.42bis. Anyone knows how to make V.42 window
>>larger on Telebit and/or ZyXEL?
>
>Such a feature would be nice.
>
>Another thing that would be useful is a way to push (flush) the
>current v.42 packet out of the modem.  This would be very useful at
>the end of TCP packets, to cut down on a bit of the delay.  
>
>I wonder if any modem manufacturers is doing work in this regard.
>
>-wolfgang

	I would call Telebit Technical Support (from Moscow?) about this.
There a LOT of undocumented registers beyond 255, accessible by using the
AT~D1 command. After this command is issued, do a AT&V and see all those neat
registers!
	Telebit has told me about two of them, 500 and 501. Both have something
to do with PEP (not pertinent here, but good for an example). They have
something to do with compression, or window sizes, or packet size negotiation
or something. Don't remember what they did, just what values to use to get
better speed under certain conditions.
	I would ask them if any of these registers will cure the problem. They
are VERY helpfull in the area of getting their modems to work correctly under
strange conditions. And not just registers could be at fault. It may be the
version of the firmware in the modems, etc. etc.

-- 
Kilowatt Computers - (516) 253 2805	Arthur Krewat
Deer Park, NY				...!kilowatt!krewat
(516) 667-6142 Zoom V.32bis		I'm in the uucp maps or try
(516) 586-4743 WorldBlazer PEP/V.32bis	...!uunet!areyes!kilowatt!krewat

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 02:31:52 GMT
From:      jrb@rigel.cs.pdx.edu (James Binkley)
To:        comp.protocols.tcp-ip
Subject:   query about 2 subnets/1 segment and directed bcast

Back to 2 subnets on 1 segment again:

Greetings,

I was wondering if anyone might have any insight
into the following situation that involves 2 subnets
on the same ethernet segment:

Given the following setup:

net 140.140.1.0 subnet mask 255.255.255.0
net 140.140.2.0 subnet mask 255.255.255.0

The local topology is something like this:

default router:
		aix box  1.100
		  |
	cisco ---------------- subnets 1 and 2 (same wire) -------
					 | zymurgy
					 1.240/2.240

We have an experimental server on zymurgy that is sending 
out a directed broadcast on net 2 as 140.140.2.255. 
Zymurgy has the capability to have 2 ip addresses
attached to a single enet device.
		140.140.1.240
		140.140.2.240
It is sending the directed bcast out to 2.255 as an
ethernet bcast.

So anyway we have the real net '1' and the experimental
subnet on top of it, '2'. 

For "no apparent reason" an aix box and an hp X terminal too 
(both on net 1 with 1 interface and 1 ip address on that
interface)
are picking up the directed broadcast and forwarding it
as a unicast packet to the "default" cisco router.
Why a broadcast on another ip subnet is forwarded
is beyond me. The aix box is forwarding the packet too (
ip ttl is decremented; netstat -s shows forwarding count
incremented ). (Of course, it also happens
to not be a router in the real sense of the word -
The cisco then forwards
the unicast back to zymurgy but it has been told
already (via static routes) to forward any
default net 2 subnet packets to zymurgy -- so that is the
correct move. Nothing but static routes -- no rip or
any kind of dynamic routing used here.
Any insights here?  Mine is: "Life with 2 subnets
in the presence of buggy tcp/ip implementations can be
interesting :->"

			Jim Binkley
			jrb@cs.pdx.edu

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1993 19:07:32 -0800
From:      stahara@xlate.hsc.usc.edu (Stanley Tahara)
To:        comp.sys.sun.apps,comp.protocols.tcp-ip
Subject:   Need printcap for HP LJ4

Hi,

I need some help.  We are trying to install an HP Laserjet 4 on a 
SPARCstation 1.  Our university computing guys say they need a 
printcap for this printer, suuposedly we are the first at USC to 
try this.  Anyway I spoke to HP customer service and they said to 
contact Sun.  I thought I would try here first.  I would greatly
appreciate any assistance.

Thank you.

-- 
|Stan Tahara                   Dept. of Microbiology            |    
|Phone:   (213)-342-1722       USC School of Medicine           |
|FAX:     (213)-342-1721       stahara@xlate.hsc.usc.edu        |
*********** AGUACUGCUAAUUUAGAUUAU ACUGCCCAUGCACGUGAG*************

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 06:02:03 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip, schuetz@fm11ap01.tu-graz.ac.at
Subject:   Re: Please tell a newbie the differences betw FSP and FTP and ...

In article <1k15dsINNl17@fstgds15.tu-graz.ac.at> you write:
>1.) What is FSP exactly? I know and have seen FTP already and been told
>    that FSP is kinda similar.

In 12 years on the Internet, I have never heard about a protocol called
FSP.

>2.) Our "tn.exe" (telnet) preferres to make fuss. Sometimes I can easily
>    connect to an FTP site, but at the same time TN would't want to 
>    connect. ("Host unrechable, destination unreachable"). Strange...
>    In general, TELNET seems not to want to connect as easily as FTP. 

The owls, they are not what they seem ...
It is very common these days for routers to set up packet filters
that differentiate between FTP and TELNET. Many sites do not allow ANY
incoming TELNET traffic. The hosts that are unreachable by TELNET but
can be reached by FTP, are they hosts that you have been explicitly
authorized to TELNET to ? Do you have (legal) accounts on them ?

>Any help is greatly appreciated, E-mail answers preferred 'coz I cant
>sift through all the news everyday.

In general it is considered to be extremely rude to be too busy to read
the replies to your own postings ... You may not have time to read all
the news every day, but you should set aside time to read the groups to
which you are posting ...
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1993 11:21:33 GMT
From:      kenh@leps5.phys.psu.edu (Ken Hornstein)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR and Fortran flow control RFC 1179

In article <1993Jan26.072251.8942@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>In article <1993Jan22.170024.2775@vax1.mankato.msus.edu>
>   robin@vax1.mankato.msus.edu writes:
>>For output we get a complete printout on the host... but the fortran flow
>>control is NOT interpreted and the "1" "0" "+".. etc. are printed.
>
>The file is printed as transmitted. How would the print server host know
>that this file came from FORTRAN ?

Isn't there a code you can send using the lpr protocol that tells the
print server host that the client is using FORTRAN carriage controls?
I thought there was, but it's been a while ....

--Ken

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 1993 11:53:12 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <SALKIELD.93Jan26224429@csqx.cs.rhbnc.ac.uk>, 
salkield@csqx.cs.rhbnc.ac.uk (Tom Salkield) writes:

>I am posting on behalf of a friend who needs to compare the layers of
>the internet protocol suite with the OSI seven layer model as part of
>his course assignment.

If you find any treatment of this that is both thorough and also 
objective and neutral, please let the rest of us know!

Almost any computer networks textbook will spend a page or two stating
that TCP corresponds to OSI Transport, IP to OSI net, but IP is 
connectionless while OSI is CO. That's about it - sometimes I wonder
how they can spend several pages saying nothing more.

Then you have the fighting young priests, making detailed comparisons
for the sole purpose of showing how useless (wretched or whatever) one
alternative is, compared to the other. For an excellent example of
this approach you may read M.T.Rose's treatment of OSI Session in The
Open Book. (If anyone would like to read my 40-page comment to The Open
Book, give me a hint and I'll mail it to you as a Postscript file.)

If a text exists at M.T.Rose's level of detail, but without his personal
opinions and judgements, I would be *very* happy to know of it!


Ketil Albertsen, 
College lecturer in computer communication courses

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 15:44:59 GMT
From:      rbz@edsr.eds.com (Rodger B Zeisler)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

salkield@csqx.cs.rhbnc.ac.uk (Tom Salkield) writes:


>I am posting on behalf of a friend who needs to compare the layers of
>the internet protocol suite with the OSI seven layer model as part of
>his course assignment.
 
>I was wondering whether any reports exist, possibly available by
>anonymous ftp, on this subject ?

I just purchased a book, "TCP/IP Network Administration" by Craig Hunt.
It is a nutshell handbook from O'Reilly & Associates, Inc.  Chapter 1
is an "Overview of TCP/IP" and it explains about the 7 layer OSI standard
versus the 4 layer TCP/IP standard.


<Rodger>

+-------------------------------+-------------------------------------------+
|  Rodger B. Zeisler            |  Work Phone:  (214) 661-6241              |
|  Electronic Data Systems Corp |  Home Phone:  (214) 517-4884              |
|  7171 Forest Lane             |  INTERNET: uunet.UU.NET!edsr.eds.com!rbz  |
|  MS C210                      |        or  uunet.UU.NET!edsr!bigdaddy!rbz |
|  Dallas, TX  75230            |  COMPUSERVE:  71563,2160                  |
+-------------------------------+-------------------------------------------+

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 1993 16:30:33 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   LPnet and LPD/LPR client machines?


Is the System V Rel 4 lpnet network printing support
supposed to be compatible with older BSD type systems
based on lpr/lpd ?  

In particular how do I set up a System V rel 4 Unix 
system to support non-unix clients using lpr & lpd 
to submit print jobs to the new Unix systems.

I have notes on setting this up on Solaris but then
Sun can be expected to include this as an extra since
previous versions of SunOS used the BSD system. These
notes are not generic enough to cover an NCR ATT Unix
system used at another site.

How many of you have integrated non-unix clients and
a SYSV Rel 4 server and how did you do this?


Thanks for any replies. e-mail me and I shall post
the outcome.



================================================
Steven Vincent,             steven@unipalm.co.uk
Unipalm Ltd.                (44) 0223-420002
Cambridge,
England.
================================================
Subject:  
Summary:  
Keywords:  



-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 17:31:25 GMT
From:      yedidya@bimacs.BITNET (Yedidya Israel)
To:        comp.protocols.tcp-ip
Subject:   reverse rarp do not behave for ncsa2305


Hello net, I'll be glad if someone will help me with this problem.

On a 386 We have:

        Ethernet card   EtherCard PLUS (Combo)
        Packet driver:  80003pkd.exe
        TCP/IP suit:    telnet version 2.3.05

When myip is set to explicit address the whole games works fine, but
when using myip=rarp we get the message "rarp failed!!!", although
verifying that three rarp-daemon really sent the correct IP number to
the PC (rarpd -a -d on suns/sparcs). Etherfind finds all the packets
(broadcast requests and rarp replies) too.

Anyone can tell me whats wrong ?

--
Israel Yedidya,         Phone:  972-3-5318682 or 972-3-5318407/8
System Administrator,   Fax:    972-3-5353325
Math & CS Department,   Email:  yedidya@bimacs.cs.biu.ac.il
Bar-Ilan University,    Bitnet: yedidya@bimacs
Ramat-Gan, ISRAEL.      Uucp:   ...!uunet!pucc.princeton.edu!bimacs!yedidya
If someone proves there is no God, I'll stop being religious!

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 18:55:27 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

>Almost any computer networks textbook will spend a page or two stating
>that TCP corresponds to OSI Transport, IP to OSI net, but IP is 
>connectionless while OSI is CO. That's about it - sometimes I wonder
>how they can spend several pages saying nothing more.

I wish they'd spend a few pages saying something *correct*, then - as
far as I know, OSI has both connection-oriented *and* connectionless
network-layer protocols (and it also has, as I remember, a
connectionless *transport* protocol, akin to UDP).

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 19:36:17 GMT
From:      sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP facilities in ADA???



	I am looking for packages that would allow me to use TCP/IP in
the ADA programming language... If you know of any please email a vendor
etc to me....
	Thanx for all responses in advance...


	
					Kevin V. Sobilo
				sobi0268@mary.cs.fredonia.edu

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 93 19:36:48 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet VT100/VT200 for TCP/IP on MVS (IBM large Systems)

Simware Inc.
20 Colonnade Road
Ottawa, Ontario, Canada, K2E 7M6
613-727-1779

They make a package for MVS which will do the vt100 to 3270 swap.  But, for my
two cents worth, you might want to look at getting a tn3270 emulation for the
client end.

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

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 93 22:16:54 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan27.115319.21112W@lumina.edb.tih.no>, ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
> Almost any computer networks textbook will spend a page or two stating
> that TCP corresponds to OSI Transport, IP to OSI net, but IP is 
> connectionless while OSI is CO. That's about it - sometimes I wonder
> how they can spend several pages saying nothing more.

Where did you get the idea that the OSI reference model cares whether the
network layer runs CONS or CLNP? There are ISO standards for both and in the US
GOSIP, CLNP is called for. Just because local authorities decide to run CONS
(as most Europeans probably do) is no reason to assume that it is in the
standard.

While there are LOTS of ISO standards that fit in the OSI model, the OSI model
is just that. It describes what each layer does as a general function, not
specific. IP does fit into the OSI model at the network layer. It only lack
blessings as an OSI standard. TCP fits into the transport layer the same way.
(As do the ISO/CCITT approved TP0, TP1, TP2, TP3, and TP4.)

Somewhere the idea has been popularized that OSI means interoperability in some
way. Not so. That requires systems to run matching OSI profiles, like US GOSIP
or UK GOSIP (or both). Otherwise you will get a system running TP0 and TP2
trying to talk to one running TP4 with no success.

To go a step further, there is nothing that prevents running the upper OSI
level over TCP/IP. See RFC1006, and ISODE. And, for that matter, TCP could run
on an ISO network protocol such as CLNP. In fact, the Internet Architecture
Board even recommended exactly that to alleviate the lack of IP address space.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@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.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jan 1993 23:51:00 GMT
From:      powell@wraith.netops.gtefsd.com (Mike Powell "GTE FSD Net Mgr")
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>We have 10 LaserJet printers which we would like to connect to a LPD
>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
> 
>We would rather not use LPD on various machines directly connected to
>the printers, since we would lose access to the printer when the machine
>went down (was re-booted or powered off).
> 
>The connections would be serial (RS-232), with one connection being
>parallel.
> 
>We have looked at the Lantronix equipment, but that does not really
>offer LPD; since we have a diverse user community, we want to use the
>LPR and LPRMON software that is provided with the TCP/IP implementations.
> 
>Does anyone have any suggestions?
Yes,
I am currently looking at three products:
Microplex M200/M201 default config 2 serial and 1 parallel
Axis AX-5 default config 1 serial 1 parallel
Lantronix EPS1 default config 1 serial and 1 parallel

Axis:
I currently have an evaluation unit from Axis. it does true LPD and
Novell print services. It does what it advertises.
508-777-7957 or info@axisinc.com

microplex:
They are next on the list for evaluation. It currently supports
LPD and Novell support has been announced.
604-875-1461, 800-665-7798 or sales@microplex.com

Lantronix:
"Support for Novell, TCP/IP, Ethertalk (Appletalk), LAT"
They are last on the list.
See other postings....
Phone: 714-367-0050 or 800-422-7022
--
Mike Powell PPASEL
"It's hard to find router bits for your cisco"
Disclaimer: I speak for myself. No direct relation to the DUAT folks.
internet: powell@wraith.netops.gtefsd.com  Usenet: uunet!wraith.netops.gtefsd.com!powell

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 00:22:29 GMT
From:      powell@wraith.netops.gtefsd.com (Mike Powell "GTE FSD Net Mgr")
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>We have 10 LaserJet printers which we would like to connect to a LPD
>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
> 
>We would rather not use LPD on various machines directly connected to
>the printers, since we would lose access to the printer when the machine
>went down (was re-booted or powered off).
> 
>The connections would be serial (RS-232), with one connection being
>parallel.
> 
>We have looked at the Lantronix equipment, but that does not really
>offer LPD; since we have a diverse user community, we want to use the
>LPR and LPRMON software that is provided with the TCP/IP implementations.
> 
>Does anyone have any suggestions?

Yes,
I am currently looking at three products:
Microplex M200/M201 default config 2 serial and 1 parallel
Axis AX-5 default config 1 serial 1 parallel
Lantronix EPS1 default config 1 serial and 1 parallel

Axis:
I currently have an evaluation unit from Axis. it does true LPD and
Novell print services. It does what it advertises.
508-777-7957 or info@axisinc.com

microplex:
They are next on the list for evaluation. It currently supports
LPD and Novell support has been announced.
604-875-1461, 800-665-7798 or sales@microplex.com

Lantronix:
"Support for Novell, TCP/IP, Ethertalk (Appletalk), LAT"
They are last on the list.
See other postings....
Phone: 714-367-0050 or 800-422-7022

Mike
--
Mike Powell PPASEL
"It's hard to find router bits for your cisco"
Disclaimer: I speak for myself. No direct relation to the DUAT folks.
internet: powell@wraith.netops.gtefsd.com  Usenet: uunet!wraith.netops.gtefsd.com!powell

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 93 02:08:58 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Compressed slip packet driver?

In article <1993Jan26.142944.5026@spcvxb.spc.edu> 4carroll_j@spcvxb.spc.edu writes:

       Can anyone tell me where I might find a compressed slip packet driver?

As far as I know, one doesn't exist and no one is working on one.  Of
course, writing such a program is exactly what my company does...

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 03:55:36 GMT
From:      rypma@waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: query about 2 subnets/1 segment and directed bcast

James Binkley (jrb@rigel.cs.pdx.edu) wrote:
: Back to 2 subnets on 1 segment again:
: 
: ...
: 
: We have an experimental server on zymurgy that is sending 
: out a directed broadcast on net 2 as 140.140.2.255. 
: Zymurgy has the capability to have 2 ip addresses
: attached to a single enet device.
: 		140.140.1.240
: 		140.140.2.240
: It is sending the directed bcast out to 2.255 as an
: ethernet bcast.
: 
: For "no apparent reason" an aix box and an hp X terminal too 
: (both on net 1 with 1 interface and 1 ip address on that
: interface)
: are picking up the directed broadcast and forwarding it
: ...
: Any insights here?  Mine is: "Life with 2 subnets
: in the presence of buggy tcp/ip implementations can be
: interesting :->"

BSD 4.3 networking code bites again... 

An IP implementation shouldn't forward a frame that comes in with a
broadcast (or multicast, for that matter) LLA. Unfortunately, 4.3
networking code throws away the information that the frame came in
on a broadcast link address, so ... If for any reason it is decided
by IP that the frame should be forwarded, then it will be if there's
a default or appropriate route.

I don't know about the AIX box, but the HP Xterminal does have two
network interfaces, even if you aren't using it ... the SLIP interface
on the serial port is 'attached', even though it isn't active. Having
2 interfaces and finding that a frame has been sent to it which has an
IP address that isn't any kind of broadcast address that it understands
(in fact, the address isn't even for its subnet), it forwards to the
default gateway, the Cisco box. You're lucky that the gateway was the
default or an ICMP redirect would also have been sent out.

The AIX box is probably doing something similar - it's something that
plagues this vintage of TCP/IP software.  Berkeley's Networking Release
2 fixed this by keeping a LLA broadcast/multicast flag in the mbuf header
that follows the frame around. Forwarding can thus be prevented for LLA
broadcasts (and 2 subnets on the same wire will be safer :-)

Incidentally, the most recent software release for the HP X terminal has
the network code modified so that forwarding to the same interface is never
done - the frame is just dropped. Check around on the AIX box and see if
there is any indication of 2 interfaces being attached (lo0, loopback
doesn't count). The forwarding code should never be called if there is
only one interface (in BSD 4.3/Tahoe code anyway).

Regards,

Ted Rypma
HP Panacom Division

(Any opinions, etc. expressed are entirely my own.)
even for its 


-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 03:59:03 GMT
From:      narayan@sut.ac.jp (Devendra Narayan)
To:        comp.protocols.tcp-ip
Subject:   Needed gated.conf OSPF sample !!

Would any kind soul please send me a sample gated.conf file
for OSPF protocol ? I am sorry if this is not the right place
for such a request.

===  = = ===       Devendra Narayan
=    = =  =        Education Division,
===  = =  =        Information Processing Center
  =  = =  =        Science University of Tokyo
===  ===  =        E-mail : narayan@sut.ac.jp or narayan@caren.net

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 93 07:30:18 GMT
From:      jwabik@uc.msc.edu (Jeff Wabik)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   SL/IP for Solaris 2.x?

Does anyone know if there is a version of SL/IP available for
Solaris2.x?   (I'm running 2.1)  Will the normal sysv4r version work?
(I'm new to sysv.  It still looks ugly to me.  :-)

Any info appreciated.. Thanks!

	-Jeff

--
Jeff Wabik                              E/Mail:  jwabik@msc.edu
Minnesota Supercomputer Center          AT&T:    +1 612 626 0211
Minneapolis, MN                         FAX:     +1 612 624 6550

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 07:31:37 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan27.115319.21112W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>Then you have the fighting young priests, making detailed comparisons
>for the sole purpose of showing how useless (wretched or whatever) one
>alternative is, compared to the other.

Actually, what they usually show is how dismal the OSI model is for
analysis.  Even the OSI protocols don't "fit" the OSI model in any
significant analytical sense, with most of the layers turned sideways
to allow functions to slip up or down at will.

The OSI model is useful mainly for its descriptive properties.
"Network layer" implies certain functionality which helps in
conversation, but in practice that functionality is rarely contained
in a neat layer between datalink and transport.  Ironically, it's the
OSI protocol suite itself which has the most drastic examples of
non-layering, although any competent network expert will tell you that
that, in itself, is not a deficiency.

>In article <SALKIELD.93Jan26224429@csqx.cs.rhbnc.ac.uk>, 
>salkield@csqx.cs.rhbnc.ac.uk (Tom Salkield) writes:
>>I am posting on behalf of a friend who needs to compare the layers of
>>the internet protocol suite with the OSI seven layer model as part of
>>his course assignment.

Your friend would probably find it easier to do his homework himself.
It doesn't take a significant amount of information about TCP/IP and
the OSI model to do this analysis.  I doubt that cribbing the answer
from some other source will acheive the educational goal that your
friend's instructor had in mind.  And it's certainly not the kind of
thing worth bothering thousands of people about.

						don provan
						donp@novell.com

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 10:16:55 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan27.141654.1@ptavv.llnl.gov>, oberman@ptavv.llnl.gov writes:

>> Almost any computer networks textbook will spend a page or two stating
>> that TCP corresponds to OSI Transport, IP to OSI net, but IP is 
>> connectionless while OSI is CO. That's about it - sometimes I wonder
>> how they can spend several pages saying nothing more.
>
>Where did you get the idea that the OSI reference model cares whether the
>network layer runs CONS or CLNP?

Evidence 1: The real world. The vast majority of networks following OSI
standards do run CONS. To put it squarely: They run X.25, which is CONS.
(ISDN will come in a few years, which is even more CONS.)

Evidence 2: While a CLNS was into earlier OSI documents, it has actually
been out for a few years! I haven't seen the '92 CCITT documents yet,
so it may have a decent treatment now. The preliminary copy I've got of
ISO 8473-1 (Connectionless-mode network service) states that the text is
also published as X.233, but there was no X.233 in the bluebooks (1988).

So, in the finer details, it is not strictly correct that "OSI is CO".
But as a first, general statement for people who want an introduction to
the difference between OSI and Internet protocols, it is a very good
starting point. Eg, is there *any* OSI *applications* that actually uses
connectionless mode? (Note that I was careful to state 'OSI is CO' in
a general sense, not associating it to the net layer in particular).
Actually, I have never seen the connectionless Transport service spec,
although I have heard of its existence. I don't know if there is any
CL Session service spec, or a CL Presentation service spec.

In essence, those fighting for CLTS want it for running their non-OSI
Internet applications.

Besides, I didn't intend, in my original statement, to make any blunt
statements about the OSI RM - I was referring to networking textbooks,
in general! (I could dig up a few examples to support it).

Besides 2: I consider IP an internet *Protocol*, not a net *Service*. If
we are to discuss the finer details of the OSI RM, IP is most certainly
not a CLNS, it is a CLNP. You may (but I am not seriously suggesting it!)
run CONS realized by a CLNP such as IP.

>While there are LOTS of ISO standards that fit in the OSI model, the OSI model
>is just that. It describes what each layer does as a general function, not
>specific. IP does fit into the OSI model at the network layer. It only lack
>blessings as an OSI standard. TCP fits into the transport layer the same way.
>(As do the ISO/CCITT approved TP0, TP1, TP2, TP3, and TP4.)

While I certainly agree with the main spirit of this statement, I think you
should pick up X.200 (or its ISO equivalent) and see which responsibilities
the OSI RM put on the NE and the TE. Too bad I've left my X.200 at home
today, or I would have quoted it. You will find that most (although not
all) of what TCP does is something primarily assigned to th NE.
A lot (although not all) of what IP does is something primarily assigned
to the Link Entity. On the general level, there is very little difference 
between running OSI TP on a middle-of-the-road OSI NS (such as X.213 NS
using X.223 mapping to X.25), or on TCP; you get essentially the same service.

The one that does not fit into the OSI RM is TP4; it simply assumes that the
NE does *not* do what it is supposed to according to X.200. I have a 
definite impression that TP4 was included with the sole purpose of "selling"
OSI to the IP camp. IMHO, TP4 should never have been included. It is OK
to run OSI over IP, but then a proper NS mapping (analogous to X.223, but
certainly very different) should  be defined rather than pushing
NE responsibilities over to the TE!

This "TCP = OSI TS, IP = OSI Net" is a very widespread misconception that
I have never seen backed up by a feature-by-feature analysis of the two.

>Somewhere the idea has been popularized that OSI means interoperability in some
>way. Not so. That requires systems to run matching OSI profiles, like US GOSIP
>or UK GOSIP (or both). Otherwise you will get a system running TP0 and TP2
>trying to talk to one running TP4 with no success.

As long as we keep the non-OSI-spirit TP4 out of it, it is much simpler.
Fallback to TP0 is defined as part of the connect procedure. For 
interconnection of different net level protocols, an architecture is
defined ("Internal organization of the Network layer") that is supposed
to allow eg. a CLNP hop in a net providing a CONS, but hide it from the
end service interface. As soon as people start implementing these standards
rather than fighting them, things will become much easier... :-)

>To go a step further, there is nothing that prevents running the upper OSI
>level over TCP/IP. See RFC1006, and ISODE. 

RFC1006 is a starting point. But it does not provide the full service, TP0
only. Which means eg. that there is no true support for expedited data.
(According to the letter of the standard: Good enough, according to the 
spirit: Eeeeh, well...). I will consider 1006 a workable interim solution,
but not a permanent one. A better permanent solution would be to run TCP
as a net service provider, although the egos of the people in the Internet 
camp would be seriously injuried if TCP was degraded to Net level...

>And, for that matter, TCP could run on an ISO network protocol such as CLNP. 

In principle this is (of course) true. But most programming interfaces to 
TCP makes a whole lot of IP itself visible. If all programmers knew that 
they should NOT make their software rely on IP being present, fine. But
generally speaking, programmers tend to make maximum use of whatever 
functionality provided. You certainly can "prove", in practice, that
TCP-based software CAN run across a non-IP net, but to paraphase
Dijkstra (?): "A demo can prove the presence of problems, not the absence".
Up until now, the syntax for invoking IP functionality has differed. But
adapting to various syntax is much easier than adapting to absence!

Ketil Albertsen.


-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 10:22:04 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Generic IP address

In article <1993Jan26.185514.19852@walter.bellcore.com>, pietro@nova.bellcore.com 
(Pietro Manzoni) writes:

>Is there anybody who knows if it's possible to send a message specifing a
>generic address.
>
>I'm not talking of multicast, I'm just wondering if it could be possible
>to send a datagram without specifing a destination address.
>
>This type of datagram should be interpreted as: the first host that receives
>the datagram is the destination host...

How would any host know that it was the first one? The problem is most
obvious on a broadcasting net, such as Ether - *all* hosts would believe
that they were the first one.

But even on a point-to-point net: On which link connection should the message
be sent? A single random one? Or on all available (which is functionally
identical to broadcasting)?

Sorry, I do not understand the semantics of you suggested "first host gets it"
address.

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 10:35:47 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B5D10A21.MACE@HDQCMS2H.UTSD.ATT.COM>,
 MACE@HDQCMS2H.UTSD.ATT.COM wrote:
>I was looking for a standalone device, rather than a process running
>on a set of PCs to drive the printers...

Microplex makes such a box.  They can be reached at <info@microplex.com>.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 11:44:06 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
> Evidence 1: The real world. The vast majority of networks following OSI
> standards do run CONS. To put it squarely: They run X.25, which is CONS.

Actually a lot of them run X.25 (1980), which, as far as I know, is *not*
a full CONS. This was the case here in Norway at least a couple of years ago -
The Norwegian Telecom ran a mix of X.25 (1980) and X.25 (1984). I don't know
what the situation is today. Also, according to Olav Kvittem, not even X.25
(1984) is a full CONS, because it doesn't handle a normal 20-octet NSAP.

> starting point. Eg, is there *any* OSI *applications* that actually uses
> connectionless mode? (Note that I was careful to state 'OSI is CO' in

Yes, DECnet Phase V...

> In essence, those fighting for CLTS want it for running their non-OSI
> Internet applications.

That's your interpretation. I don't expect everybody to agree.

> NE does *not* do what it is supposed to according to X.200. I have a 
> definite impression that TP4 was included with the sole purpose of "selling"
> OSI to the IP camp. IMHO, TP4 should never have been included. It is OK

So what do we use if we want reliability? TP0 over X.25 is simply not good
enough. TP0 and TP4 are by far the most commonly implemented...

> As long as we keep the non-OSI-spirit TP4 out of it, it is much simpler.

If I'm not allowed to use TP4, I'll stick to my Internet protocols, thank you.

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

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 11:53:30 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan28.073137.7195@novell.com>, donp@novell.com (don provan) writes:

>Actually, what they usually show is how dismal the OSI model is for
>analysis.  Even the OSI protocols don't "fit" the OSI model in any
>significant analytical sense, with most of the layers turned sideways
>to allow functions to slip up or down at will.

Sorry, I don't understand what you mean by "layers turned sideways".
Could you explain? (Preferably with examples)

>Ironically, it's the OSI protocol suite itself which has the most drastic 
>examples of non-layering, although any competent network expert will tell 
>you that that, in itself, is not a deficiency.

Sure. The protocols came first, before a good taxonomy had been developed.
So the OSI guys had to face a decision: Should the taxonomy, the RM,
describe the world in the current messy state, or should we make an
attempt to be systematic, create a goal to work towards? They chose the
latter, and I think that was a good idea.

(A sidetrack: If your statement was intended to say that TCP/IP is well
layered, I think most datacomm people would protest! One thing is that
organizing 2/7 of the problem areas is much easier than organizing the
entire problem solution, another is that several textbooks make an
issue out of TCP/IP not being layered, but "hierarchical", in the sense
that the functionality of both levels is available to the programmer)

I think you could day that the more recent OSI protocols are generally 
closer to the model, but there are certainly some problems even in the
newer ones.

I do believe that in ten years, we will smile at the current low layers
in OSI (and that is NOT because IP will take over... :->). The coming of
ATM (and ISDN) will turn around a lot of the ways we think of network
problems. Of course we will still use both IP and X.25, but the trends
will be in quite a different direction.


>>>I am posting on behalf of a friend who needs to compare the layers of
>>>the internet protocol suite with the OSI seven layer model as part of
>>>his course assignment.
>
>Your friend would probably find it easier to do his homework himself.
>It doesn't take a significant amount of information about TCP/IP and
>the OSI model to do this analysis.  I doubt that cribbing the answer
>from some other source will acheive the educational goal that your
>friend's instructor had in mind.  And it's certainly not the kind of
>thing worth bothering thousands of people about.

I do not feel "bothered" by a discussion of Internet vs. OSI protocols,
even if what started the discussion was a question from a student.

As a college lecturer, I consistently urge the students to find information
in other sources, to search for non-textbook arguments and solutions.
"The real world" certainly looks different from the textbook image, and
I would say it is a good idea for a student to ask professionals in the
field how they feel about the Internet/OSI alternatives.

Ketil Albertsen, college lecturer

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 93 12:33:49 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article <19971@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  I put two questions to the readers of this group:
>
>1) Do you concur with Mr. Gaskin that coax is dead or dying?
>
>2) What options are available for small (less than a dozen nodes) networks
>currently running coax and wanting to move to 10BaseT?  For example, I
>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>available which are cost effective for small networks?
>
>I look forward to your replies...
>
>Frank.
>--
>___________________________________________________________________
>Frank I. Reiter                 Internet: Frank@mindlink.bc.ca
>MIND LINK! Communications Corp. Surrey, British Columbia, Canada


For 1,2,3 or so systems, coax may be just fine but beyond that, you get into
the complexities of having to run basically 2 cables to each PC. (One in from
PC A to PC B and one out From PC b to PC C.)  In many cases this is awkward to
do.  With a 10baseT system, you run a single cable back to a central hub
(typically in the phone closet since you can run the cables at the same time
the phone lines are run).  This usually makes the topology easier to manage and
if a cable breaks, you only lose 1 system instead of splitting your network 
into 2 segments.  The tradeoff of course is cost.  An 8-12 user hub will cost
$500-$1000 depending upon features required and expandibility options.  I'm
using thinnet here at home to link 3 systems (really thin 1/8 in. RG-174) and
it works just fine but in an office environment with arbitrary room layout, I'd
use 10baseT.  The other advantage of 10baseT is moves and changes.  If each
office is wired for voice and data, it is a very simple job to move four or so
wires in the phone closet to move a user down the hall.

In summary, if you have thinnet installed, it sould work just fine but if you
are planning any new networks/office layouts, I'd definitely go with 10baseT
and get it wired at the time the phones are wired.

Cliff
cliffb@cjbsys.bdb.com



-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 17:04:58 GMT
From:      russell@hawk.nstn.ns.ca (Paul Russell)
To:        comp.protocols.tcp-ip
Subject:   'Magic Muffin' Information

A friend asked me about what a 'Magic Muffin' or 'Magic Cookie' was in the 
TCP/IP protocol.  Does anyone have any information on this?

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 17:37:28 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

 ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>>, donp@novell.com (don provan) writes:
 
>>>>I am posting on behalf of a friend who needs to compare the layers of
>>>>the internet protocol suite with the OSI seven layer model as part of
>>>>his course assignment.
>>
>>Your friend would probably find it easier to do his homework himself.
>>It doesn't take a significant amount of information about TCP/IP and
>>the OSI model to do this analysis.  I doubt that cribbing the answer
>>from some other source will acheive the educational goal that your
>>friend's instructor had in mind.  And it's certainly not the kind of
>>thing worth bothering thousands of people about.
>
>As a college lecturer, I consistently urge the students to find information
>in other sources, to search for non-textbook arguments and solutions.
>"The real world" certainly looks different from the textbook image, and
>I would say it is a good idea for a student to ask professionals in the
>field how they feel about the Internet/OSI alternatives.

Newsgroups like this are a rare opportunity for interested people to
hear and learn from the masters.  But that will only continue as long
as there is low enough volume to not take up too much time and the
S/N of topics interesting to the net.gods remain favourable.

If your students wanted to learn about politics you would bring them
to your capital and watch from spectator gallery, perhaps even ask
a question to one of the polititions after the debates.  But it is a 
little absurd to suggest that every one of them should interrupt the 
order of the house with questions like "what really is the difference 
between this and communism, I need to know for a paper I am writing?"

And remember, my analogy was about politians, the people who read 
this group actually have useful work to do!

Why not suggest students watch the dynamics of the group, perhaps scan
through old archives of the group for answers, and keep a few good
books on reserve in the library so everyone gets a chance to read them.

Erick

-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 93 17:54:58 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip,comp.sys.sequent
Subject:   Re: Nameserver help?

In article <1993Jan18.130031.11572@atlastele.com> brians@atlastele.com (Brian Sheets) writes:
>I have set up a nameserver on my machine and some weird things are happening and
>I was wondering if someone could help me out.
>
>I am running Dynix 3.0.17.10  on an S3 using a dialup slip connection to PSI
>The probles I see are, 1) when I lose my connection I can't seem to talk on 
>my local ethernet, When I telnet in to the the system  it is very slow with 
>a login  prompt. One really weird thing is that "talk" say "target machine
>does not recognize you". This happens whenever I am using named.

The reverse zone lookup is failing. Have you set up a reverse zone at
all ? Is it properly delegated ?

If your forward zone contains resource records like

	host.my.zone.                 IN A   127.126.125.124

then you must have a reverse zone that can resolve

	124.125.126.127.in-addr.arpa. IN PTR host.my.zone.

RTFRFCs !!!
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 93 18:03:45 GMT
From:      mac@devildog.att.com (Mike Carr)
To:        comp.sources.wanted,comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Where can I find NYSERnet source?

Can anyone tell me where I can get the source for NYSERnet?
I was told that it is public domain. I need it for a few SUN workstations.

Thanks,

Michael Carr (mac@devildog.att.com)

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 93 18:54:30 GMT
From:      rich9256@mary.cs.fredonia.edu (Devin    Richards)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP to Ada interface????


I am looking for packages or any type of software that would allow me to
interface TCP/IP with Ada.  Any help would be appreciated.
Please send me vendors/names/anything else!

Thanks in advance.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-
Devin Richards					SUNY College at Fredonia

          INTERNET: rich9256@mary.cs.fredonia.edu
          UUCP:  {ucbvax,rutgers}!sunybcs!mary!rich9256

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   It rolls down stairs alone or in pairs it runs over your neighbor's dog.
   It fits on your back it's great for a snack it's Log Log Log. 
   It's Log Log it's big it's heavy it's wood.
   It's Log Log it's better then bad it good!
   New Log from Blammo.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 20:15:34 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan28.115337.8776W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>Sorry, I don't understand what you mean by "layers turned sideways".
>Could you explain? (Preferably with examples)

Actually, you've been clearly illuminating the most obvious example:
x.25 support.  X.25 was wedged into the OSI model by inventing a null
transport layer and a null network layer so that the datalink layer,
x.25, can manifest itself directly at the transport service layer.
One way to envision this is as turning the datalink, network, and
transport layers on their sides so that datalink can reach up to the
bottom of the session layer.

Another example involves the upper three layers.  In practice, these
don't really work as "layers", but more as individual units in a
cooperative whole.  In any practical implementation, the actual
application (as opposed to the application layer) has to interact with
presentation and session directly, not through any higher layer
service exchange.  This is reflected in the service definitions, which
include many "pass through" type functions in the presentation and
application layers, although not really enough to do a reasonably
efficient implementation.  Again, the way i've started to envision
this is by tilting the three layers on their sides such that the
application can interact with any of them directly.

And, of course, with the introduction of ACSE, the application layer
itself has become more of a utility library than a layer.  This is a
different kind of tilt: while the model envisions various application
protocols in the application layer, each running vertically from
presentation up to the top of the stack, ACSE is now the one thing
that goes from top to bottom, dealing with each of the application
protocol components as appropriate for the actual application.  In
effect, the protocol components hang out horizontally from the ACSE,
each connected only to the ACSE rather than spanning the space between
the application and the presenation layer as dictated by the model.

I hope this clears up what i meant.  Bear in mind that these aren't
criticisms.  So far as i can see, these are the *correct* solutions to
the problems encountered, not deficiencies in the protocol designs.

>Sure. The protocols came first, before a good taxonomy had been developed.
>So the OSI guys had to face a decision: Should the taxonomy, the RM,
>describe the world in the current messy state, or should we make an
>attempt to be systematic, create a goal to work towards? They chose the
>latter, and I think that was a good idea.

I do, too.  My point, though, is that it is a *taxonomy* (an excellent
term for it: thank you for mentioning it).  As a taxonomy, the model
is good only for *describing* protocols, not for analysing or
evaluating them.  And, as i say, this is revealed over and over
whenever someone tries to "compare" the two protocol suites using the
OSI model as the measure of quality by which they are rated.

>(A sidetrack: If your statement was intended to say that TCP/IP is well
>layered, I think most datacomm people would protest!

Well, i intended to say no such thing, but in my experience -- and
forgive me for saying this -- most datacomm people wouldn't know
layering if it jumped up and bit them on the nose.

>I think you could day that the more recent OSI protocols are generally 
>closer to the model, but there are certainly some problems even in the
>newer ones.

As i say, i think it would be a mistake to measure the quality of a
protocol suite based on how close it comes to matching a taxonomy.
That would be something like judging the quality of a cow by measuring
its "cowness" rather than by measuring how much milk it produces.

>I do believe that in ten years, we will smile at the current low layers
>in OSI (and that is NOT because IP will take over... :->).

I'm not sure where you're looking, but from what i can see, in ten
years we won't even remember OSI.  With all the excitement about the
growing OSI market, everyone seems to overlook the fact that the
TCP/IP market is growing an order of magnitude faster.  IP doesn't
have to "take over", since it's the installed based in virtually every
market that isn't dominated by proprietary networking.  From
everything i've heard, the only people still interested in OSI are the
ones that have to deal with painful, government induced network
monopolies such as the European phone companies.  (I've lost count of
the number of times i've heard about people that wanted OSI only to
connect geographically separated *TCP/IP* LANs.)

>I do not feel "bothered" by a discussion of Internet vs. OSI protocols,
>even if what started the discussion was a question from a student.

I'm not bothered by the discussion, either, although this discussion
actually has very little bearing on the original question.

						don provan
						donp@novell.com

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 21:47:27 GMT
From:      powell@wraith.netops.gtefsd.com (Mike Powell "GTE FSD Net Mgr")
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>We have 10 LaserJet printers which we would like to connect to a LPD
>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
> 
>We would rather not use LPD on various machines directly connected to
>the printers, since we would lose access to the printer when the machine
>went down (was re-booted or powered off).
> 
>The connections would be serial (RS-232), with one connection being
>parallel.
> 
>We have looked at the Lantronix equipment, but that does not really
>offer LPD; since we have a diverse user community, we want to use the
>LPR and LPRMON software that is provided with the TCP/IP implementations.
> 
>Does anyone have any suggestions?
Yes,
I am currently looking at three products:
Microplex M200/M201 default config 2 serial and 1 parallel
Axis AX-5 default config 1 serial 1 parallel
Lantronix EPS1 default config 1 serial and 1 parallel

Axis:
I currently have an evaluation unit from Axis. it does true LPD and
Novell print services. It does what it advertises.
508-777-7957 or info@axisinc.com

microplex:
They are next on the list for evaluation. It currently supports
LPD and Novell support has been announced.
604-875-1461, 800-665-7798 or sales@microplex.com

Lantronix:
"Support for Novell, TCP/IP, Ethertalk (Appletalk), LAT"
They are last on the list.
See other postings....
Phone: 714-367-0050 or 800-422-7022

Mike
--
Mike Powell PPASEL
"It's hard to find router bits for your cisco"
Disclaimer: I speak for myself. No direct relation to the DUAT folks.
internet: powell@wraith.netops.gtefsd.com  Usenet: uunet!wraith.netops.gtefsd.com!powell

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 23:15:34 GMT
From:      mdivya@world.std.com (Marigowda Divya)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Testing

vish@ngc.com (Vish Mulchand) writes:

>I am curious to know how TCP/IP is being tested. I would be interested in
>almost anything related to testing of TCP/IP and this would include 
>automated TCP testers, conformance tests, test cases/suites, philosophies
>experiences and other information that might prove to be useful.
 
>Regards
>Vish Mulchand
>vish@thor.ngc.com
>(415) 688-2849 
 
>-- 
>Vish Mulchand
>Network General Corporation
>vish@thor.ngc.com
>(415)688-2849

Message to Vish:  I tried to send mail to you directly, but it was
bounced back to me;  hope you will check for responses here also.


we are working on this at our company;  I will send you some 
preliminary information as soon as its available (couple of weeks).

Cheers,
Marigowda Divya
GSOFT (PC based LAN/WAN Protocol Testers)
mdivya@world.std.com

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jan 1993 23:45:09 GMT
From:      aiko@opium.cs.odu.edu (John K Hayes)
To:        comp.windows.x,comp.dcom.modems,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Need advice on x-windows connectivity via x.25


Hello, net experts.  A friend of mine needs help linking two Sun SPARC
stations via x.25 (remote WAN sortof, but no internet involvement) so he
can run x-windows through the connection.  I don't know a whole lot about
this stuff, so feel free to consider me a x-windows/x.25 idget and don't
work about insulting our combined intelligences....

Basically, he needs to know what to use at both ends to connect the
machines via a 9600 baud modem using x.25 protocol.  He says he can't
use tcp/ip over the modem, but I'm not sure why.  Any tips appreciated!

Thanks for your support.

John Hayes
aiko@cs.odu.edu
-- 
    ---{john hayes}  OLDOMINISITY; Norfolk, Virginia USA
                     internet: aiko@cs.odu.edu

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1993 00:14:26 GMT
From:      dank@cco.caltech.edu (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

donp@novell.com (don provan) writes:
>And, of course, with the introduction of ACSE, the application layer
>itself has become more of a utility library than a layer.

Where can we read more about ACSE?  Is this an OSI thing?

>IP doesn't have to "take over", since it's the installed based in virtually 
>every market that isn't dominated by proprietary networking.  
>						donp@novell.com
 						     ^^^^^^

For somebody who works at the company responsible for nearly all the
growth in proprietary networking in the last five years, you seem
to have a considerable affinity for TCP/IP.  Is this shared by your
company as a whole - i.e. can you explain why your company plans to
offer IPX rather than TCP/IP as the default networking environment
in their UNIX product?
- Dan Kegel (dank@blacks.jpl.nasa.gov)

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 93 00:18:56 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP congestion/Nagle's algorithm

In article <1k1du3INNdoe@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:

    RFC 1122 has a nice description of how all of the different "when to send"
    algorithms, including Nagle's, fit together.
    
An issue is that while the Discussion section under 4.2.3.4 describes
a minor (and tested as effective) modification to Nagle's original
algorithm, the Implementation section describes something much more
like 4bsd's approach.  4bsd waits trying to fill the guessed-at
window even if there is no unacknowleged data outstanding.  This is
at the root of a lot of throughput problems with odd segment sizes
and smallish windows, and is the reason people keep saying that some
sort of NODELAY option is a MUST (it isn't really necessary if you
implement Nagle w/o timeout, per Discussion).

My personal opinion is that an administratively-configured "allow
Nagle override" variable should be a MUST, to avoid greedy applications
pursuing nothing more profound than smooth mouse motion swamping routers.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1993 01:03:38 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan28.201534.16358@novell.com> donp@novell.com (don provan)
writes: 

    >I do believe that in ten years, we will smile at the current low layers
    >in OSI (and that is NOT because IP will take over... :->).
    
    I'm not sure where you're looking, but from what i can see, in ten
    years we won't even remember OSI.  With all the excitement about the
    growing OSI market, everyone seems to overlook the fact that the
    TCP/IP market is growing an order of magnitude faster.  IP doesn't
    have to "take over", since it's the installed based in virtually every
    market that isn't dominated by proprietary networking.  From
    everything i've heard, the only people still interested in OSI are the
    ones that have to deal with painful, government induced network
    monopolies such as the European phone companies.  (I've lost count of
    the number of times i've heard about people that wanted OSI only to
    connect geographically separated *TCP/IP* LANs.)
    
In ten years, there is a significant possibility that TCP will be running
over CLNP.  The problem with IP's growth rate is that it is TOO
successful.  The growth of the IP address space is a serious problem.  The
TUBA proposal (one of several before the IETF) would migrate the Internet
to running with CLNP as the network layer protocol.

    						donp@novell.com

Of course, others have suggested using IPX as the new network layer
protocol.  0.5 ;-)

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 02:29:49 GMT
From:      reh@wam.umd.edu (Richard Huddleston)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Subnet Fields > 8 bits: SUMMARY


Summary of results/responses from my posting re: what the hell gives
with subnet masks greater than 8 bits ( on a Class A or B net ID ) ?
 
The answer, briefly, is: nothing gives.  Provided there are at least
two bits for the host IDs, you can do anything ya want.  There were
numerous caveats about which particular subnet schemes would be supported
by routing hardware; for example, non-contiguous bitmasks aren't always
supported, and neither are mixed-field-length subnets.
 
Relevant RFCs were
 
 917
 919
 922
 940
 950
 
I'd like to thank everybody who took the time to respond to my posting, and
for the high quality, as well, of the responses.  Low BS to content ratio.
 
 

-- 
Richard Huddleston
University of Maryland at College Park

Personal opinions

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1993 03:00:37 GMT
From:      kenh@leps5.phys.psu.edu (Ken Hornstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Please tell a newbie the differences betw FSP and FTP and ...

In article <1993Jan27.060203.12435@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>In article <1k15dsINNl17@fstgds15.tu-graz.ac.at> you write:
>>1.) What is FSP exactly? I know and have seen FTP already and been told
>>    that FSP is kinda similar.
>
>In 12 years on the Internet, I have never heard about a protocol called
>FSP.

FSP, as I understand it, is just another way of accessing files anonymously.
I think it uses UDP.  I'm not really sure what's so great about it.  I have
seen FSP clients and servers posted to alt.sources.

--Ken

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 07:45:11 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan27.141654.1@ptavv.llnl.gov>, oberman@ptavv.llnl.gov 
writes:

>Where did you get the idea that the OSI reference model cares whether the
>network layer runs CONS or CLNP? 

I just came across the statement quoted below in the X.212 recommendation,
Appendix II (note that appendix II is not formally a part of the
recommendation). This is from the bluebooks, the '88 edition:

"The assumption that a connection is a fundamental prerequisite for
communication in an OSI environment permeates the Reference Model and
is one of the most useful and important unifying concepts of the OSI
architecture."

Could anyone with access to the whitebooks check if the sentence is
still there, or in which way it has been modified?

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 08:34:34 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1k9vpaINNrdl@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>In article <1993Jan28.201534.16358@novell.com> donp@novell.com (don provan)
>writes: 
>    >I do believe that in ten years, we will smile at the current low layers
>    >in OSI (and that is NOT because IP will take over... :->).
>    
>    I'm not sure where you're looking, but from what i can see, in ten
>    years we won't even remember OSI.
>    
>In ten years, there is a significant possibility that TCP will be running
>over CLNP.

And if that comes to pass, then CLNP will be remembered as the network
layer protocol of the Internet protocol suite, not as the network
layer of the OSI protocol suite.  So i stand by my prediction.

						don provan
						donp@novell.com

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 93 13:08:56 GMT
From:      Sam.Wilson@ed.ac.uk
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: MacTCP and window size

veizades@apple.com (John Veizades) writes:
> In article <30794@castle.ed.ac.uk>, ercm20@festival.ed.ac.uk (Sam Wilson)
> wrote:
> > 
> > Since this seems to be independent of the specific application I assume
> > it's a MacTCP problem, possibly a shortage of memory.  ...
> > 
> MacTCP has little to do with the size of window that is advertised to the
> remote host.  The application that is using MacTCP gves MacTCP the memory
> needed to maintain the connection.  

Thanks, that's interesting info, but it doesn't seem to explain what is
seen (except by coincidence).  Incidentally I've had two other responses
suggesting that a) the host system might be at fault since the TCP
connection open seems to be legal; and b) MacTCP 1.1.1 handles memory
better than earlier versions.  We're using 1.1b5 just at the moment,
while we wait for Apple UK to agree to a site licensing arrangement - no
you don't want to know, we've been waiting years...  but that's another
story.  

Anyway the coincidence is that both NCSA Telnet and Eudora fail when the
machine is in 'fail mode' and in both cases the symptoms (at the network
level) are the same - same size of small window advertised and host
resets connection.  When it works these same applications, without
having had their application memory size tweaked, offer the same larger
window size and the connection works. 

> John Veizades...
> MacTCP Lead Engineer
> Apple Computer, Inc.

Aha!  Someone who knows about MacTCP!  (And that's yet another story...)
Perhaps you can explain why MacTCP's DNS resolver is so primitive, i.e.
it only looks in either the default domain or the root domain and
doesn't work its way up the name tree, when the setup looks as if it
should be much more sophisticated (though even if it was it would still
be confusing!).  Reply by mai lif you like.

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 93 13:29:27 GMT
From:      west@mgmt3.ncsl.nist.gov (Jim West)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan27.115319.21112W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>
>Almost any computer networks textbook will spend a page or two stating
>that TCP corresponds to OSI Transport, IP to OSI net, but IP is 
>connectionless while OSI is CO. That's about it - sometimes I wonder
>how they can spend several pages saying nothing more.

What ever happened to IS 8473 -- The Connection-Less Network Protocol (CLNP)?
Saying that ISO Network layer is Connection Oriented is incorrect or at
least incomplete.  The ISO Standards specify a Connectionless service
and a Connection Oriented service.  Sure, they don't interoperate, but what
does ISO care about interoperability? :-).

Jim West
-- 
----------------------------------------------------------------------
In this message I speak only for myself, not necessarily for my employer.
National Institute of Standards and Technology
west@mgmt3.ncsl.nist.gov

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 13:41:55 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <STEINAR.HAUG.93Jan28124406@delab.sintef.no>, Steinar.Haug@delab.sintef.no (Steinar Haug) writes:

>> starting point. Eg, is there *any* OSI *applications* that actually uses
>> connectionless mode? (Note that I was careful to state 'OSI is CO' in
>
>Yes, DECnet Phase V...

Sorry, I didn't think of DECnet as an *OSI application*. I thought OSI
applications were such things as distributed directories, DDBMSs, email,
conferencing systems, file transfer etc. etc. Solutions to end user
problems and needs. I consider DECnet (a family of) *tools* to solve
end user problems.

I don't know what goes into DECnet Phase V, but if that is a package
incorporating X.400 mail, X.500 directory, FTAM, JTAM... all using
a connectionless presentation service, they you have serious problems
interworking with others - all those services are defined by a COPS.
In that case, DEC has created an island of their own.

>So what do we use if we want reliability? TP0 over X.25 is simply not good
>enough. TP0 and TP4 are by far the most commonly implemented...

As I said the other day: As soon as people start *implementing* those
OSI protocols, they will work much better... The solution to X.25 not
being reliable enough is, IMHO, *not* to throw out the OSI model but
to use OSI style handling: TP1 or TP3.

If you are claiming that the residual error rate (that is, undetected
and unreported errors) is too high for your requirements, I think you
should support that with numeric figures for the actual error rate
in the X.25 net you are using. Have you and your service provider
ever agreed on test procedures to measure this? I would be *extremely*
surprised if the residual error rate was a problem. After all,
a significant fraction of bank transactions all over Europe go across 
X.25. If it is good enough for the banks, you must have some very
special needs if it is not good enough for you!

>> As long as we keep the non-OSI-spirit TP4 out of it, it is much simpler.
>
>If I'm not allowed to use TP4, I'll stick to my Internet protocols, thank you.

*I* refuse to use cables that contain more than 3% zinc..  :->

Seriously: Who is "I", who demand the right to use TP4? Certainly not the
implementor of the net entity; the net layer could care less what is
in the packets (TPx or TPy). Certainly not the implementor of the session
entity; transport services are independent of transport protocol class.
Certainly not the implementor of presentation entity, not the implementor
of OSI applications - they are even further remote from the transport
protocol.

So you must be a transport entity implementor. Well, we don't need that 
many of those around the world. You just implement for us, so that we
can use the transport services; I don't care as long as you provide a
transport connection to my OSI partners all over Europe, running X.25.

Too bad: They run TP0, TP1 or TP3. Most of them across X.25; later
across ISDN or ATM or other solutions - that is Net's problem.

Oh, so you were not thinking of the commercial/industrial European
market? Thinking of USA? Fine, then: How widespread is OSI session,
OSI Presentation, OSI applications in the US market? Not very much.

I know one solution: Run FTP, Telnet, NNTP, SMTP... across an OSI
transport connection, you don't need any Session/Presentation for 
those! Isn't that nice: By using a non-Internet transport protocol
you rule out contact with the TCP-users. By using non-OSI application,
presentation and session protocols, you rule out contact with OSI users.

Sure you have created a large market for gateway machines that way.
Earlier, the market was small: You only had the Internet-application-
to-OSI-application gatewaying. Now you get all possible permutations
of OSI/non-OSI at all layers, in the worst case. What a business
opportunity!


Ooops; looks like I should have put some '#define sarcasm' somewhere
above. And a lot of smileys of some sort. Too late now - I suppose
the flamethrowers are out already.


Well, some think it good, some think it bad: My personal opinion
about TP4 cannot prohibit Steinar from using it. I am even considering
implementing a TP4 myself, just because I want my personal OSI stack
to run across one of the few nets I've got free access to. I am not
that much a fanatic. But I reserve the right to think that TP4
is definitely non-OSI.

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 13:50:54 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1k9st2INNnnq@gap.caltech.edu>, dank@cco.caltech.edu (Daniel R. Kegel) writes:

>Where can we read more about ACSE?  Is this an OSI thing?

X.217 for the service definition, X.227 for the protocol.
(I hope they didn't change the numbers for the '92 whitebook editions!)

Yes, it is an OSI thing. It is the first service element to be activated
on an incoming call, it takes care of ensuring that the application
process you want to talk to is there, that it gets your message and that
the correct environment is set up. Sure, the caller also uses ACSE services
on the calling side to send those messages.

Well, most of this is realized in an implementation dependent way; the
ACSE protocol defines just how to pass the data from one peer to 
another and the semantics of these data. The processing done by ACSE 
to ensure that the process is there and the correct environment is up
is defined locally; it may vary widely from system to system.


-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 14:15:12 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Please tell a newbie the differences betw FSP and FTP and ...

kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
}lars@spectrum.CMC.COM (Lars Poulsen) writes:
}>In article <1k15dsINNl17@fstgds15.tu-graz.ac.at> you write:
}>>1.) What is FSP exactly? I know and have seen FTP already and been told
}>>    that FSP is kinda similar.
}>In 12 years on the Internet, I have never heard about a protocol called
}>FSP.
}FSP, as I understand it, is just another way of accessing files anonymously.
}I think it uses UDP.  I'm not really sure what's so great about it.  I have
}seen FSP clients and servers posted to alt.sources.

Although it could be used in a responsible manner, it has been our experience
that FSP is mostly used for software pirating.

FSP uses UDP and can be setup on any port# making it (next to) impossible
to filter.

It has turned into a major time sink here dealing with these little twerps.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 14:28:44 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan28.201534.16358@novell.com>, donp@novell.com (don provan) writes:

> X.25 was wedged into the OSI model by inventing a null
>transport layer and a null network layer so that the datalink layer,
>x.25, can manifest itself directly at the transport service layer.

'Scuse me??? X.25 is a *protocol* spec, not a service spec. There
certainly is a recommendation for how to map the X.213 services
onto the X.25 protocol; it is called X.223 (at least in the '88s)

Like all service standards, X.213 does not define an actual interface
syntax, only a conceptual service interface. So you may dig up some
implementation where you'll never find an 'NC-CONNECT-response'
function definition. But that may be the case in *any* layer, using
*any* protocol. Implementors do take shortcuts - usually for
reasons of efficiency, but also in an attempt to control markets.

"Null transport layer"? Huh? Say, which edition of X.214 are you reading?

"The datalink layer, x.25". Sure, X.25-2 is the data link layer;
it is LAP-B, an adaptation of HDLC. But is LAP-B visible in the
transport services? Not in *my* copy of X.214!

X.25-3 is a net protocol, for use by some net entity. The net
entity cannot do anything that is impossible through the selected
protocol. So what responsibilities does X.200 put on the net layer?

 - routing and relaying
 - network connections
 - network-connection multiplexing
 - segmenting and blocking
 - error detection
 - error recovery
 - sequencing
 - flow control
 - expedited data transfer
 - reset
 - service selection
 - network layer managment.

(X.200, 7.5.4 in the bluebooks). The last one, network layer management,
I know too little about. But the X.25-3 protocol certainly support all
the listed functions. (Ask IP about the same!)

>One way to envision this is as turning the datalink, network, and
>transport layers on their sides so that datalink can reach up to the
>bottom of the session layer.

I just don't think this statement is meant seriously.

>Another example involves the upper three layers.  In practice, these
>don't really work as "layers", but more as individual units in a
>cooperative whole.  In any practical implementation, the actual
>application (as opposed to the application layer) has to interact with
>presentation and session directly, not through any higher layer
>service exchange. 

For Presentation and Session, I can agree with you; I do teach them
to my students as two more or less parallell sets of functions. The
main reason for not making them 100% peers is essentially the user
data parameter of the session calls.

But the third one (application, I presume): It sure builds (further)
abstractions from those provided by P/S-services - namely problem 
oriented abstractions. It definitely is "above", or whatever you
will call it. P and S has no life of their own, except as realizers
of application concepts. What do you mean by "application (as 
opposed to the application layer)"? The applicatiation layer *is*
that part of the application interacting with the P services,
nothing else!

>And, of course, with the introduction of ACSE, the application layer
>itself has become more of a utility library than a layer. 

Not only ACSE: All ASEs are exactly as you say. They are standard
modules (call them utility libraries, if you like) for producing
and interpreting problem oriented (application) protocols. That is
exactly how it was meant!

>ACSE is now the one thing
>that goes from top to bottom, dealing with each of the application
>protocol components as appropriate for the actual application.  In
>effect, the protocol components hang out horizontally from the ACSE,
>each connected only to the ACSE rather than spanning the space between
>the application and the presenation layer as dictated by the model.

Sounds as if you are trying to create layers where there is not
supposed to be one. ACSE is not a layer, it is a service element for
establishing an association and disconnecting.

ACSE itself does not at all deal with the other ASEs. The "Structure 
of the Application layer" standard (I don't have it ready at hand, 
can't remember the number) gives a (terribly) conceptual description 
of how a SACF, which is something else than ACSE, adminsters different
service elements. This is a necessary muxing/demuxing that must be
done somehow, but it is all a local affair and the standard is just
a way do describe at a conceptual level how they are coordinated.


Ketil Albertsen

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 93 14:32:04 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan29.083434.524@novell.com>, donp@novell.com (don provan) writes:

>In article <1k9vpaINNrdl@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>>In ten years, there is a significant possibility that TCP will be running
>>over CLNP.
 
>And if that comes to pass, then CLNP will be remembered as the network
>layer protocol of the Internet protocol suite, not as the network
>layer of the OSI protocol suite.  So i stand by my prediction.

I believe that Tony Li made an unintentional typo - that he meant to write
'TCP over CONP'. Otherwise his statement makes little sense.

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 15:47:42 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

 dank@cco.caltech.edu (Daniel R. Kegel) writes:
>donp@novell.com (don provan) writes:
>
>>IP doesn't have to "take over", since it's the installed based in virtually 
>>every market that isn't dominated by proprietary networking.  
>>						donp@novell.com
> 						     ^^^^^^
>For somebody who works at the company responsible for nearly all the
>growth in proprietary networking in the last five years, you seem
>to have a considerable affinity for TCP/IP.  

Don's IP lineage far exceeds his years at Novell.  When you look
at Novell's NLMs, LWP, LWG, Unix, etc. you see a company with
a future in TCP/IP.

>Is this shared by your company as a whole

Novell has the ultra-capitalistic viewpoint that they will sell
you whatever you want to buy.  That's why they offer scads of
TCP, OSI, and other products which fit into their bulky product
guide. 


Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 93 16:47:02 GMT
From:      alanj@endeavor18.tek.com (Alan Jeddeloh)
To:        comp.protocols.tcp-ip
Subject:   Re: Q: Where to find a intro. to DNS etc.

In article <1993Jan29.180626.1562@ccc.govt.nz> david@ccc.govt.nz writes:
>Anyone know where I can get a brief introduction to the Domain Name System?
>Something that covers MX resords too.

Albitz, Paul and Cricket Liu. _DNS and BIND in a Nutshell_.  O'Reilly &
Associates, Inc.  Sepastopol, CA USA.  1992.  ISBN 0-56592-010-4.

--
    Alan Jeddeloh      W:(503) 685-2991  H:(503) 292-9740
    Tektronix, Inc.; D/S 60-850; PO Box 1000; Wilsonville, OR 97070
    Alan.Jeddeloh@tek.com 
    You can put the children to bed, but you can't make them sleep!

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 93 18:04:23 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Large Windows and Delayed Acking

In article <1993Jan21.233655.29402@gordian.com>, mike@gordian.com (Michael A. Thomas) writes:
|> 
|>   I have been playing around with a TCP implementation trying to get
|> the throughput up and discovered an interesting anomaly with large
|> windows. The setup I have is a program which is an infinite data
|> source sending to the discard port (port 9) on a remote machine over
|> ethernet. I am merely measuring the bandwidth and occassionally reporting
|> that to the user -- nothing complicated.
|>   What I have found is that with large windows (say 16kb) the sending
|> TCP stops sending at about 4k and waits for the receiving TCP to
|> send an ACK. The receiving TCP, however is using a defered acking
|> scheme which tries to delay sending ACK until a larger window is
|> consolidated into one packet. The metric it is using is 1/2 the
|> buffer size, and the delayed ack period is on the order of 100ms.
|>   I can understand why a sending TCP might be leary of sending *so*
|> much data without hearing an ack, but my question is what algorithm
|> is the sending TCP using to determine how much data it will send
|> before going into this quiesent state? Is there an appropriate
|> RFC which I should read which describes this situation? Is the
|> behavior of the sending TCP correct?
|> 
|>   (BTW, I noticed that the IBM/AIX which extends a 16k window 
|>    has the same problem with a Sun running 4.1.2, so the problem
|>    is not unique to the TCP I'm futzing with...)
|> -- 
|> 

Ah yes, I too have seen this phenomenon but I have the advantage of access
to network source code and a network sniffer.  What you are seeing is an
interaction between the speed at which data acknowledgements are generated
and the way the sender implements write side flowcontrol.  Depending on
the implementation base (I only know about DG's and can only guess about
SUN's and IBM's), the receiver will transmit an acknowledgement every 
0.2 seconds (if an ack is required) OR when the window opens by 35%.
Some newer versions of TCP/IP also send an ACK when 2 fullsize segments
have been delivered to the user application and/or their receive buffer
is emptied.  Transmitters on the otherhand will block writes until at least
50% of total transmit buffer space is available.  It is possible (probable)
that while there is sufficient space in the send window to transmit data, there
is insufficient space in the send buffer to get that data from the application.

So what do you do about it?  I've found that the best performance is obtained
when the transmit buffer size equals or exceeds the receive buffer size. Your
mileage may vary.

--
+------------------------------------------------------------------+
| John A. Scott                       | Phone: +1 919 248 5995     |
| Data General                        | Email: scott@dg-rtp.dg.com |
| 62 TW Alexander Drive               |                            |
| Research Triangle Park, NC 27709    |                            |
+------------------------------------------------------------------+
                                                       


-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 18:23:39 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   CLNP (Was: Info wanted on TCP/IP vs OSI 7 layer)

In article <8370@dove.nist.gov>, west@mgmt3.ncsl.nist.gov (Jim West) writes:

>What ever happened to IS 8473 -- The Connection-Less Network Protocol (CLNP)?
>Saying that ISO Network layer is Connection Oriented is incorrect or at
>least incomplete. 

Let's distinguish between CLNP and CLNS. You can easily build a CO service
on top on a CL protocol - see eg. a TCP-based socket service, based on the 
IP protocol.

Now that we are at IP: Read the introduction to the IP RFC, and see what was
the originally intended application area for IP: As an *interNET* protocol.
(The use of IP as an *interHOST* protocol is a comparatively new idea.)
Although the wording is new, the technical contents is similar in 8473 and
its associated standards: A multi-hop net connection that spans several nets 
may use "local" protocols in their respective nets, while the net-to-net
protocol may be eg. 8473. 

The OSI stack of standard documents is taller than most of us know... MUCH
more that 7 layers... There is also an "Internal organization of the Network
layer", IS 8648, describing an architecture for relaying between nets. That
is, NE-to-NE-to-NE-to... where the NEs may be in different nets. But interacting
at a Net service interface with a TE only at the endpoints.

> The ISO Standards specify a Connectionless service
>and a Connection Oriented service.  Sure, they don't interoperate, but what
>does ISO care about interoperability? :-).

You can never hope to get interoperability between a TE using CLNS and another
TE using CONS, no more than a series of postcards can be received on a phone
as a stream of spoken sentences, or a telephone conversation as postcards.

If a NE by using a CLNP is capable of providing a CONS, smile and be happy! 
Provided one of the NEs along the route both speak CONP and CLNP you will 
also be able to talk to users in nets based on CONP. Provided, of course, 
that people *implement* the OSI protocols. It doesn't matter if the standard 
is good or bad if noone implements it!



-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1993 18:41:46 GMT
From:      dank@cco.caltech.edu (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>Don's IP lineage far exceeds his years at Novell.  When you look
>at Novell's NLMs, LWP, LWG, Unix, etc. you see a company with
>a future in TCP/IP. ...
>Novell has the ultra-capitalistic viewpoint that they will sell
>you whatever you want to buy.  That's why they offer scads of
>TCP, OSI, and other products which fit into their bulky product
>guide. 

Right... but they do seem to be trying to push IPX by offering it for
free with Unix, whereas they charge for TCP/IP.  It's not like they
had to spend a lot of money developing TCP/IP for Unix- what is their
excuse for charging?

Novell scares me.  I know this is slightly irrational, but when I see
all those IPXians multiplying out there, and Novell loving every minute
of it, I get the feeling that TCP/IP is under attack.
- Dan 'tcp tribalist' Kegel

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 21:38:18 GMT
From:      mscott@quaver.urbana.mcd.mot.com (Mark Scott)
To:        comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: Netblazer

In article <C1G4xB.B5p@wsrcc.com>, wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:
|> >We're running a slip link from here in Moscow to Alternet in VA, USA. Runs
|> >OK, but: I had to turn V.42/V.42bis off. Reason? It looks like V.42 window
|> >is too small for the huge roundtrip echo delay time (>=.5sec) we experience.
|> >When V.42/V.42bis was enabled, all we could have from ftp and friends was
|> >500-700 bytes/sec, with V.42 turned off we have more pleasant 1100-1300
|> >bytes/sec. Pity we cannot use V.42bis. Anyone knows how to make V.42 window
|> >larger on Telebit and/or ZyXEL?
|> 
|> Such a feature would be nice.
|> 
|> Another thing that would be useful is a way to push (flush) the
|> current v.42 packet out of the modem.  This would be very useful at
|> the end of TCP packets, to cut down on a bit of the delay.  
|> 
|> I wonder if any modem manufacturers is doing work in this regard.
|> 
|> -wolfgang
-- 
Codex makes modems that have features to provide "echo cancellation"
& other enhancements to fix problems encountered when your calls 
get routed over satellite & etc. You should be able to use them with 
the NetBlazer, but I think you'll need Codex modems on both ends.

_________________________________________________________________________
Mark Scott			
Motorola Computer Group 
Urbana Design Center	
#include <std/disclaimer.h>

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1993 21:54:03 GMT
From:      ppinta@cs-acad-lan.Lakeheadu.Ca (Pasi Pinta)
To:        comp.protocols.tcp-ip
Subject:   Looking for PC based RARP server software


  We are looking for PC based RARP server software.  We have currently a SUN 
670MP running a RARP server, but it can not pass through our router.  BOOTP 
could but its no good for our mixed environment of machines. Our router separates
three subnetworks, each of which uses a separate class c IP number set.  If
there was a PC based version of RARP we could take three old clunker XTs and
set them up on the three subnetworks to serve the administering of IP numbers
for TCP/IP purposes instead of re-aligning our mainframe's to do the same.
Any information regarding the availability (commercial/freeware) of the above
would be greatly appreciated.

Please mail me directly.  I'll be glad to post a summary if there is demand
or mail a summary of any replies to anyone interested.

Thank you for your help.

Pasi Pinta
Faculty Computer Advisor
Lakehead University
Thunder Bay, Ontario
CANADA
ppinta@cs-acad-lan.lakeheadu.ca
ppinta@thunder.lakeheadu.ca

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 21:58:35 GMT
From:      dhepner@cup.hp.com (Dan Hepner)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?


From: dchen@ctp.com (Denys Chen)

>What does it mean by "DCE COMPLIANT" from the perspective of a DCE 
>application DEVELOPER (people who develop application that runs in DCE) ?

There are different definitions.  Some for real, some somewhat sleazy.

DCE can be seen as two independent things: the specification of
several programming interfaces, and implementations of those
interfaces.

Those who offer DCE implementations thus have the theoretical capability
of doing an implementation of the APIs independent of buying
licensed C code from OSF.  If they faithfully implemented the
APIs, they could legitimately claim to be "DCE compliant".

Also, someone selling an applications could supply it as either
DCE clients or servers, using DCE services in lieu of doing
anything done by DCE themselves.  This application would be
described as "DCE compliant".

Some would like to claim an association with DCE, and describe
their "DCE RPC like" or "CDS like" products as "DCE compliant",
using a definition which implies that they could be made to
work in a DCE environment with some unspecified amount of
work.

And some application providers imagine that their clients or
servers could, again with some amount of work, interact
with other DCE applications, although perhaps it uses some
proprietary service rather than a DCE supplied service.

The "real" test of DCE compliance of an application is whether
it _uses_ the DCE name service to broker clients and servers,
it uses the DCE security services to do authentication and
authorization, if it needs threads it uses DCE threads, and
it uses DCE RPC.  If it needs to know the time it uses the DCE 
time service, etc.  Such truly compliant applications know that 
they can depend on other similarly compliant DCE applications to be 
using identical services, and they are free to codify this dependence 
in assumptions made by the application.


>What does it mean by "DCE COMPLIANT" from the perspective of a DCE 
>application USER (people who use application developed by DCE application
>developer) ?

It might not mean much to the user, unless the user is also the
one who specifies functionality and pays the bills.  DCE compliant
applications facilitate changing vendors; if one vendor's server
doesn't provide sufficient functionality, or costs too much, one
could go to a competitor.  Note that DCE compliance however does
not put restrictions on what API the DCE server exports, nor the
client expects.

>I tried to give it a definition as "any software that can be plugged 
>into the net by relying on DCE's Name Service, Time Service, and 
>Distributed File System (AFS) is DCE COMPLIANT." 
 
>My statement also implies that the software does NOT need to use DCE's RPC
>as transport service.
>Denys Jyh-Hwa Chen

This definition would severely compromise the promise of DCE.  How would 
it be guaranteed to interoperate with other DCE applications?  Profound
in the promise of DCE is that clients and servers might be provided by
different vendors.

Dan Hepner

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jan 1993 22:22:59 GMT
From:      tmax@well.sf.ca.us (Eric Melbardis)
To:        comp.protocols.tcp-ip
Subject:   Looking for xtp software implementation(s).


?

Hi.
	I am looking for any available xtp (xpress transport protocol)
	implementations available in software. Can any one help?

Thanks in advance

Eric Melbardis
tmax@well.sf.ca.us

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 93 00:48:43 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1k9st2INNnnq@gap.caltech.edu> dank@cco.caltech.edu (Daniel R. Kegel) writes:
>Where can we read more about ACSE?  Is this an OSI thing?

(Let's see if i can remember this just right....)  Association Control
Service Entity.  (Did i get it right, Jan?)  It's sorta the focal
point of the application layer, which is made up of a bunch of
cooperating elements providing various facilities needed for the
particular application.

>For somebody who works at the company responsible for nearly all the
>growth in proprietary networking in the last five years, you seem
>to have a considerable affinity for TCP/IP.  Is this shared by your
>company as a whole - i.e. can you explain why your company plans to
>offer IPX rather than TCP/IP as the default networking environment
>in their UNIX product?

No, i do not speak for Novell, but i am comfortable with Novell's
attitude towards TCP/IP.  In fact, i humbly take some pride in having
played a minute role in shaping Novell's current TCP/IP directions.

I will say, though, that your assumption that it would cost Novell
nothing to include TCP/IP in all versions of UNIXWare is invalid.
Not even close to valid, in fact.
						don provan
						donp@novell.com

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 93 01:16:49 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1kbtpaINNhna@gap.caltech.edu> dank@cco.caltech.edu (Daniel R. Kegel) writes:
>Novell scares me.  I know this is slightly irrational, but when I see
>all those IPXians multiplying out there, and Novell loving every minute
>of it, I get the feeling that TCP/IP is under attack.

Good.  Now that OSI is losing momentum, without a threat the TCP/IP
community might get complacent.  Make TCP/IP better than NetWare, and
TCP/IP can take over the world.  Just don't be surprised if you see
Novell in the lead of *that* charge, as well.

Keep in mind that TCP/IP isn't under attack by Novell.  We're not
giving away IPX: people are *buying* it, so they're the ones to
"blame".  And we *are* loving every minute of it, but only because it
means we're producing products that people want to pay us money for.

Think "solution", not "protocol".  And "cooperation", not "turf".

					don provan
					donp@novell.com

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 1993 02:02:22 GMT
From:      doleary@cisco.com (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan29.143210.583W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
 [various deleted quoted text]
>I believe that Tony Li made an unintentional typo - that he meant to write
>'TCP over CONP'. Otherwise his statement makes little sense.

TCP over CLNP makes more sense than TCP over CONP to me (you know,
redundant functionality and all that).  Tony is more than capable of
speaking for himself (but I'll butt in anyway :-), I expect he is
referring to some of the proposed options for dealing with IP address
space exhaustion, i.e. run TCP (and associated applications) over CLNP.

						dave



-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 1993 02:14:16 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan29.143210.583W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
    >In article <1k9vpaINNrdl@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
    >>In ten years, there is a significant possibility that TCP will be running
    >>over CLNP.
    
    I believe that Tony Li made an unintentional typo - that he meant to write
    'TCP over CONP'. Otherwise his statement makes little sense.

No, I was exactly correct in what I wrote.  What makes little sense about
doing that?

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 93 18:06:25 NZDT
From:      david@ccc.govt.nz
To:        comp.protocols.tcp-ip
Subject:   Q: Where to find a intro. to DNS etc.

Anyone know where I can get a brief introduction to the Domain Name System?
Something that covers MX resords too.

Thanks in advance

David
-- 
David Richards, Systems Programmer, Christchurch City Council
MIS unit, PO Box 237, New Zealand | Ph +64 3 3711-689
Fax +64 3 3796-706 david@ccc.govt.nz PSI%0530130010083::DAVID
"Build That Body, Ski That Slope, Travel That World."

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 93 07:50:31 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan29.134201.29439W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>>If I'm not allowed to use TP4, I'll stick to my Internet protocols...
>
>Seriously: Who is "I", who demand the right to use TP4? Certainly not the
>implementor of the net entity...Certainly not the implementor of the session
>entity...Certainly not the implementor of presentation entity, not the
>implementor of OSI applications...
>
>So you must be a transport entity implementor...

*Classic* OSI mentality: you never even consider that the "I" that's
demanding could be an actual *user*, willing to back up demands with
purchase decisions.  This might explain why users aren't showing much
interest in OSI anymore.
						don provan
						donp@novell.com

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 08:25:16 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan29.142850.368W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>In article <1993Jan28.201534.16358@novell.com>, donp@novell.com (don provan) writes:
>> X.25 was wedged into the OSI model by inventing a null
>>transport layer and a null network layer so that the datalink layer,
>>x.25, can manifest itself directly at the transport service layer.
>
>'Scuse me??? X.25 is a *protocol* spec, not a service spec.

Of course it's a protocol.  It's a protocol that has characteristics
clearly belonging to the transport, network, and datalink layers of
the OSI model.  Are you saying that the OSI model is only a taxonomy
for interfaces, and it doesn't matter how the protocols fit into it?

>"Null transport layer"? Huh? Say, which edition of X.214 are you reading?

I've never even heard of X.214.  I was speaking of TP-0, a transport
protocol which doesn't do anything.  The term i used for that is "null
transport layer".  Would "null transport protocol" have been a less
confusing term?

>X.25-3 is a net protocol, for use by some net entity.

I think this is where the connection oriented OSI camp loses TCP/IP
folk such as myself.  How can nodes expect to communicate with each
other if they each use a different protocol at the network layer,
depending on the type of network they're using?  How is my PC here on
this 802.3 network going to receive or understand the X.25 packets
you're sending?
						don provan
						donp@novell.com

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 1993 09:31:03 GMT
From:      dank@cco.caltech.edu (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

donp@novell.com (don provan) writes:
>Keep in mind that TCP/IP isn't under attack by Novell.  We're not
>giving away IPX: people are *buying* it...

Before I go on, let me say I appreciate anyone at Novell who is working
on open (i.e. non-proprietary) protocols such as tcp/ip, and who is willing 
to tell us about it on the net.  Now, onwards:

Correct me if I'm wrong, but I understood that Unixware ships with
IPX free, but TCP/IP is extra cost.  So customers of Novell's shrinkwrap
Unix aren't buying IPX, they're getting it free, whether they want it or not.
Sounds like Novell wants to encourage Unix users to use IPX rather than TCP/IP.
Funny, that.

I wouldn't mind getting Unix from Novell, if only it came with tcp/ip.
Otherwise, gee, maybe I'll switch to Microsoft's NT; after all, it supports 
the Posix API & tcp/ip for free.  Never thought I'd think of Microsoft
as a white knight, but there you are.
- Dan K.

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 11:11:14 GMT
From:      mbm@netarch.com (Mike Morey)
To:        comp.protocols.tcp-ip
Subject:   Multiple Class C networks on a single Ethernet

I have a client who wants to connect 2 separate class C networks
onto a single ethernet and want hosts on these two networks to
talk to each other.

The situation is as follows :

One of our clients has an Internet connection through a Cisco router
and operates 2 separate DNS domains on one single ethernet segment.

For simplicity, lets call the 2 domains (and the associated Class C
network number) :

	tree.com (201.10.23.0)
	shrub.com (198.213.20.0)

with the following hosts and IP address :

	a.tree.com (201.10.23.12)
	b.shrub.com (198.213.20.3)

(Please note that these are fictitious names and addresses)

                       One ethernet segment

    ========+===============+==================+==============
            |               |                  |
            |               |                  |
          +-+-+           +-+-+          +-----+----+
          |   |           |   |          |          |
          |   |           |   |          |  Router  |
          +---+           +---+          |          |
       a.tree.com       b.shrub.com      +-----+----+
     (201.10.23.12)   (198.213.20.3)           |
                                               |
                                          To Internet (e.g. BaRRNet)

They want a.tree.com to have network connectivity to b.shrub.com and
vice-versa. Services like telnet rlogin, ftp, sendmail, DNS, etc
are desired.

They would also like Internet hosts to have access to both these machines
as well.

The routing tables have been set on both machines so that both machines
know the route to the other machine.

Does this work ? I tried all kinds of configurations but I can't
get a.tree.com to talk to b.shrub.com.

Because of limitation of resources, the client is not able to install
a second ethernet.

If you have any suggestions as to what else I may try, please let me
know. In any event, I would love to hear responses from the net
as to whether the proposed plan is feasible.

I know that the right thing to do is to get a dual-port Cisco router
but due to limitation of funds, the client would like to make do
with the configuration as outlined above.

Please email responses to me as I do not access the newsgroups very
often. I will summarize if there is interest.

Thanks again

/Mike

mbm@netarch.com

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 14:04:11 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
> >So what do we use if we want reliability? TP0 over X.25 is simply not good
> >enough. TP0 and TP4 are by far the most commonly implemented...
> 
> As I said the other day: As soon as people start *implementing* those
> OSI protocols, they will work much better... The solution to X.25 not
> being reliable enough is, IMHO, *not* to throw out the OSI model but
> to use OSI style handling: TP1 or TP3.

Maybe so. I have a network to run. I'll start thinking about TP1 and TP3
when a significant number of the people we are connected to, do the same.
So far we've seen very little interest in TP1 and TP3.

> If you are claiming that the residual error rate (that is, undetected
> and unreported errors) is too high for your requirements, I think you
> should support that with numeric figures for the actual error rate
> in the X.25 net you are using. Have you and your service provider
> ever agreed on test procedures to measure this? I would be *extremely*
> surprised if the residual error rate was a problem. After all,
> a significant fraction of bank transactions all over Europe go across 
> X.25. If it is good enough for the banks, you must have some very
> special needs if it is not good enough for you!

As I said, I have a network to run. In this case Uninett (the Norwegian
University and R&D community network), and more specifically email within
Uninett. The simple fact is that our X.25 connections vary widely in quality,
but *many* of them have the problem that you cannot get a large email message
through across an X.25 connections. We do *not* have this problem on our TCP
connections.

The reason for the problem is that when sending a large message there is a
significant (close to 1) probability that sooner or later we get an X.25
RESET, and the email session is dropped. Of course it is retried again later,
but some messages *never* get through. What "large" means here varies: Some
X.25 connections will only allow about 100 kBytes or so of email through, on
others I've been able to get up to 3 Megabytes through. Yes, this *does*
happen on our connections with the Norwegian Telecom. Yes, we have checked
that the RESETs come from the Norwegian Telecom X.25 switches.

I am certainly not arguing that X.25 is useless - far from it. But if you
insist on sending large email messages, it's not good enough. You might say
that the users shouldn't be so dumb as to send messages several megabytes in
size - but they do! And I have to provide a *service* to my email users. I
have to use software available *today*, on our current hardware platforms,
to provide this service. I cannot wait for wonderful new software products
and protocol implementations that might become available two, or five, or
ten years from now.

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

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 14:19:52 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

donp@novell.com (don provan) writes:
> In article <1993Jan29.134201.29439W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
> >>If I'm not allowed to use TP4, I'll stick to my Internet protocols...
> >
> >Seriously: Who is "I", who demand the right to use TP4? Certainly not the
> >implementor of the net entity...Certainly not the implementor of the session
> >entity...Certainly not the implementor of presentation entity, not the
> >implementor of OSI applications...
> >
> >So you must be a transport entity implementor...
> 
> *Classic* OSI mentality: you never even consider that the "I" that's
> demanding could be an actual *user*, willing to back up demands with
> purchase decisions.  This might explain why users aren't showing much
> interest in OSI anymore.

Don Provan got is exactly right - I was speaking as a *user* of transport
services. As a user, I am not satisfied with TP0 over X.25. TP4 is fine,
I can use it both for my LAN and for WAN connections. And as a user, (and
a purchaser) I can, fortunately, vote with my wallet.

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

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 16:05:55 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1kco9oINNqnl@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:

>    >>In ten years, there is a significant possibility that TCP will be running
>    >>over CLNP.
>    
>    I believe that Tony Li made an unintentional typo - that he meant to write
>    'TCP over CONP'. Otherwise his statement makes little sense.
>
>No, I was exactly correct in what I wrote.  What makes little sense about
>doing that?

Nothing except that you don't have to wait for ten years - that is what we are
doing today! IP is most definitely a CLNP. There is a significant possiblitity
that we will still have IP running in ten years - I sure agree with that. I am
just surprised that you made it an issue on a ten year scale.


-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 1993 16:06:22 GMT
From:      Charles Menser <charles@shadow.peachnet.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Please tell a newbie the differences betw FSP and FTP and ...

In article <C1MCxE.n4p@news.iastate.edu> John Hascall, john@iastate.edu
writes:
> FSP uses UDP and can be setup on any port# making it (next to)
 impossible
> to filter.
> 
> It has turned into a major time sink here dealing with these little
twerps.

Is there anything unique in the login procedures of FSP? Even a small
string?

Finding the buggers from within a host might be rough, but I can have a
protocol sniffer sit on the net and watch, most of the time [i.e. when it
is not watching for other foul play].

Charles

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 16:07:04 GMT
From:      ttvvtt@mixcom.com (Donald Amby)
To:        comp.protocols.tcp-ip
Subject:   Subnet masks within Class B Internet address

I am posting the following for one of our system managers:

    Our parent company has an official Class B(!) Internet address (139.69),
    and my subsidiary has been assigned subnets 139.69.48 to 139.69.63.
                                          In hex:86:45:30 to  86:45:3F
    
    I'm trying to decide what to use as a subnet mask.
    
    With FF.FF.F0.00 our entire address range would be one 4K-node net.
    FF.FF.F8.00  = 2 2K-node subnets.
    FF.FF.FC.00  = 4 1K-node subnets.
    FF.FF.FE.00  = 8 500-node subnets.
    FF.FF.FF.00  = 16 255-node subnets
    
    Physically, the WAN is three bridged/routed sites, so it acts like one
    net, but does it make sense to declare each site a subnet, or each
    department?  Should we keep everything on one big net?  Should future
    flexibility dictate at least *some* subnetting?
-- 
Donald E. Amby
    amby@mixcom.com             414-797-6713 (voice)   414-797-6533 (FAX)
    Harnischfeger Engineers, Inc., P.O.Box 1512, Milwaukee, WI 53201-1512

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 16:28:46 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan30.075031.20976@novell.com>, donp@novell.com (don provan) writes:

>*Classic* OSI mentality: you never even consider that the "I" that's
>demanding could be an actual *user*, willing to back up demands with
>purchase decisions.  This might explain why users aren't showing much
>interest in OSI anymore.

The OSI philosophy is making a clear distinction between WHAT to do and
HOW to do it. The actual *user* makes demands to the WHATs. Essentially,
the OSI customer buys *solutions*, not mechnanisms.

The engineer takes care of the HOW. TP4 is a part of the HOW, not a 
part of the WHAT.

Before anynone turns on their flamethrower: Surely part of the WHAT may
imply something about the viability of a HOW alternative. So if the WHAT
is to provide connectivity with someone who is running TP4 only as part
of *his* HOW. 

That is not the typical situation in Europe, and when a customer can buy 
(assume for this discussion that the price is acceptable) *both* 
interconnectivity *and* all the WHAT, I think it is silly for that customer 
to state: Well you give me the problem solution I needed, but you did it
using a mechanism that I disagree with, so therefore I rather go to
someone else who uses my favorite techniques to make a poorer solution
- but then it is done MY WAY.

That is how I read Steinar's approach in his posting that started this:
He will reject a problem solution suiting the market he is in (Europe), 
if it doesn't use his favorite TP4 technique, even if TP4 would mean a 
poorer solution (reduced connectivity).  Well, I can't force him
or anyone else to reject more suitable solutions just because they
have this idea that one single technique is the only viable - I just
think it a little silly.

It would be equally silly of me if I were trying in the USA to buy
an OSI Transport network, demanding that it be based on TP3 and
X.25. I suppose I could buy it, but it wouldn't be very useful to
me if all the others run TP4 over IP.





-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 16:59:27 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan30.082516.21240@novell.com>, donp@novell.com (don provan) writes:

>Of course [X.25] a protocol.  It's a protocol that has characteristics
>clearly belonging to the transport, network, and datalink layers of
>the OSI model. 

Net, link, *and physical*: Yes. X.25 explicitly covers these three layers;
who would deny that. Chapter 1 defines physical, chapter 2 link and chapter
3 "packet layer".

But Transport? It sure does a lot of the things that TCP does in the Internet 
suite, but that doesn't mean that it belongs in the OSI transport definition!

There are a few things that, according to X.200, Net DOES, and Transport
MAY DO; the model isn't 100% rigid and absolute in all details. So some
responsibilities may, in an actual service definition, be placed at either
side of the service interface. 

For argument's sake you could say that if either Net or Transport can do it (eg. 
muxing), if Net does it, it has "characteristics clearly belonging to transport". 
I'll accept that for the fun of the argument, but it isn't very enlightening.

> Are you saying that the OSI model is only a taxonomy
>for interfaces, and it doesn't matter how the protocols fit into it?

The OSI reference model is a taxonomy for communication related 
*functionality*. This functionality is accessed through a service interface
and realized by a protocol interface. A, or any, protocol capable of
supporting the defined functionality is acceptable. A protocol that
canNOT support the functionality doesn't qualify. So the answer is
negative: No, the OSI model is more, and it does matter how the
protocols fit in.

>>"Null transport layer"? Huh? Say, which edition of X.214 are you reading?
>
>I've never even heard of X.214.  

Why don't you go out and get a copy of it. It might give you a few surprises.

>I was speaking of TP-0, a transport protocol which doesn't do anything.  

You'll find it in X.224; I suppose you don't know that one, either. You may
run TP0 across TCP, across X.25, across a modem line, across ISDN. Adapting
to such a diversity of networks, both the various degrees of service and
eg. different addressing - is that to do "nothing"?

What about segmentation and reassembly - is that to do "nothing"?

If you provide multiple transport connections across (say) individual
TCP connections, running TP0 on each of them, you have to manage the
TSAP-to-TCPport. Is that management to do "nothing"?

Oh, well, if you have never heard of the standard documents, I suppose
you are rather thin on the responsibilities of the Transport layer.


K.A.

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 21:35:49 GMT
From:      dchen@ctp.com (Denys Chen)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?



In article <C1MyDo.BBA@cup.hp.com>, dhepner@cup.hp.com (Dan Hepner) writes:

|> (... Good explanation deleted...)
|>
|> The "real" test of DCE compliance of an application is whether
|> it _uses_ the DCE name service to broker clients and servers,
|> it uses the DCE security services to do authentication and
|> authorization, if it needs threads it uses DCE threads, and
|> it uses DCE RPC.  If it needs to know the time it uses the DCE
|> time service, etc.  Such truly compliant applications know that
|> they can depend on other similarly compliant DCE applications to be
|> using identical services, and they are free to codify this dependence
|> in assumptions made by the application.
|>
|> (... Good explanation delete...)
|>
|> >I tried to give it a definition as "any software that can be plugged
|> >into the net by relying on DCE's Name Service, Time Service, and
|> >Distributed File System (AFS) is DCE COMPLIANT."
 
|> >My statement also implies that the software does NOT need to use DCE's RPC
|> >as transport service.
|> >Denys Jyh-Hwa Chen
|>
|> This definition would severely compromise the promise of DCE. 

Doesn't my definition sound exactly the same as the "real test" you 
describe above ?

|>                                                               How would
|> it be guaranteed to interoperate with other DCE applications?  

It's guarranteed to interoperate with other DCE applications because it 
_relies_ (i.e., _uses_) DCE's Name Service, Time Service, etc.

|>                                                               Profound
|> in the promise of DCE is that clients and servers might be provided by
|> different vendors.

My statement does NOT limit _vendor_ of the applications. My statement 
starts with "_any_ software ...".

Maybe you can elaborate a bit more about what'd be compromised by my
statement.

Overall, to me, your posting is quite informative and articulate. 
It really helps. Thank you.

---------------------------------------------------------------------------
NOTHING IN THIS ARTICLE REPRESENTS VIEWPOINT, OPINION, OR WHATSOEVER OF THE
ORGANIZATION FROM WHICH THIS ARTICLE IS POSTED.
---------------------------------------------------------------------------
 /\/\ |Denys Jyh-Hwa Chen                 | //Definition of "communism" :
/ /_.\|Cambridge Technology Partners, Inc.|
\  /./|304 Vassar St.  Cambridge, MA 02139|   static void Person::own() {}
 \/\/ |Voice:617-374-8271 Fax:617-374-8300|

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 93 21:50:27 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Generic IP address

In article <1993Jan26.185514.19852@walter.bellcore.com> pietro@nova.bellcore.com writes:
>Is there anybody who knows if it's possible to send a message specifing a
>generic address.
>
>I'm not talking of multicast, I'm just wondering if it could be possible
>to send a datagram without specifing a destination address.
>
>This type of datagram should be interpreted as: the first host that receives
>the datagram is the destination host...

I'm afraid this just isn't possible with most of the network technologies in
use today.  A packet must either be explicily addressed to a single destination,
or where supported, a specific group of destinations.

>-- Pietro

Art

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Jan 1993 22:41:37 GMT
From:      ae2@cunixa.cc.columbia.edu (Amiran Eliashvili)
To:        comp.protocols.tcp-ip
Subject:   Reliable Broadcasting

Hi all:

Does anyone know of any references that addresses the issue of reliable
broadcasting using UDP. Btw, does any one has any experience with MTP?

thanks for any response

/amiran

please send mail to ae2@cunixa.cc.columbia.edu


-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 04:28:45 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Please tell a newbie the differences betw FSP and FTP and ...

Charles Menser <charles@shadow.peachnet.edu> writes:
}John Hascall, john@iastate.edu writes:
}> FSP uses UDP and can be setup on any port# making it (next to)
}>impossible to filter.
}> It has turned into a major time sink here dealing with these little twerps.
 
}Is there anything unique in the login procedures of FSP? Even a small string?

There's not even a login procedure.  FSP is a set of commands (FSP is to
FTP as MH is MAIL in this respect).  Near as I can tell, FSP is specifically
designed for illicit use (to avoid detection and survive denial of service
attach).

}Finding the buggers from within a host might be rough, but I can have a
}protocol sniffer sit on the net and watch, most of the time [i.e. when it
}is not watching for other foul play].

About all you can do filter-wise is to block all UDP ports except those you
specifically want to pass (this should do a reasonably good job of keeping
anyone from running a fsp-server at your site as they would have to tread
on some other service).  This should do a fair job of blocking clients too
(of course, a fsp-server at some other site could be setup on a generally
passed port [say, domain]).  As always, a technical solution to a policy
problem, is at once over-restrictive and under-effective.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Wild-Eyed Visionary
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 1993 09:03:54 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan30.160600.13608W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
    In article <1kco9oINNqnl@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
    
    >    >>In ten years, there is a significant possibility that TCP will be running
    >    >>over CLNP.
    
    Nothing except that you don't have to wait for ten years - that is what
    we are doing today! IP is most definitely a CLNP. There is a
    significant possiblitity that we will still have IP running in ten
    years - I sure agree with that. I am just surprised that you made it an
    issue on a ten year scale.
    
Well, I am aware that lab implementations exist.  I was thinking more along
the lines of it being the de-facto standard service.  I will easily believe
it will take ten years to fully deploy TCP/CLNP.

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 12:47:36 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>In article <1kco9oINNqnl@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
>
>>    >>In ten years, there is a significant possibility that TCP will be running
>>    >>over CLNP.
>>    
>>    I believe that Tony Li made an unintentional typo - that he meant to write
>>    'TCP over CONP'. Otherwise his statement makes little sense.
>>
>>No, I was exactly correct in what I wrote.  What makes little sense about
>>doing that?
>
>Nothing except that you don't have to wait for ten years - that is what we are
>doing today! IP is most definitely a CLNP. There is a significant possiblitity
>that we will still have IP running in ten years - I sure agree with that. I am
>just surprised that you made it an issue on a ten year scale.

You still don't get the point... ISO CLNP is *one* of the proposals for the
*next* generation of Internet IP - ie. as the followup to IP as we know it
today. There are several other proposals also, read the "big-internet"
distribution list for discussions on this. I believe *this* is what Tony Li
referred to when he said that in ten years there is a significant possibility
that TCP will be running over CLNP.

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

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 93 13:12:03 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
> That is not the typical situation in Europe, and when a customer can buy 
> (assume for this discussion that the price is acceptable) *both* 
> interconnectivity *and* all the WHAT, I think it is silly for that customer 
> to state: Well you give me the problem solution I needed, but you did it
> using a mechanism that I disagree with, so therefore I rather go to
> someone else who uses my favorite techniques to make a poorer solution
> - but then it is done MY WAY.
> 
> That is how I read Steinar's approach in his posting that started this:
> He will reject a problem solution suiting the market he is in (Europe), 
> if it doesn't use his favorite TP4 technique, even if TP4 would mean a 
> poorer solution (reduced connectivity).  Well, I can't force him
> or anyone else to reject more suitable solutions just because they
> have this idea that one single technique is the only viable - I just
> think it a little silly.

No, I am afraid you misunderstand. I'm saying that TP0 over X.25 is, in some
cases, simply not good (reliable) enough. The ISO solutions I have available
today are TP0 and TP4, but I also have TCP/IP available.

I'm doing exactly what you suggested, namely demanding a reliable, connection-
oriented transport service. Please note that the other solution offered to me,
TP0 over X.25, is not acceptable according to *my* reliability criteria, which
are indeed part of my demands on the "WHAT". Are you saying that I'm not
allowed to specify what reliability I want?

My reliability criteria can be satisfied if I use TP4. But if I can't use TP4
(you were the one who suggested that TP4 should be outlawed :-), I'd rather
use TCP/IP. Also, I'm (implicitly) saying that I expect both TP4 and TCP to
give me sufficient connectivity.

I don't expect us to agree on this...

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

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 14:35:54 GMT
From:      mundt@casbah.acns.nwu.edu (John Mundt)
To:        comp.protocols.tcp-ip
Subject:   line discipline status from an inetd fork

I have a library on-line public application program that I would like
to make available on a TCP/IP port, served up by inetd.  I've got it
set up fine, and it executes, but the line discipline as set by inetd
is not what I expected.

Lacking source code, what does inetd do to stdin and stdout?  I've
found that I have to do a fflush() to make printf() statements appear
prior to the application running.  I assume that inetd does not set
the tty line into the same configuration that it would for a standard
serial line terminal.

Question 1:  What does inetd do?  
Question 2:  Who has dealt with this before, and what did you do?
Question 3:  Rather than my re-invent the wheel, does someone have a code
             fragment that would set the line properly?
Question 4:  Finally, am I barking up the wrong tree?

Thanks for your help.

John

-- 
---------------------------------
John Mundt                    mundt@casbah.acns.nwu.edu
Glenview School District 34   mundt@chinet.chi.il.us
(And coming real soon now...  mundt@ncook.k12.il.us)

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 19:13:15 GMT
From:      smurph@sdf.lonestar.org (Steve Murphy)
To:        comp.protocols.tcp-ip
Subject:   Connecting two 10baseT machines together.


Howdy,

	Well, I finally convinced the boss to buy a couple of SMC elite 16
ethernet boards. The cards have an "ARU" (sp?) port and a RJ45 jack for
Unshielded Twisted pair. I remember reading on the net that one can wire
two machines together without a "hub" by using what would be analogous 
to a "Null Modem cable" in the RS232 world. My assumption is that one
would "cross" the receive and transmit wire(s). Anyone know for sure?
Please let me know.

Thanks in advance,

Steve
Go Cowboys!!

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 19:57:08 GMT
From:      tmax@well.sf.ca.us (Eric Melbardis)
To:        comp.protocols.tcp-ip
Subject:   Wanted: sources for xtp (eXpress Transport Protocol)


Hello out there.

Does anyone have a software implementation of xtp as defined by
Protocol Engines (vrsion 3.64 or other?).
Thanks.

Eric Melbardis
tmax@well.sf.ca.us

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 21:39:36 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   CLNP

Several people writes:

> [a lot of stuff about CLNP as a new and upcoming Internet protocol thing]

OK, you caught me. To me, and a lot of others, CLNP is simply (any)
ConnectionLess Network Protocol, not a specific one marketed by that
name. Large parts of the network community (although it may be most prominent
in the OSI-oriented part of the world) would interpret it this way,
and in the general sense, good old IP is definitly a CLNP.

So, if you next time make it clear that you are talking about the
specific CLNP and not the general concept of a CLNP,  you are more
likely to be understood correctly.

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Jan 1993 23:09:35 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

cliffb@cjbsys.bdb.com (cliff bedore) writes:

>In article <19971@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>>2) What options are available for small (less than a dozen nodes) networks
>>currently running coax and wanting to move to 10BaseT?  For example, I
>>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>>available which are cost effective for small networks?
 
>For 1,2,3 or so systems, coax may be just fine but beyond that, you get into
>the complexities of having to run basically 2 cables to each PC.

Everyone here seems to think that thinnet is the kludgy daisy-chained
thing you find in development labs.  We have thinnet wired sub-floor
with neat make-before-break connecters with a twin length of coax out to
a BNC plug. We just moved almost *everyone* round here, and only had one
problem, that of one segment that ended up with too many drops on it.
Fixed with a run of coax from the repeater.

If we'd had 10Bt it just wouldn't have been possible without pulling
lots of wire. Everyone says "it's more flexible". Or am I missing
something? Like a bigger budget? :-)

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
PIPEX is a division of Unipalm Ltd. - phone 0223 424616.

END OF DOCUMENT