The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for March 1991 (353 messages, 180385 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/03.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 Mar 91 04:12:16 GMT
From:      digennar@umbc3.UMBC.EDU (Mr. Jerry DiGennaro)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Request for information on netmask


Could somebody please point me in the direction of any easy to
comprehend essay on the purpose and use of the TCP-IP netmask feature?
Or, could someone e-mail me a brief description of netmask?  Some
specific questions are:

What is the difference between 255.255.255.0, 255.255.0.0 and 0.0.0.0?
How is the netmask used?
Why does it exist?
What other questions should be asked by a novice?

You can send me e-mail to jad@loyola.edu or digennaro@umbc3.umbc.edu or
post a reply to these groups.  Thanks in advance for your efforts.

Jerry DiGennaro
-- 
Jerry DiGennaro			digennar@umbc3.umbc.edu
						(301) 532-5129

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 06:39:48 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?

In article <8698@gollum.twg.com> david@twg.com (David S. Herron) writes:
    	Marshal Roses "The Open Book" (but only if you can stand long
    	digressions into the political maneuvers which networking 
    	development has become ... (*sigh*))

At least Marshal Rose is nice enough to warn the reader when he gets on his
soapbox.  (The margins have "Begin Soap...End Soap" delimiters.)

// marc
-- 
// marc@dumbcat.sf.ca.us
// {ames,decwrl,sun}!pacbell!dumbcat!marc

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 08:04:33 GMT
From:      j.onions@xtel.co.uk (Julian Onions)
To:        comp.protocols.tcp-ip
Subject:   Re: do me a favor and answer this


>    X.{4,5}00 names for people & mailboxes have (at least) the following attri
 bu
> tes:
> 
>    Country				/C=../
>    Administrative Domain		/ADMD=.../
>    Primary Domain			/PRMD=.../
>    Organization			/O=.../
>    Organizational Unit		/OU=.../
>    Surname				/S=.../
>    Given Name			/G=.../
>    Common Name			/CN=.../
No - you are missing something here. X.400 and X.500 are different.
X.400 was designed before X.500 and therefore X.400 could not rely on
X.500 information. This is why X.400 includes obvious routing things
such as ADMD and PRMD. An X.500 Distinguished Name has almost no
constraints on it whatsoever. In practice, it usual starts with a
Country, Orgnization or locality as the most significant part, but
this is not enforced by the standard. X.500 is used to look up X.400
names so my X.500 DN may be very different to my X.400 mail address
and you can't in general algorithmically derive one from another.
The X.500 name is meant to be natural and 'intuitive' the X.400
address is meant as an address. As it looks so horrible - you are
meant to try and hide it from the users wherever possible (my
opinion). Just to complete this an example:
My Distinguished Directory Name is the following (in white pages
syntax)
C=GB@O=X-Tel Services Ltd@cn=Julian Onions
my X.400 address on the other hand is (in rfc987 syntax)
/C=GB/ADMD= /PRMD=X-Tel Services Ltd/O=Xtel/I=J/S=Onions/



X.400 in the 1984 recommendation says an address is made up of the
following components.
Country, ADMD, PRMD, X121address, TerminalID, Organization,
UniqueUAID, Personal Name (made up of initial, given, surname and
generational-qualifier) organizationalunit and domaindefined-attributes

X.400 only allows one of 5 combinations of these though.
X121address & terminalID (optional)	- used for sending mail when
					- you're infrastructure only
					- supports digits (e.g.
					- phone/telex)
C, ADMD, UniqueUAId & DD (optional)
C, ADMD, X121address & DD (optional)
C, ADMD, + one or more of { PRMD, PN, O, OU, DD }

In practice, it is only the last one that I have ever seen used.
The other cases I think are for a PTT running a service and supplying
a mailbox facility or some such.

In the 1988 X.400 standard a whole bunch of new attributes were added.
There are one or two extensions, such as CommonName for things that
are and aren't people (seems kind of silly to address a list as
'Surname=tcp-ip'). The rest are broadly speaking either Teletex string
forms of the above, so that you can type names in whatever alphabet
you require, or paper postal address attributes to allow interworking
between X.400 and the postal system.

> Are these attributes required of every X.[45]00 people and mailbox
> names, or are they specific to the naming convention chosen by the
> NYSERNet White Pages Project (and possibly others)?

Summary: X.400 is fairly rigid in the addresses you can have, X.500
isn't. The white pages project has a lot of freedom to choose formats,
X.400 people don't have so much. (In practice, you don't get so much
freedom in X.500 - you are dependant on what the higher parts of the
tree define. For E.G. if C=US decided that at the next layer down people are
either put into subtrees type=competent and type=incompetent you are
stuck with this if you want to join the tree :-) ...)

Julian.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 13:27:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   IP addressing & T1 channels

A client of mine is developing a real-time, distributed system that will use the
TCP/IP protocol suite for control & monitoring.  A component in the system will
serve as a gateway between a LAN and a T1 link to (another gateway on) another
LAN.

In addition to control traffic, we will be performing down-line loads to
components on the distant LAN, sometihing like:


         LAN        T1           LAN
Server  ------ GW --------- GW --------- Destination 
                 1            2

Now, we don't want the bulk traffic to cause overly-long delays to the real-time
traffic.  The control traffic will all be on a single 56kbs channel of the T1,
framed in HDLC.  We were contemplating giving the down-line load traffic its own
channel, and using an application at GW2 to receive and distribute big files to
the destinations on the far LAN.

We will be writing our own device driver for the T1.

To me, a "natural" solution to this problem seems to be to use separate IP
addresses for the control and bulk-data channels.

Questions:

1. Would this require separate drivers to get any performance improvements
(i.e., would a sinlge HDLC device driver become a bottleneck)?

2. Is there a better approach?

3. What are the hidden "gotchas"?

4. Where could I look for more info?

Thanks,

Bob Stine
bstine@MCIMail.com
c_rstine@hns.com

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 15:17:00 GMT
From:      JRJONES@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   snmp packages on pc's

Hello,

I have several questions dealing with SNMP and such packages on a PC.

1.  Is anyone using any SNMP package on a PC?
2.  What package are you using and how do you like it?
3.  What short comings do you find?

Because of cost issues we are now going to look at a pc solution so 
any info would really be helpful.

James R. Jones

jrjones@alex.stkate.edu

voice - 612-690-6856

P.S.  I will summarize responses send it over the net for everyone.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 16:02:45 GMT
From:      SRGHGCP@chv.dsir.govt.nz
To:        comp.protocols.tcp-ip
Subject:   Re: NS DP8390 ethernet chip

In article <1991Feb14.150021.5723@unipalm.uucp>, leo@unipalm.uucp (E.J. Leoni-Smith) writes:
> ash@uupc.omega (Andrew Hardie) writes:
> 
>>I seem to remember some months ago talk about problems (dropped packets?)
>>with the A and B versions of the DP8390 chip as fitted to the WD8003E.
>>I notice that the new boards have the DP8390C chip. Can someone remind
>>me what the problem was and whether it (and any others that may have
>>existed in the A and/or B versions) were fixed in the C revision.
>>Thanks
>>-- 
 
>>Andrew Hardie                                       ash@omega.uucp
>>London, England                                ukc!cctal!omega!ash
> 
> Include me in your mailing lists too - Russ? James? 

The NSC 8390 has been through a lot of revisions...there were even some
released which were 'pre-A'. The B version has some problems with the 
internal statemachine on heavily loaded LANs. Exactly how the will manifest
itself will depend on the software. The worst problem is that collisions
may be lost due to a small 'blind' window. There are 3 main problems with the
B rev, one can be sorted out in software and the other two need a hardware
work around. Its fair to say that the last 2 problems shouldn't
happen it the LAN is TOTALLY perfect! I can post a full description of them
if you want? The C rev has no serious problems that I know of...we are using
both B and C revs. There is also a D rev which is supposed to be a die shrink
but is given the status of a rev 'cause DEC have'nt 'approved'it..or so the
story goes!

Geoff Peck
Physical Sciences Division
Information Technology Group
Department of Scientific and Industrial Research
New Zealand     +64-4-666-919 fax; +64-4-690-067

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 16:22:47 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP addressing & T1 channels


 > From tcp-ip-RELAY@NIC.DDN.MIL Fri Mar  1 10:21:04 1991
 > From: Bob Stine <0004219666@mcimail.com>
 > To: tcp-ip <tcp-ip@nic.ddn.mil>
 > Subject: IP addressing & T1 channels
 > 
 > A client of mine is developing a real-time, distributed system that will use the
 > TCP/IP protocol suite for control & monitoring.  A component in the system will
 > serve as a gateway between a LAN and a T1 link to (another gateway on) another
 > LAN.
 > 
 > In addition to control traffic, we will be performing down-line loads to
 > components on the distant LAN, sometihing like:
 > 
 > 
 >          LAN        T1           LAN
 > Server  ------ GW --------- GW --------- Destination 
 >                  1            2
 > 
 > Now, we don't want the bulk traffic to cause overly-long delays to the real-time
 > traffic.  The control traffic will all be on a single 56kbs channel of the T1,
 > framed in HDLC.  We were contemplating giving the down-line load traffic its own
 > channel, and using an application at GW2 to receive and distribute big files to
 > the destinations on the far LAN.
 > 
 > We will be writing our own device driver for the T1.
 > 
 > To me, a "natural" solution to this problem seems to be to use separate IP
 > addresses for the control and bulk-data channels.
 > 
 > Questions:
 > 
 > 1. Would this require separate drivers to get any performance improvements
 > (i.e., would a sinlge HDLC device driver become a bottleneck)?
 > 
 > 2. Is there a better approach?
 > 
 > 3. What are the hidden "gotchas"?
 > 
 > 4. Where could I look for more info?
 > 
 > Thanks,
 > 
 > Bob Stine
 > bstine@MCIMail.com
 > c_rstine@hns.com

Bob,

I suggest that you use type of service routing for
differentiating the traffic "streams". Do something
like assigning the download traffic "high throughput"
and the control traffic "low delay". It sounds like
you are building your own router/gateway box so
you can have it do the right thing. Differentiating
things by IP address would be "a bad thing". First,
IP addresses just identify an endpoint of the
communications -- they are not meant to identify
type of service. Second, what if you decide to 
change IP addresses?

You might want to take a look at things like the OSPF
spec and some of the Internet Drafts and RFCs on
things like policy routing and the like. 

Hope this helps
Frank Kastenholz
Clearpoint Research Corp.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 16:34:30 GMT
From:      guenther@irafs2.ira.uka.de (Guenther Schreiner)
To:        comp.protocols.tcp-ip
Subject:   Re: why UDP send ICMP port unreachable message?

In article <9103011243.AA10028@ucbvax.Berkeley.EDU>,
TAYBENGH@NUSDISCS.BITNET writes:
> Hi netlanders,
>         After reading thru the implementation of TCP/IP from
> the book The Design and Implementation of the 4.3BSD OS (published by
> Addison-Wesley) and the source code of BSD4.3 TCP/IP, I am puzzled of
> the purpose of ICMP Port Unreachable error message sent by UDP that appeared
> in the routine udp_input(). According to my understanding, this ICMP message
> is never received by UDP, nor is reported to the user if the user send a
> UDP message to a non-existent server (destination port). So why it is sent
> by the UDP? Did I misunderstand sth?

 Even if it sounds strange, it is possible to establish a UDP "connection".
 If you do so (with the system call connect() and I/O with send()/recvfrom()),
  the I/O system calls will return EADDRNOTAVAIL, ENETDOWN and ENETUNREACH
  after an appropriate incoming ICMP message.
 In opposite to this the I/O calls will NOT return an error if you use a loose
  UDP connection (with sendto() and recvfrom() calls without a connect()).

 Hope this helps,
  Guenther

--
 Guenther Schreiner			University of Karlsruhe, West Germany
  c/o Fakultaet fuer Informatik		Phone: (0721) 608-2749
  Am Fasanengarten 5			UUCP:  ...!seismo!unido!uka!guenther
  7500 Karlsruhe 1			CSNET: guenther@ira.uka.de
					EARN:  GUENTHER at DKAUNI0I
--

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 17:07:33 GMT
From:      jim@group1.uucp (Jim Haile)
To:        comp.protocols.tcp-ip
Subject:   MacTCP

We use MacTCP in an application that gets info from our Unix based 
database onto our Macs.  It works great now through Ethernet but we 
are contemplating adding a 56K line to a remote office and I am 
concerned about MacTCP.  Will it time out at this slower speed?  Has 
anyone tried this?  
Thanks, 
Jim

-- 
Jim Haile
Group One, Ltd.
uunet!group1!jim

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 18:15:15 GMT
From:      rstevens@noao.edu (Rich Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: why UDP send ICMP port unreachable message?

In article <9103011243.AA10028@ucbvax.Berkeley.EDU> TAYBENGH@NUSDISCS.BITNET writes:
> According to my understanding, this ICMP message
> is never received by UDP, nor is reported to the user if the user send a
> UDP message to a non-existent server (destination port).

UDP does indeed receive this message.  It's not documented well,
so you really need to go to the sources to see what's going on.
The publicly available "BSD Networking Release" suffices.

The sequence of events is:  icmp_input() receives the ICMP error.
The ICMP "type" is ICMP_UNREACH and the ICMP "code" is "port
unreachable".  This code is converted to PRC_UNREACH_PORT and
udp_ctlinput() is called to process the error.  udp_ctlinput()
calls in_pcbnotify(), converting the PRC_UNREACH_PORT error
into the ECONNREFUSED errno value, using the table inetctlerrmap[]
(in the file ip_input.c).  A 32-bit internet address is passed to
udp_ctlinput() and this address is passed again to in_pcbnotify().
This address is the address that the datagram was sent to that
generated the ICMP error.  The routine in_pcbnotify() is interesting
because it looks at this address and finds *every* socket that is
connect()ed to this address and sends those sockets the asynchronous
error ECONNREFUSED.

So there are three caveats: (1) you'll only know about the error if
you've done a connect(); (2) not only will you find out about the
error, but *every* process on your host that is UDP "connect()ed"
to the host that sends the ICMP port unreachable gets a ECONNREFUSED
error; (3) you usually don't find out about the error when you send()
the datagram to the port that no one is reading from, in most cases
you'll find out when you do a recv() on that socket (assuming the
classic send-a-datagram, receive-a-datagram scenario).

	Rich Stevens (rstevens@noao.edu)

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 19:55:08 GMT
From:      mab@mentor.cc.purdue.edu (Mike Brown)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Looking for network/protocol analyzer

I'm looking for a PC- and/or Unix-based (especially RS/6000 AIX)
network/protocol analysis software package that understands NFS/RPC/XDR
over TCP/UDP/IP on ethernet networks.  Understanding of other IP-family
protocols would be a real bonus, too.

I seem to recall a network posting in the last couple of months about
such a package that was available via anonymous ftp.  Naturally, I
can't find the posting now that I need the package (must not have saved
the article like I intended).  Can anyone provide pointers to this or
other packages with similar capabilities?

We already have and make extensive use of a Sniffer, so that's not the
recommendation I'm looking for here.  I'm looking for something I can
fire up in my office at random and sometimes extended intervals for
troubleshooting without having to take the Sniffer out of productive
use elsewhere.

Thanks in advance for any information you can provide.  If I get the
usual flood of "please let me know what you find out" replies, I'll
repost a short summary.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 20:16:28 GMT
From:      chris@vision.uucp (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Registering an "official" port name

Apologies in advance for my probable misuse of the word "port".  I hope you
will understand what I mean...

We would like to be able to register a known TCP/IP port number (as seen
in /etc/services on most implementations of TCP/IP that I've seen) for use by
one of our products.  We do not want to allow the system admin to choose (at
installation time) which port our product should use - we want to be able to
guarantee (ish) that port _number_ XYZ will have our client sitting on it.

Unfortunately we don't know who (or what) is responsible for the allocation and
registration of these ports.  Can someone point me in the right direction? If
not, has anyone got any useful suggestions, please?

Thanks in advance,
Chris
-- 
VISIONWARE LTD         | UK: chris@vision.uucp    JANET: chris%vision.uucp@ukc
57 Cardigan Lane       | US: chris@vware.mn.org   BANGNET: ...!ukc!vision!chris
LEEDS LS4 2LE, England | VOICE:  +44 532 788858   FAX:  +44 532 304676
-------------- "VisionWare:   The home of DOS/UNIX/X integration" -------------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 91 21:39:44 GMT
From:      mab@mentor.cc.purdue.edu (Mike Brown)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Looking for network/protocol analyzer

I'm looking for a PC- and/or Unix-based (especially RS/6000 AIX)
network/protocol analysis software package that understands NFS/RPC/XDR
over TCP/UDP/IP on ethernet networks.  Understanding of other IP-family
protocols would be a real bonus, too.

I seem to recall a network posting in the last couple of months about
such a package that was available via anonymous ftp.  Naturally, I
can't find the posting now that I need the package (must not have saved
the article like I intended).  Can anyone provide pointers to this or
other packages with similar capabilities?

We already have and make extensive use of a Sniffer, so that's not the
recommendation I'm looking for here.  I'm looking for something I can
fire up in my office at random and sometimes extended intervals for
troubleshooting without having to take the Sniffer out of productive
use elsewhere.

Thanks in advance for any information you can provide.  If I get the
usual flood of "please let me know what you find out" replies, I'll
repost a short summary.



Mike Brown, Network Systems Programmer		Internet: mab@cc.purdue.edu
Purdue University Computing Center		Bitnet:   xmab@purccvm
1408 ENAD, Room 130A				Phone:    (317) 494-1787
West Lafayette, IN 47907, USA			Fax:      (317) 494-0566

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 03:48:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   why UDP send ICMP port unreachable message?

Hi netlanders,
        After reading thru the implementation of TCP/IP from
the book The Design and Implementation of the 4.3BSD OS (published by
Addison-Wesley) and the source code of BSD4.3 TCP/IP, I am puzzled of
the purpose of ICMP Port Unreachable error message sent by UDP that appeared
in the routine udp_input(). According to my understanding, this ICMP message
is never received by UDP, nor is reported to the user if the user send a
UDP message to a non-existent server (destination port). So why it is sent
by the UDP? Did I misunderstand sth?
        Also did TCP use this message to inform the client when it tries to
initiate a connection to a non-existent server?
        Could somebody please explain this? Thanks a lot.

- Beng Hang (email: taybengh@nusdiscs.bitnet)
  Dept of Information Systems and Computer Science
  National University of Singapore

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 05:24:00 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: why UDP send ICMP port unreachable message?

In article <9103011243.AA10028@ucbvax.Berkeley.EDU> TAYBENGH@NUSDISCS.BITNET writes:
>I am puzzled of
>the purpose of ICMP Port Unreachable error message sent by UDP that appeared
>in the routine udp_input().

Others have already given adequate answers to this question (I am quite
disheartened if the assertion that the port unreachable message is sent to
all sockets connected to the host that sent the ICMP, i.e. that it doesn't
restrict it to sockets connected to the unreachable port).

>        Also did TCP use this message to inform the client when it tries to
>initiate a connection to a non-existent server?

TCP doesn't use ICMP Port Unreachable.  Instead, the remote host responds
to the SYN with a RST instead of a SYN.  UDP needs to use ICMP because
there is no built-in handshake in the protocol, whereas TCP uses a
handshake to establish a connection and can include the error report as
part of the handshake.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 12:41:59 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: Need a compact Ethernet driver for AT&T 7300

In article <1991Feb28.183714.12039@csusac.csus.edu> cs175111@csusac.ecs.csus.edu (Steven Little) writes:
>
> 	I am currently working on a project to connect an AT&T 7300
>to a host via an Ethernet cable.  The problem I'm having is that
>the ROM space in the 7300 is very small.  
>	What I need is a reduced tcp-ip or a tiny tcp-ip to handle
>this problem.  I thank anyone who can help me with my problem in advance.

I don't understand the reference to "small" ROM space; the system supports
up to 4MB (or 8MB) RAM and > 300MB HD; not bad for a circa-1985 10MHz 68010.

In any event, the AT&T 7300 is also known as the 3B1, and questions such as
this are best directed to comp.sys.3b1 where you'll get a LOT of help!  :-)

Ethernet exists for the 3B1 (I have many connected on my net) as does StarLAN.
The Ethernet is the WIN/3B TCP/IP 802.3a-1988 10BASE2 10Mbit/S, and the
StarLAN is 802.3e-1988 1BASE5 1Mbit/S over twisted-pair.

Several people, myself included, have ported portions of the 4.3BSD "Tahoe"
networking software suite to the 3B1/7300 and some of this can be found at
osu-cis (aka cheops.cis.ohio-state.edu [IP 128.146.8.62]) and (soon) in the
comp.sources.3b1 newsgroup.

I also have copies of the 3B1/7300 Device Driver Development Guide (from AT&T)
available at cost for anyone interested; either send email (see sig below) or
browse the comp.sys.3b1 newsgroup.

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

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 16:11:10 GMT
From:      Steven_Carmody@BROWN.EDU
To:        comp.protocols.tcp-ip
Subject:   sending data over citywide cable TV systems

We're currently talking to the local cable TV company about transmitting
data over the "institutional cable" they are required to operate
(interconnects schools, libraries, colleges, universities, hospitals, etc).
We have ten years of experience with a campus based broadband system, and
feel there is a reasonable possibility of success with the citywide cable.
Unfortunately, as soon as we said the word "data" the cable company heard
the words "common carrier", and routed our request to their legal dept.

I'd like to supply the lawyers with a list of communities which are already
doing what we're proposing. If you know of a community that's doing this,
please send me a note. thanks very much.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 18:58:31 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: why UDP send ICMP port unreachable message?

>The routine in_pcbnotify() is interesting because it looks at this
>address and finds *every* socket that is connect()ed to this address
>and sends those sockets the asynchronous error ECONNREFUSED.

The routine "in_pcbnotify()" is buggy.  It is *not* supposed to be doing
that.  It appears to be fixed in 4.3-reno and in SunOS 4.1, and may be
fixed in other systems as well.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 19:11:58 GMT
From:      efb@suned1.Nswses.Navy.MIL (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Digital phones for SLIP circuits

Confronted with an urgent need to run SLIP between two Sun3s (OS 4.1 and
4.1.1) and some easy to comeby telephone assets AND NO money for modems,
we are trying to pick the most trustworthy and easy to accomplish SLIP
link.  Sites are within 3 miles, wire, 1/2 mile crow flight.

- We have Meridian phones for which we can get 9600 baud RS-232 interfaces.
DOES ANYBODY know if with handshaking and async over digitized phone line,
these data phone options WORK SUCCESSFULLY for this purpose ?

- We have access to a four wire metallic circuit, not conditioned.  Is
there an economical, recent or old, technology four wire modem YOU USE to
support 9600 baud SLIP ?

- We have some available Telebit modems, no two alike and NO T2500.  Dont
think any are the newer of V32/V42 which ever that is.  The last neighbor we
knew using these a 200 mile dialup phone path spent lots of time restarting
the circuit.  Is there a good way to use these locally over an analog
delivered voice grade phone line ?

- How would YOU rate from YOUR PERSONAL experience these options, for cost
effectiveness and ease ( idiot-proof-ness ) of installation ?

- Remember in answering these questions, the right answer leads to the most
efficient use of tax dollars.  Thanks /Ev/

-- 
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 19:38:01 GMT
From:      cs175111@csusac.ecs.csus.edu (Steven Little)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domain
Subject:   Need 3b1 Ethernet driver



	I need a compact or tiny tcp/ip for the 3b1.  I'm trying to get
a Ethernet driver for an EPROM based system.  The 3b1's are being used to
teach operating systems.  The students are programing operating systems
and cross compilling them to a host computer.  The current method is to
use the RS-232 ports, this is an extremely slow process.  
	The problem is that I have a limited ROM space in which to place
the driver.  That is why I need the compact or tiny tcp/ip.

		Thank you in advance.

		send email to cs175111@csusac.ecs.csus.edu

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 21:35:49 GMT
From:      dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton")
To:        comp.protocols.tcp-ip
Subject:   Re: Underscores

> Hi,
>   I've been getting complaints about my SMTP rejecting mail from sites
> with a underscore in its host name. If I read RFC 821 correctly, names
> may consist of letters, digits, and hyphens. Has this been liberalized
> recently?
>   The site in question is: its_gate.cc.uow.edu.au
>
>                                  Thanks,
>                                    Jeff

RFC 821 and 822 weren't very clear on what characters a hostname could
contain.  RFC 952, "DOD Internet Host Table Specification" clarifies
what characters are legal.  The legal characters are letters, numbers,
and the hyphen, and the hostname must begin with a letter, and end with
a letter or digit.  The exact syntax is:

<hname> ::= <name>*("."<name>)
<name>  ::= <let>(*(let-or-digit-or-hyphen>)<let-or-digit>>

Note:  I used parentheses instead of square brackets (none on my
       terminal...)

Daniel

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

Daniel M. Barton
TCP/IP Development
IBM Research Triangle Park, NC

Internet:  dmbarton@ralvmm.vnet.ibm.com
           dmbarton%ralvmm@vnet.ibm.com

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 22:37:14 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re:  do FINs count as 1 like SYNs ?

>Hi!
>Sending a SYN advances the sequence number by one since it must be ACKed.
>A FIN is ACKed, too, so does it advanced the sequence number?
>I browsed through RFC761 but found nothing which tells me. :-(

Kai --
	RFC 791 (which updated 763) describes the closing sequence pretty
well and illustrates this case in Figure 13 (page 39).  The packet that ACKs
the FIN will have an ACK number one greater than the FIN's sequence number.
So, yes, the sequence number is incremented after the FIN is transmitted
(so that ACK will == snd.NXT).
	You may want to also get a copy of RFC-1122 (Requirements for Internet
hosts): this document clarifies a number of points in both the TCP and IP
protocol specifications that have been interpreted in different (and frequently
incompatible) ways.

				-- Frank Solensky / Clearpoint Research Corp.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 23:16:51 GMT
From:      oberman@amazon.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: UnderscoresDIR/NEW

In article <9103022255.AA04928@ucbvax.Berkeley.EDU>, dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton") writes:
> RFC 821 and 822 weren't very clear on what characters a hostname could
> contain.  RFC 952, "DOD Internet Host Table Specification" clarifies
> what characters are legal.  The legal characters are letters, numbers,
> and the hyphen, and the hostname must begin with a letter, and end with
> a letter or digit.  The exact syntax is:

This is out of date information RFC 1122 removes the prohibition of numeric
first characters in host names. Other than that, I know of no changes fron 952.
As far as I can tell, underscores remain a no-no.

That stated, they are quite common and most implementation will allow them. The
only problem is when you hit a system that doesn't. So, please follow the rules
and don't use them. I would also recommend against numeric first characters as
many implementation have not been changed since 1122/1123 were issued.

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

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 91 23:34:07 GMT
From:      braden@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Underscores

RFC-1123 (Section 2.1) points you to RFC-952, and then liberalizes the
syntax to allow "3COM.COM".

Bob Braden

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 91 05:05:53 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Underscores


underscores are found in some hostnames managed by merit on behalf of
the nsfnet, e.g. ann_arbor.mi.nss.nsf.net, 129.140.17.77.  until these
names are changed, it's hard to argue that underscores are illegal,
just ill-advised.

--Ed
emv@ox.com
please ignore the goofy From: line in the header.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 91 05:09:18 GMT
From:      dab@ASYLUM.SF.CA.US (Dave Bridgham)
To:        comp.protocols.tcp-ip
Subject:   Registering an "official" port name

If your application is using TCP (as it sounded from your message),
may I suggest reading RFC1078 (TCPMUX) for an alternative to using
a well known port.

					David Bridgham

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 91 12:01:01 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   3270 Telnet via satellite circuit problems

This past weekend we converted our 9.6kb terrestial link to a 64kb satellite
link.  I realize the inherent delays of a satellite link.  Everything worked
except for 3270 Telnet (VM to VM).  Linemode Telnet, FTP and SMTP worked
fine.  But when establishing a 3270 Telnet session, the user would have
his/her terminal cleared, and that would be it.  Sometimes the remote
status area (bottom right hand corner) would appear but never a remote
VM logo.

We run FAL V.1.2.1 with the BTI Ethernet gateway (Texas line driver) and
cisco AGS routers.  Any ideas?  Will V.1.2.2 solve this problem?

Thanks,
Hank

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 91 12:22:08 GMT
From:      efb@suned1.Nswses.Navy.MIL (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Re: NetCure and Packet Drivers

What are examples of the component _packed drivers_ upon which to load 
the many products such as NetCure, in this case .. does the .SYS file
that comes with Sun PC-NFS qualify, does some component of ka9q nos or
other public access product fill this need ?  e.g. for 3C503s ?  Thanks.


-- 
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 91 15:18:48 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   sending data over citywide cable TV systems

Could you let us have a synopsis of your replies concewrning other
sites who are doing this? We are interested in moving in a similar
direction in the future and would appreciate any info. thanks

*******************************************************************************
Snailmail: Gordon Byron,  Arts Computing Advisor,Pathfoot Building, 
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786 73171: Ext 7266  Fax: +78651335
*******************************************************************************

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 00:32:52 GMT
From:      VANCE@TGV.COM (Icarus)
To:        comp.protocols.tcp-ip
Subject:   Re: Underscores

>underscores are found in some hostnames managed by merit on behalf of
>the nsfnet, e.g. ann_arbor.mi.nss.nsf.net, 129.140.17.77.  until these
>names are changed, it's hard to argue that underscores are illegal,
>just ill-advised.

Doing something in broad daylight doesn't make it legal.  If we want to expand
the allowable characters in host names (which I think is quite reasonable),
then let's move on that.  RFC 1123 (Host Requirements) explicitly relaxes the
restriction of the first character in a host/domain name being a letter (now
allows numbers as well), but it does NOT add an underscore to the valid set of
characters.

Until a change is "officially" made, using underscores in hostnames is a
mistake, and can cause problems for some hosts.

Regards,
-----Stuart

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 02:02:24 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson DDN:(CDS6))
To:        comp.protocols.tcp-ip
Subject:   Serial line IP packages over a net


Helo out there in netland,

I am looking for a way to hook my system into an Internet feed in
another town.  The simplest method would be to hang a modem off of
both machines (mine an Amiga 3000UX and the other site a SparcStation
2) and run SLIP, PPP, or dialupip over a regular phone line between
us.  There are two problems with this, first the LD charges (same area
code, different local telcoms) and second the use of a valuable serial
port in the back of the SS2.

Another method of accessing the SS2 seems to clean up both of these
problems, but I am not sure if one of the serial line ip packages
would work over it, some have said that it would and others have said
that it wouldn't as part of the connection is itself packetized.

Here's the set up.  Let's say I am in city A and the SS2 is in city B.
There is a terminal server in city A that has modems hanging off of it
and can connect to the SS2 in city B over a DECnet or TCP-IP
connection (I am not sure which).  Here's the question, would any of
the serial line ip packages (SLIP, PPP, or dialupip) be able to run
over this kind of connection ([mybox]-[modem]-[modem]-[terminal
server]-[SS2])?  Has anybody done this or know if it could be done or
not?

On a related note, has anyone run one of the SLIP or like packages
over a connection facilitated by a pair of 2400 bps V42.bis (4 to 1
compression) modems (I know - SLOW, but they are cheap and what I have
available to me right now.)

Please respond via e-mail as I can not always read news.  I will share
any answers either via e-mail or, if volume dictates, I will post a
summary.

Thank's in advance,

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

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 04:05:15 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: NetCure and Packet Drivers

In article <8218@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey) writes:

   What are examples of the component _packed drivers_ upon which to load 
   the many products such as NetCure, in this case .. does the .SYS file
   that comes with Sun PC-NFS qualify, does some component of ka9q nos or
   other public access product fill this need ?  e.g. for 3C503s ?  Thanks.

"Packet drivers" are those bits of software (usually TSRs, but
sometimes actual MS-DOS device drivers) that comply with FTP
Software's Packet Driver Specification
</anonymous@vax.ftp.com:pub/packet-d.ascii>

A number of hardware manufacturers supply their own packet drivers.
Clarkson University also distributes a freely copyable collection of
packet drivers
</anonymous@sun.soe.clarkson.edu:pub/packet-drvers/driverss.zip> with
source, or
</anonymous@sun.soe.clarkson.edu:pub/packet-drvers/drivers.zip> without source.



--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 06:31:09 GMT
From:      jclark@sdcc6.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   RARP implimentations for BSD 4.3 tahoe/reno

The standard BSD 4.3 does not seem to have a 'rarpd' program
implimented. Is there a public version of the RARP protocol.

Please mail a reply to 

John Clark
jclark@ucsd.edu
-- 

John Clark
jclark@ucsd.edu

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 10:25:25 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Time schedule for next InterOP ?


Hi folks,

Does somebody know the date for the next InterOP (in San Jose?).
I'm just planning a private journey to the west coast, and want
to combine it with a visit of InterOP.

Sincerely,
Klaus Steinberger

--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
BITNET: K2@DGABLG5P             Internet: k2@bl.physik.tu-muenchen.de

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 12:46:11 GMT
From:      rstevens@noao.edu (Rich Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Time schedule for next InterOP ?


 7-11 October, 1991 (San Jose)
18-22 May, 1992 (Washington, DC - new Interop East)
26-30 October, 1992 (San Francisco - SJCC too small)

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 13:05:06 GMT
From:      gt3741b@prism.gatech.EDU (Kikai heno hanashite)
To:        comp.protocols.tcp-ip
Subject:   SLIP and Dial-up

I have a question about the "Dial-up Internet Protocol"..

namely, does it exist yet, was it ever a serious idea (or just
a joke), and if it's not there yet, and is serious.. how far
away is it?

John

-- 
   Emperors Thought for the Day:                |       John E. Rudd jr.
Only the insane have the strength to prosper;   |  gt3741b@prism.gatech.edu
   Only those who prosper judge what is sane.   |  (ex- kzin@ucscb.ucsc.edu)                                                    |     Speaker to Machines
#include<std.disclaim>  Send all comments, flames, and complaints to /dev/null.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 16:37:46 GMT
From:      jaynes@med.umich.edu (William Jaynes)
To:        comp.protocols.tcp-ip
Subject:   setting TCP/IP segment size



I've got Sun's running 4.1 and 4.1.1.  Is there anyway to configure the
maximum packet or segment size.  I'd like to limit it to 1024 but they
are negotiating for a size of 1460.  At 1460, my packets are getting
fragmented and under some circumstances this is a problem.  At 1024 I
can side-step this problem.  Any help?

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 16:48:00 GMT
From:      MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager")
To:        comp.protocols.tcp-ip
Subject:   routed problems on a SPARCstation

We are having trouble with routed on a SPARCstation I running SunOS 4.0.3. We
have the machine set up as a router between two different networks with two
different Ethernet cards. The cards seem to be configured correctly and the
machine passes packets between the networks just fine. However, the problem
comes in when routed trys to send a rip packet but it is getting a message that
says network not reachable. Right now we have another router advertising the
route for it, but we'd like to get it to advertise for itself.

The network numbers are 137.112.4.0 and 137.112.40.0 with a netmask of
255.255.252.0 and broadcast of 137.112.7.255.

Anyone else having these kinds of problems or have any suggestions?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jerrod t. carter, networking manager     |    my employer has no opinions
rose-hulman institute of technology      |
mgrjtc@rosevc.rose-hulman.edu            |    "may all your faults be soft."

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 17:33:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Use of SOCK_RAW to implement new transport protocol on top of IP?

Hi netlander,
        I would like to use SOCK_RAW provided in BSD socket to implement a new
transport protocol on top of IP. Regretably, the documentation of SOCK_RAW
usage is very scare, it is not clearly discussed in BSD documantation, nor the
two precious books - The design and implementation of 4.3BSD OS (published by
Addsion-Wesley), and Unix Network Programming (published by Prentice-Hall).
As such, I would like to sort for the net experience. The questions are:

        1) How one can associate a new protocol (that is not defined in in.h -
socket) to the socket? Specifically, how one can initialize the rcp_proto
field so as to filter packets on input, and also the rcb_pcb field so as to
attach the new protocol-specific information? (note: the rcb_* and raw socket
are discussed in 11.7 of the BSD4.3 book - pg 332)

        2) If one cannot filter out the packets on input using the above
method, then if I open a socket using protocol 0 (the default protocol - IP?),
does this socket receive all the packets including TCP, UDP, ICMP, and pure IP
packets? (in fact, I did an experiment on SunOS4.1, I found out the socket
receives only the ICMP packets, not even the pure IP packets, the program
segment are attached as follow, did I did sth wrong?, I also crashed the system
several times when I tried to send out IP packets, is this a bug or I did sth
wrong again?) Moreover, how to initialize the socket so that it can receive all
IP packets in order to extract the newly defined packets?

        3) In SunOS4.1, I opened a raw socket with protocol 0 to receive IP
packets using the attached program segment shown below, then when I used ping
(within same host) to ping itself, this program only receive the echo ICMP
messages, but NOT the request ICMP messages. On the other hand, if I ping from
other host to this particular host, the request ICMP messages are also NOT
received by this program. As such it seems that all ICMP request messages are
filtered out by IP layer and thus cannot be received by user process? Is that
true? Morevoer, if I used an connected UDP socket to send message to an
unreachable port within the same host, this program is also able receives the
port unreachable ICMP messages (type=3, code=3). Why is it so? I thought it
should EITHER receive ALL ICMP messages (including echo, request and etc), OR
it should not receive any ICMP messages at all.

        4) After looking thru the in.h, I found out there is a IPPROTO_RAW (255)
, should I use this instead of the default 0 in order to receive pure IP
packets? If not, what is the purpose of this protocol?

        Could somebody please solve/explain all these puzzles? I am desparated,
please help. Thanks a lot.

        ==> Here are the receiving part (in C), this part can receive ICMP
        message, BUT NOT the pure IP packets sent by the below program.

        int     sock, socklen;
        struct  sockaddr_in     local_in, remote_in;
        char    buf[1024], hostname[15], s1[10];
        u_short local_port, remote_port;

        sock = socket(AF_INET, SOCK_RAW, 0);
        if (sock <0)
        {
            perror("opening datagram socket");
            exit(1);
        }
        for (;;)
        {
           int  i;
           long *lp;

           socklen = sizeof(remote_in);
           /* read from the socket */
           if (recvfrom(sock, buf, 1024, 0, &remote_in, &socklen)
               < 0)
              perror("receiving datagram packets");
           lp = (long *)buf;
           printf("-->%s\n", buf);
           for (i=0; i<12; i++)
              printf("x%2.2x: x%8.8x\n", i*sizeof(long), *lp++);
        }
        close(sock);

        ===> Here are the sending part (in C), the receving part above never
         receive the message sent here, anything worng here? This segment
        also crashed the SunOS4.1 many times, error message saying the panic
        in m_copy, any clues?

        char    buf[BUFLEN], remote_host[40], str[40];
        int     local_port, remote_port, size;
        struct  sockaddr_in     local_sock, remote_sock;
        struct  hostent         *host;

        if ((id = socket(AF_INET, SOCK_RAW, 0)) < 0)
           syserr("main(): socket()")

        /* Get the messages and sendto */
        for (;;)
        {
           printf("\nPls input the messages:\n");
           gets(buf);
           if (buf[0] == '\n' || buf[0] == '\0')
              break;
           host = gethostbyname(remote_host);
           bcopy(host->h_addr, &remote_sock.sin_addr, host->h_length);
           remote_sock.sin_family = AF_INET;
           size = sendto(id, buf, sizeof(buf), 0,
                        (struct sockaddr *)&remote_sock, sizeof(remote_sock));
           if (size < 0)
              syserr("main(): sendto()")
        }

        Sorry for the lenghty posting, Thanks in advance for any help.

- Beng Hang (EMAIL: taybengh@nusdiscs.bitnet)
  Dept of Information Systems and Computer Science
  National University of Singapore

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 21:07:25 GMT
From:      kdb@macaw.intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP

In article <1991Mar01.170733.9543@group1.UUCP>, jim@group1.uucp (Jim Haile) 
writes:
> Path: intercon!uupsi!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!group1!jim
> From: jim@group1.uucp (Jim Haile)
> Newsgroups: comp.protocols.tcp-ip
> Subject: MacTCP
> Keywords: MacTCP
> Message-ID: <1991Mar01.170733.9543@group1.UUCP>
> Date: 1 Mar 91 17:07:33 GMT
> Sender: jim@group1.UUCP (Jim Haile)
> Organization: Group One, Ltd.; San Francisco
> Lines: 12
> 
> We use MacTCP in an application that gets info from our Unix based 
> database onto our Macs.  It works great now through Ethernet but we 
> are contemplating adding a 56K line to a remote office and I am 
> concerned about MacTCP.  Will it time out at this slower speed?  Has 
> anyone tried this?  
> Thanks, 
> Jim
> 
> -- 
> Jim Haile
> Group One, Ltd.
> uunet!group1!jim

From my understanding you should not have any problems.  I know there is a 
problem at 9600.  I do know that Apple is working on that problem, but we use 
our product out over the net at 56K without any problems.


Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 21:34:30 GMT
From:      ez@mentor.gandalf.ca (Eugene Zywicki)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   HSSI Standard??


 I am looking for information about a proposed standard that I believe
is called HSSI (High Speed Serial Interface). Can anyone elaborate
further on the background of HSSI, its place in internetworking, and
the standards body that is defining it?  
-- 
Eugene E. Zywicki          CAnet: ez@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 22:24:50 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Subnet Number 0


I see in RFC950 and the like that the subnet portion of the IP address
should not be zero, since it is reserved.  This seems to stem from the
concept of 0 meaning "this" network; presumably subnet "0" means
"this" subnet.  (i.e. if we have 128.1.0.0, with a 255.255.255.0 mask,
then an address of 128.1.0.x is illegal)

Is this still a real restriction on the address space?

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 91 23:01:27 GMT
From:      fillmore@emrcan
To:        comp.protocols.tcp-ip
Subject:   TCP/IP software for OS/2 ?

Has anyone made a list of available TCP/IP software packages that run under
OS/2 and which Ethernet boards they support?
I am aware of IBM's product but would like to know what else is available,
including public domain software.
Thanks in advance..

________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 14:28:31 GMT
From:      martin@udac.uu.se (Martin Wendel)
To:        comp.protocols.tcp-ip
Subject:   nntpxmit dumps core

I've just compiled and installed NNTP 1.5.8 on a SUN Sparcstation
running SUNOS-4.0.3. It seems like the server works allright but 
nntpxmit dumps core when trying to transmit news. I'm using inews
instead and it seems to be working ok.
Does anyone know which one is best, inews or nntpxmit, for posting
and relaying news?
By the way, I run cnews.

-- 
E-mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC
       Domainmaster@UU.SE                     Martin Wendel
       Postmaster@UDAC.UU.SE                  Box 2103
Tel: 018 - 18 77 80                           S-750 02 Uppsala

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 14:44:29 GMT
From:      jcurran@SH.CS.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and Dial-up

--------

> From: Kikai heno hanashite <prism!gt3741b@gatech.edu>
> Organization: Georgia Institute of Technology
> Subject: SLIP and Dial-up
> To: tcp-ip@nic.ddn.mil
 
> I have a question about the "Dial-up Internet Protocol"..
> 
> namely, does it exist yet, was it ever a serious idea (or just
> a joke), and if it's not there yet, and is serious.. how far
> away is it?

"Dialup IP" is real.  It is available via ftp from uunet.uu.net and
from bbn.com.  The software will automatically initiate SLIP connections
to remote hosts whenever packets are queued to the dialup IP interface. The
package includes a general (mmdf-like?) script language to negotiate and
establish connections.  There is a mailing list for discussion, send to  
"dialupip-request@sh.cs.net" for info.

Now the surreal part:  The software runs under BSD, Ultrix, and 3.x
SunOS.  It does not run under SunOS 4.x streams (yet).  

/John

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 16:13:28 GMT
From:      Deb_Kocsis@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Seminar Announcement


 
  /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
  *                                                                      *
  *  T h e   M e r i t   N e t w o r k i n g   S e m i n a r s           *
  *                                                                      *
  *                                                                      *
  *  M A K I N G  Y O U R  N S F N E T  C O N N E C T I O N   C O U N T  * 
  *                                                                      *
  *                                                                      *
  /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
 
 
  Merit/NSFNET Information Services is committed to providing
  current information on national networking to all users of the
  NSFNET backbone. Toward this end we will sponsor a two-day
  seminar in Ann Arbor, Michigan, May 20 and 21. "Making Your
  NSFNET Connection Count" will be an informative seminar
  focusing on issues of interest to campus computing leaders,
  information systems and networking administrators, educational
  liaisons, librarians, and educators who want to learn more
  about national networking.
 
 
  Day 1, "Real People Doing Real Things," will feature a number
  of presentations concerning network applications in education
  from the elementary grades through the college level. The Day 1
  activities will begin with a keynote address by Paul Evans
  Peters, Director, Coalition for Networked Information and will
  close with a tour of the Merit Network Operations Center.
 
  Day 2, "How to Get Connected and Stay Connected" will provide
  local, state, mid-level, and national networking perspectives
  from the experts. Day 2 will also be comprised of presentations
  on internetworking, information/user services, and network
  operations.
 
 
  The seminar will be held at the Tenneco Automotive Training and
  Development Center in Ann Arbor. Microcomputers connected to
  regional and national networks will be available on-site so
  that attendees may access network resources discussed in the
  presentations. The registration fee is $395. An early-bird fee
  of $345 will be charged for registrations received before April
  15, 1991. This fee includes the two-day seminar, a reception on
  Sunday evening, lunch on Monday and Tuesday, all seminar
  material, and an optional tour of the Network Operations
  Center.
 
  For further information send an electronic message to
  seminar@merit.edu or telephone 1-800-66-MERIT.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 16:21:06 GMT
From:      chrisv@CMC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   bandwidth usage for X applications?

Good morning all,
I tried posting the following question to the X windows interest group but 
received NO responses. So I'm going to give it a go here on TCP, since most
of you ARE concerned with bandwidth usage for applications, etc.
QUESTION - Does anyone have a feel for rough bandwidth usage for some of the
"typical" (if there is such a thing) X client applications? Has anyone run any
benchmarks which included X sessions across the net? It can't be too difficult
to fill up an Ethernet VERY quickly running clients to a few servers doing CAD
or something.
If you have some applications that can eat up an Ethernet let me know, we're
actively looking for good app's to highlight the need for FDDI at Interop this
year. Many thanks,
Chris VandenBerg
CMC A Rockwell Co.
chrisv@cmc.com          805-562-3127

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 18:12:17 GMT
From:      jonson@SERVER.AF.MIL (Lt. Matt Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet Number 0

<Erik J. Murrey writes>
> Subject: Subnet Number 0
> Message-Id: <1423@nocsun.NOC.Vitalink.COM>
> 
> I see in RFC950 and the like that the subnet portion of the IP address
> should not be zero, since it is reserved.  This seems to stem from the
> concept of 0 meaning "this" network; presumably subnet "0" means
> "this" subnet.  (i.e. if we have 128.1.0.0, with a 255.255.255.0 mask,
> then an address of 128.1.0.x is illegal)
> 
Absolutely.  Take a look at RFC 1122, section 3.2.1.3.  There are some
caveats for using such addresses in IP address discovery routines.

/matt

-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 18:28:35 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Time server (Internet-style); anyone got freely distributable source?

UNIX Review, Vol 8 No 12 says, in the Daemons and Dragons column, that RFC
1129 covers Network Time Protocols.  The article describes the time service
reasonably clearly, I think.  According to the author, he/they use xntpd
"written by Dennis Ferguson at the University of Toronto."  "To obtain the
xntp implementation of the NTP protocol, use anonymous ftp to louie.udel.edu
and look in the directory ~ftp/pub/ntp/xntp.  The distribution consists of 
a 49 KB compressed tar archive.  The distribution takes approximately 10
minutes to build on a Sparcstation 1." [typos, if any, are mine]

Author of the article was Rob Kolstad, who acknowledges help from Jeff Polk.

Mark

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 18:30:19 GMT
From:      jonson@SERVER.AF.MIL (Lt. Matt Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for mil spec archive

<J B Systems writes>
> 
> I have received a spec which references MS 1777 (IP) and MS 1778 (TCP).
> I have the rfc's to tcp and ip, but where can I find an archive for the
> mil standards?  Any help would be welcome.
> 
The Mil-Stds can be gotten as publication NIC 5004 - "DDN Protocol Handbook,
Vol 1"  from DDN Network Information Center, SRI International, Menlo Park,
CA, 94025.  It was put together in 1985.

They can also be requested from the Naval Publications and Forms Center (NPFC)
(individually, by name) which is :
Naval Publications and Forms Center
Code 3015
5801 Tabor Drive
Philadelphia, PA 19120
The Mil-Stds in question date back to 1983.

I know that there are still military acquisitions that reference those
particular specs, but to be really interoperable, vendors should be referencing
RFC 1122 & RFC 1123 and using them as their criteria.  Any military acquisition
authority that doesn't invoke 1122 & 1123 is seriously behind the times.
Some people still come up with their specs in a virtual vacuum, however...

The catch-22 disclaimer of course:
The opinions above are my own and do not represent official views of the U.S.
Government.

(maybe the opinions are catching on... :-)
/matt
-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 18:48:42 GMT
From:      tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi)
To:        comp.protocols.tcp-ip
Subject:   mac to mac ftp with NCSA Telnet 2.3?


 I posted this question to  telnet@ncsa.uiuc.edu on 1/22, but apparently
 that is a dead list, I didn't receive any replies.

 Does Mac NCSA Telnet support mac to mac ftps directly?  I don't want
 to sign onto a mainframe/mini to ftp stuff between two macs.  I 
 thought ncsa telnet 2.3 had this feature, but I don't see it
 documented.

 JoAnn

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 19:32:23 GMT
From:      jclark@sdcc6.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: CWRU student prevented from teaching how to send ethernet packets

In article <1991Feb27.144731.23147@usenet.ins.cwru.edu> cjs@po.CWRU.Edu (Christopher J. Seline) writes:
+
+I wrote a program that puts packets on ethernet and takes responce packets 
+off; the idea that my (or any) program could be modified to send n+1 packets
+(swamping our 100M FDDI fiber backbone) scared them; my program didn't do 
+that -- but it (And any other program) could be modified to do so.

What is so special about such a program. Most intro texts on tcp
inplementation have examples of this. Clearly just writing a piece
of code which talks to various 'echo' services could do the
'swamping'. Big deal.

Of course if you have a way to bring down the net maybe you should
post an article stating the hole in argument that says access to the
net will resonably likely for all users.
-- 

John Clark
jclark@ucsd.edu

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 20:39:32 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   DS8390 chip problems

Message posted to net in case strange NZ mail address doesn't work!

Geoff Pack, DSIR, New Zealand

Yes, please to the details on the problems with the B version of the
DS8390 chip. Thanks.

Email to ash@omega.uucp or ...!ukc!cctal!andrew, whichever is easier.
Will acknowledge receipt.

If anyone else on list is interested, please contact me and I will pass
it on or post it to the net, depending on interest.

Andrew
-- 

+----------------------------------------------------------------------------+
|  Andrew Hardie                                             ash@omega.uucp  |
|  London, England                                      ukc!cctal!omega!ash  |
+----------------------------------------------------------------------------+

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 22:19:14 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial line IP packages over a net


Well here is the followup I said I would post.  It seems that, using a
"plain, no frills" terminal server, you are out of luck, however there
are terminal servers that do support SLIP (some even support PPP).
With these servers, you connect to the server as a regular session and
then do the commands to start SLIP (something like "set terminal
internet slip enable") and go back and start your SLIP connection
without dropping the line.

With these servers (Xyplex, Cisco, and some others) you do not even
need to continue your SLIP link to a "gateway" machine.  The server,
in fact, acts like a slow router.  Once you are SLIP'd to the terminal
server, that is on the desired network, you are connected and
_shuldn't_ need to do anything else then set up some nameservers if
needed.

There has been concern expressed about running a SLIP connection with
a lot of high-density trafic over a terminal server as possibly being
detrimental to throughput for other users.  My application will be a
very low density connection, however.

Any more comments or questions are wlcome.

Thank's again,

	-Chris

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

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 91 23:39:10 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial line IP packages over a net


    Here's the set up.  Let's say I am in city A and the SS2 is in city B.
    There is a terminal server in city A that has modems hanging off of it
    and can connect to the SS2 in city B over a DECnet or TCP-IP
    connection (I am not sure which).  Here's the question, would any of
    the serial line ip packages (SLIP, PPP, or dialupip) be able to run
    over this kind of connection ([mybox]-[modem]-[modem]-[terminal
    server]-[SS2])?

A good number of todays terminal servers support SLIP directly.  Some
even support PPP.  This would solve your problem more convieniently.

Bill Westfield
cisco Systems.
-------

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 00:09:34 GMT
From:      steve@edm.isac.CA (Steve Hole)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   POP2/3, IMAP2/3

This is almost certainly an FAQ, but I have yet to see a collection of
definitive answers posted to either of these groups.   What I would like
is information on the following items:

 * POP2/3 server for UNIX, clients for UNIX and DOS.
 * IMAP2/3 server for UNIX, clients for UNIX and DOS.

I don't really care too much about the flavor of UNIX or of the DOS
TCP/IP libraries that it is implemented for, as I can probably muddle
through that if I have too.  Summary information on the software and a
list of ftp sites would be appreciated for each.  I will be happy to
post a summary back to the group for those who wish it.

-- 
Steve Hole  		         mail: steve@edm.isac.ca
ISA Corp.			 uucp: !{uunet, alberta}!ncc!isagate!steve
Edmonton, Alberta, Canada       phone: (403) 441-4121 

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 01:41:02 GMT
From:      keith@ca.excelan.com (Keith Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Need: Enhanced FTP

The News Manager)
Nntp-Posting-Host: ca
Reply-To: keith@ca.excelan.com (Keith Brown)
Organization: Novell, Inc. San Jose, California
References: <867@nddsun1.sps.mot.com>
Date: Thu, 28 Feb 1991 23:19:18 GMT

In article <867@nddsun1.sps.mot.com> wied@birdie.sps.mot.com (Bill Wied) writes:
>I'm looking for an enhanced version of FTP which will create virtual connections between hosts that are not directly connected, possibly using routing table information on in between hosts.
>
FTP clients should never find themselves in a configuration where they have
to worry about such matters. Interhost routing is the job of IP which
sits a few layers below FTP. When an FTP client wishes to connect to a host
that is not directly on its own IP network, IP will carry it's connection
request across an IP internet to the IP network on which the remote host
lives (on a good day).

>The control connection probably needs to be some virtual pipe but the data connection can either create a virtual connection or use some kind of store and forward mechanism to route it's data to the desired host.
>

The only example of data and control connection "juggling" that I'm aware
of is in FTP clients that support what I'm in the habit of calling "third
party copies". The idea is that you can sit at Machine A and use FTP to
transfer a file from Machine B to Machine C without the data ever darkening
Machine As doorstep. We support this in both our Windows 3.0 based FTP
client and also our non-Windows FTP client in the LAN Workplace for DOS.
I'm not sure if FTP softwares client can do this too but it wouldn't
surprise me (2.04 couldn't, right James?). Also, the University of Marylands
TCP/IP implementation looks pretty complete, so perhaps that can do it too?

Keith
-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 01:41:31 GMT
From:      brian@na.excelan.com (Brian Meek)
To:        comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: Looking for OS/2 TCP/IP products with RFC 1001/1002

The News Manager)
Nntp-Posting-Host: na
Reply-To: brian@novell.com (Brian Meek)
Organization: Novell, Inc. - San Jose, California
References: <4432@se-sd.SanDiego.NCR.COM> <1331@vaxeline.COM>
Date: Sat, 2 Mar 1991 08:44:57 GMT

In article <1331@vaxeline.COM> backman@vaxeline.ftp.com.UUCP (Larry Backman) writes:
[...]
>FTP Software V1.1 (in beta right now) supports RFC 1001/2 NETBIOS
>3Com's 3+TCP for LAN Mgr supports RFC 1001/2 Netbios.  It has been
>shipping for a while.
>IBM TCP/IP for OS/2 V1.1 does not to my knowledge support Netbios.
>Ungermann-Bass is rumored to have an OS/2 TCP Netbios.  I have not seen it.
>Excelan (now Novell) once shipped LAN Workplace for OS/2 w/ TCP & Netbios.
>I have no idea if it still is shipping.

The LAN WorkPlace for OS/2 is no more dead than OS/2 itself... hmmm.

Version 2.0 of LWP for OS/2 is a remnant of our LAN Manager developments
before we started focusing on NetWare and merged with Novell.  The next
release of the product (v3.0) is nearly ready for BETA testing and includes 
a redesigned TCP/IP module.  

The v3.0 release works in conjunction with the NetWare Resquestor for 
OS/2 using a single adapter.  Ethernet, Token-Ring and ARCNET cards with 
ODI for OS/2 drivers can be used.  RFC-NETBIOS is there, so are all of the 
basic service applications and a good BSD 4.3 Socket Library.

Those interested in BETA testing should send a note to me describing your
need for TCP/IP on OS/2 (Toolkit or end-user, for example...) and be sure
to include a mailing address and a FAX number.  

PS - the recently announced LWP for DOS is not available for BETA testing
     as it will be shipping in April.

-- brian
____________________________________________________________________________
         Brian Meek       Novell, Inc. - 2180 Fortune Dr. San Jose, CA 95131
Internet Mail: brian@novell.COM                        Phone: (408) 473-8375

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 01:43:27 GMT
From:      stu@gtisqr.uucp (Stu Donaldson)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Help with Anonymous FTP

In article <1991Feb21.211534.772@ulkyvx.bitnet> rwmira01@ulkyvx.bitnet (Rob Miracle) writes:
>"If the username is "anonymous" or "ftp" and an "anonymous" account is present
>if /etc/passwd, the user is allowed to log in by specifying any password.  Since
>anyone can log in under "anonymous," it is wise to restrict the access
>privileges of this account."

I used the account 'ftp' since it wouldn't have the problem.  With
this, both 'anonymous' and 'ftp' work as logins.

>anonymous account and add an account called ftp.  Now I can log in, but any
>access other than CD barfs with a message:
>
>PORT 136,165,2,12,8,17
>200 PORT command okay
>NLST
>425 Data Socket not created [0.0.0.0,0]

I had the same problem.  It doesn't tell you that there are a few
other files thatyou need to have in the ~ftp account.

~ftp/bin
	ls	needed for the NLST or LIST commands in ftp to work.
	pwd	needed to get the current working directory

~ftp/dev
	null
	tcp	# needed so the socket call within ftp can work.
	udp	# probably not needed, but I added it when I added tcp
~ftp/etc
	group	# needed for group id to show up in the dir command.
	passwd	# needed for login id to show up in the dir commadn.

~ftp/shlib
	libc_s	# surprise, /bin/ls uses the shared library so this 
		# is requried.
shlib:
total 54
-rwxr-xr-x   1 root     other      26236 Feb 27 10:47 libc_s*

>Problem #2  It seems that the CD command can get anywhere on the system.  How
>do I restrict it to just the tree that I want it in?

ftpd will automatically do a chroot to the new directory, thus
preventing you from using CD to get to directories above ~ftp.

>Thanks in Advance
>Rob 
>-- 
>Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
>Programmer/Analyst-II    | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
>University of Louisville | UUCP     : ...psuvax1!ulkyvx.bitnet!rwmira01
>"Revenge is a dish best served cold.  It is very cold in space" 
>       -- Ancient Klingon Proverb

-----------------------------------------------------------------------
Stu Donaldson                   "Can't you understand what I'm saying?" 
stu@mav.com                     "What did you do, fail telepathy?" 

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 01:46:09 GMT
From:      stu@gtisqr.uucp (Stu Donaldson)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Help with Anonymous FTP

In article <1991Feb21.211534.772@ulkyvx.bitnet> rwmira01@ulkyvx.bitnet (Rob Miracle) writes:
>Problem #1, AT&T SVR3.2.2 only allows 8 character file names, thus "anonymous"
>can not be created.  By hand editing /etc/passwd and /etc/shadow, I added the
>account as:   anonymous:x:1000:100:FTP Anonymous Account:

I used the account 'ftp' since it wouldn't have the problem.  With
this, both 'anonymous' and 'ftp' work as logins.

>anonymous account and add an account called ftp.  Now I can log in, but any
>access other than CD barfs with a message:
>
>PORT 136,165,2,12,8,17
>200 PORT command okay
>NLST
>425 Data Socket not created [0.0.0.0,0]

I had the same problem.  It doesn't tell you that there are a few
other files thatyou need to have in the ~ftp account.

~ftp/bin
	ls	needed for the NLST or LIST commands in ftp to work.
	pwd	needed to get the current working directory

~ftp/dev
	null
	tcp	# needed so the socket call within ftp can work.
	udp	# probably not needed, but I added it when I added tcp
~ftp/etc
	group	# needed for group id to show up in the dir command.
	passwd	# needed for login id to show up in the dir commadn.

~ftp/shlib
	libc_s	# surprise, /bin/ls uses the shared library so this 
		# is requried.
shlib:
total 54
-rwxr-xr-x   1 root     other      26236 Feb 27 10:47 libc_s*

>Problem #2  It seems that the CD command can get anywhere on the system.  How
>do I restrict it to just the tree that I want it in?

ftpd will automatically do a chroot to the new directory, thus
preventing you from using CD to get to directories above ~ftp.

>Thanks in Advance
>Rob 
>-- 
>Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
>Programmer/Analyst-II    | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
>University of Louisville | UUCP     : ...psuvax1!ulkyvx.bitnet!rwmira01
>"Revenge is a dish best served cold.  It is very cold in space" 
>       -- Ancient Klingon Proverb

-----------------------------------------------------------------------
Stu Donaldson                   "Can't you understand what I'm saying?" 
stu@mav.com                     "What did you do, fail telepathy?" 

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 01:48:41 GMT
From:      stu@gtisqr.uucp (Stu Donaldson)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Help with Anonymous FTP

In article <1991Feb21.211534.772@ulkyvx.bitnet> rwmira01@ulkyvx.bitnet (Rob Miracle) writes:
>Problem #1, AT&T SVR3.2.2 only allows 8 character file names, thus "anonymous"
>can not be created.  By hand editing /etc/passwd and /etc/shadow, I added the
>account as:   anonymous:x:1000:100:FTP Anonymous Account:

I used the account 'ftp' since it wouldn't have the problem.  With
this, both 'anonymous' and 'ftp' work as logins.

>anonymous account and add an account called ftp.  Now I can log in, but any
>access other than CD barfs with a message:
>
>PORT 136,165,2,12,8,17
>200 PORT command okay
>NLST
>425 Data Socket not created [0.0.0.0,0]

I had the same problem.  It doesn't tell you that there are a few
other files thatyou need to have in the ~ftp account.  This is
for Interactive Systems 2.0.2, your mileage may vary.

~ftp/bin
	ls	needed for the NLST or LIST commands in ftp to work.
	pwd	needed to get the current working directory

~ftp/dev
	null	# may not be needed, but I added it while trying to fix
		# the problem.
	tcp	# needed so the socket call within ftp can work.
	udp	# probably not needed, but I added it when I added tcp

	Note that these files in the ~ftp/dev directory will need to
	be actual devices.  Therefore, you will need to either link
	to the real /dev/* files, or use mknod to create them.

~ftp/etc
	group	# needed for group id to show up in the dir command.
	passwd	# needed for login id to show up in the dir commadn.

~ftp/shlib
	libc_s	# surprise, /bin/ls uses the shared library so this 
		# is requried.

>Problem #2  It seems that the CD command can get anywhere on the system.  How
>do I restrict it to just the tree that I want it in?

ftpd will automatically do a chroot to the new directory, thus
preventing you from using CD to get to directories above ~ftp.

>Thanks in Advance
>Rob 
>-- 
>Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
>Programmer/Analyst-II    | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
>University of Louisville | UUCP     : ...psuvax1!ulkyvx.bitnet!rwmira01
>"Revenge is a dish best served cold.  It is very cold in space" 
>       -- Ancient Klingon Proverb

-----------------------------------------------------------------------
Stu Donaldson                   "Can't you understand what I'm saying?" 
stu@mav.com                     "What did you do, fail telepathy?" 

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 01:54:35 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for mil spec archive

Matt:

> <J B Systems writes>
 
> > I have received a spec which references MS 1777 (IP) and MS 1778 (TCP).
> > I have the rfc's to tcp and ip, but where can I find an archive for the
> > mil standards?  Any help would be welcome.
 
> I know that there are still military acquisitions that reference those
> particular specs, but to be really interoperable, vendors should be referencing
> RFC 1122 & RFC 1123 and using them as their criteria.  Any military acquisition
> authority that doesn't invoke 1122 & 1123 is seriously behind the times.
> Some people still come up with their specs in a virtual vacuum, however...

...now what was the name of that Gunter AFB program--had something to do
with LANs, PCs, etc.--it was supposed to become the Air Force standard based
on MIL-STD-1777 and MIL-STD-1778 ? ;-)

Some of the newer RFPs still contain references to the MIL-STDs but suggest
that the vendor read them, primarily, for hysterical reasons.

Merton

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 04:54:18 GMT
From:      bvj@ESD.3Com.COM (B.V. Jagadeesh)
To:        comp.protocols.tcp-ip
Subject:   Silicon Vallaey Networking Conference - Advance Program



Hi -
	The Technical Committee of SVNC - 91 ( Silicon Valley Networking
	conference ) has put together an excellent technical program
	with papers from Universities from USA and Europe, Leading Networking
	companies and Research Institutes from different parts of the
	world. A preliminary conference program is attached for your 
	reference.

	SVNC also offers one day tutorial on FDDI and X- Motif

	SVNC-91 aims to cover technical papers in the following areas

	1. Internetworking
	2. High Speed Networking
	3. X - Windows
	4. Network Management
	5. Distributed Systems
	6. Physical layer 
	7. Networking Applications
	8. Network Test Equipments

	If you have any questions about this conference please
	do not hesitate to contact me.

	The conference will be held from April 23rd - 25th at Santa Clara
	Convention Center, Santa Clara, CA - 95052

	Registration form is attached at the end of this mail which can
	be used for registering in the conference.

Thanks
/B.V. Jagadeesh
Chairman - Technical Committee
bvj@ESD.3Com.com
(408)-764-5169
 

            Silicon Valley Networking Conference 1991 -  Advance Program 
	    ------------------------------------------------------------

	    Conference Dates: April 23rd to 25th 1991
	    Place           : Santa-Clara Convention Center, 
                              Santa-Clara, CA - 95052
			      USA.

DAY 1    April 23, 1991  TUTORIALS

----------------------------------------------------------------------
              |          Track  1         |         Track 2
----------------------------------------------------------------------
8:30 AM       |  Introduction to X-Motif  |  Introduction to FDDI
  to          |  Richard Lasslo           |  Mark Wolter
5:00 PM       |  Hewlett Packard Company  |  National Semiconductor
----------------------------------------------------------------------
12:00 NOON      Lunch Break

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

*******************************************************************************

DAY 2    April 24, 1991 TECHNICAL PAPER TRACKS

---------------------------------------------------------------------
KEYNOTE SPEAKER:   Current and future trends in network management.    
		   Keith McCloghrie,  Hughes LAN Systems  8:30 - 9:00

---------------------------------------------------------------------
Track 1                              |  Track 2
---------------------------------------------------------------------
   Session: NETWORK MANAGEMENT       |  Session: PHYSICAL LAYER - I
---------------------------------------------------------------------
1. John Pickens, 3COM                |  1. Dave Wong, Level One Comm
   Open Management Architecture      |     Understanding Twisted Pair
   Making network management         |     Ethernet
   manageable.                       |
                                     |
2. Arminius Mignea, Hughes LAN Systems|  2. William.V.Ringer, Intel
   A methodology for configuring     |     Notebook PC Network
   large networking.                 |     Interface card.
                                     |
3. Joe Grim,    Hewlett Packard      |  3. Peter Sun, PLX
   The SNMP protocol                 |    A non-buffered architecture
                                     |    for Ethernet LAN
                                     |    controllers.
				     |  
				     |  4. Paul Singh, Intellicom
				     |     10Base/T based Ethernet Networks
----------------------------------------------------------------------
                   COFFEE BREAK + Discussion with Speakers
----------------------------------------------------------------------

Session: INTERNETWORKING             | Session: Physical Layer - II
                                     |
4. Kai Jacobs, Tech. Univ. of Aachen |  5. Mike Seibert, MICRON
   Point to multipoint communication.|     Use of triple port DRAM for
                                     |     smart/faster network app.
                                     |
5. Joachim Carlo, Clearpoint         |  6. Greg Wolfson, Intel
   Analysis of the effects of high   |     LAN connection for
   speed bridges on network          |     advanced controller micro
   performance                       |     controller platform.

6. Brian Lloyd, Telebit              |  7. Donna Weaver, Standard
                                     |     Microsystems Corp.
   IP routing over public switched   |
   networks.                         |     Advanced silicon for the
                                     |     networking of controller
7  Vinod Bhardwaj, Kalpana Inc.      |     based systems.
   Parallel Networking               |     
                                     |     
----------------------------------------------------------------------
                               LUNCH + Exhibits
----------------------------------------------------------------------
Session: X-Window                    |  Session: NETWORK TEST EQUIPMENT
                                     |
8. V.R. Ranganath and                |  8. Jay Weill, Network General
   Phil Bourkekas                    |     Network troubleshooting
   RISC Controllers - An Architecture|     analysis and trends and
   well suited for X - Windows       |     issues.
                                     |
9. Dale Luck, Gfx Base Inc.          |  9. Jay Seaton, Spider Sys.
   X Window System for Amiga Computer|     Monitoring and Managing
                                     |     LANs.
                                     |
10. Jim Fulton, NCD                  |  10. Daniel Bougher, Tektronix
   Making fonts more manageable.     |     LAN Map Local Area Network
                                     |     conduit troubleshooting.
----------------------------------------------------------------------
                   COFFEE BREAK + Discussion with Speakers
---------------------------------------------------------------------
Session: X-Window                    |  Session: HIGHSPEED NETWORKING
                                     |
11. Mark Brown, GRAPHON              |  11. Yigal Jacoby, Tekelec
    Advantages of an advanced X-Term |      FDDI Network testing.
    design.                          |
                                     |
12. Kevin Herbert, CISCO             |  12. Sanjay Dhavan, AMD
    X-remote and terminal server     |      FDDI Interoperability
    solutions to needing an X-window.|      testing.
                                     |
13. Panel Discussion                 |  13. Sonu Mirchandani, Business
                                     |      Networks Group
                                     |      Performance Isuues in FDDI
                                     |      LANs
				     |
				     |  14. My T Le, Plus Logic.
				     | 	    FDDI - Traffic Controller
----------------------------------------------------------------------


DAY 3    April 25, 1991 TECHNICAL PAPER TRACKS

----------------------------------------------------------------------
KEYNOTE SPEAKER:  Bruce Nelson, Auspex Systems  8:30 - 9:00
----------------------------------------------------------------------
Track 1                              |  Track 2
----------------------------------------------------------------------
Session: Highspeed Networking        | Session: Distributed Systems
                                     |
14. George Marshall, Adaptive        | 15. Jeff Eppinger, Transarc
                                     |     Corp
   Impact of telecommunications and  |     Transactional remote
   highspeed networking.             |     procedure calls.
                                     |
15. Jaffar Rehman, U of Penn         | 16. S. Gopisetty
   Using detailed traffic            |    Santa Clara University
   statistics for more effective     |    A client-Agent-Server Model
   wideband multiplexing.            |    for Distributed Processing
                                     |    environment
                                     |
16. Alan Taffel, US Sprint           | 17. Peter Taid, Peer Logic
   Frame Relay an overview of        |    Peer-to-peer computing for
   networking technology.            |    distributed environment.
                                     |
17. Tom Dugan, Vitesse Semiconductor | 
    Sonet on Silicon                 |

----------------------------------------------------------------------
                            BREAK 10:35 - 11:15 AM
----------------------------------------------------------------------
Session: Highspeed Networking        | Session: Distributed Systems
                                     |
18. Brian Button, Stratacom          | 18. Michel Besson, Cerics
   Frame Relay its concepts and      |    A protocol for interactive
   implications                      |     remote programming in
                                     |     heterogenous implementation
                                     |     and performance.
                                     |

19. Raj Pari, National Semiconductor | 19. Harold Rabie, Echelon
   ISDN Basic access components and  |     Distributed Processing using
   design of ISDN peripherals.       |     Local Operating Network
                                     |
20. Tom Russel,   Ultranet           | 20. OSF Distributed Management
    System Issues in Gigabit/s       |     Environment
    Networking                       |     David Schwab - Hewlett Packaret 

----------------------------------------------------------------------
                            LUNCH 12:05 - 2:00PM
----------------------------------------------------------------------
Session: Internetworking II           | Session: Physical Layer II
                                      |
21. Karen Parker, National Semi       | 21. Ed D'Souza, National Semi
   Designing and Ethernet for FDDI    |    Parallel architecture for
   router.                            |    maximized throughput in
                                      |    star-wired topologies.
                                      |
22. R. Spurk, Dept. of Computer       | 22. Daniel Pettengil, Intel
   Science, Univ. of Saarbruken       |     Bus mastering for LAN
   Router support for multicasting in |     adapters.
   multicomputer interconnection      |
   network.                           |
                                      |
23. Jim Forster, Cisco Systems        | 23. Mike Yep, National Semi
   Comparison of metrics in todays    |    Design of FDDI concentrator
   routing protocols.                 |
                                      |
24. Milo Medin,  NASA                 | 24. Dick Allen, Photonics
    OSPF Routing protocol             |     Non-cable connectivity
                                      |     alternatives in design
                                      |     and implementation of
                                      |     networks.
----------------------------------------------------------------------
                          BREAK   3:15 - 3:45 PM
----------------------------------------------------------------------
Session: Network Management II         | Session: Network Applications
                                       |
                                       | 25. Paul Flaherty, Stanford University
				       |     A Fast Open Systems Interconnection
				       |     Protocol System
				       |
25. Bob Stewart, Xyplex                | 26. Manoj Goel, Novell
    Development and integration of MIB |     Integration of electronic
                                       |     mail messages.
                                       |
26. Fred Baker, ACC                    | 27. T. Casey, Dept. of CS
    SNMP experimental bridge MIB       |     Univ. College of LONDON
    development.                       |     U.K.
                                       |     A Hybrid network image
                                       |     server.
                                       |
27. Larry Lace, Network Research       | 28. Bala Parasuram, Syscom
    Heterogenous networking            |     Fascimile outsource a
    considerations when using SNMP     |     resource saving
    agents and network management      |     alternatives to
    devices.                           |     in-house.
                                       |
28. Tin Phan & Dean K. Endo, Touch Comm| 29. Bob Jacobson, U of
    An object oriented agent           |     Washington
    architecture                       |     Virtual world paradigm
                                       |     and televirtuality
                                       |     implications for network
                                       |     design capabilities.
                                       |
29. Jochen Seitz, Institute of Tele -  | 30. Norm Schneidwind, Navel
    matics, Univ of Karlaruhe, FRG     |     PG School
    An architecture for an Expert      |     Issues in allocating
    system Aiding in Network Planning  |     servers and files in LAN.
    and Network Management             |
				       | 31. Daniel PattenGill
				       |     Banyan Systems Inc
				       |     Directory Services and Street Talk
 ---------------------------------------------------------------------

A three Day package is $295 and a two day package is $245. 

For more info on registration please call B.V. Jagadeesh at (408)-764-5169 
or send email to bvj@ESD.3Com.com or majithia@calstate.bitnet

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 07:58:00 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   RFC 1078


Hi Everybody,

Recently I stumbled across RFC 1078. I have never seen this implemented, but
maybe I'd like to use it. Before I start doing it myself, has anybody else
already done it or is awar of an implementation ?


			ciao
				-Torsten
--
Torsten Beyer                      e-mail : tb@Materna.DE
Dr. Materna GmbH		   VOX    : +49 231 5599 225
Vosskuhle 37			   FAX    : +49 231 5599 100
D-4600 Dortmund 1,  West Germany

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 08:54:04 GMT
From:      efb@suned1.Nswses.Navy.MIL (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Sun 4c (SLC) OS 4.1.1 and SLIP packages

Have TWO questions.

(1) Do you have any version of public SLIP running on a Sun4c architecture
under SunOS 4.1.1 ( minimal kernel config files and all ) ?

(2) If YES to (1), what SLIP packages have you integrated / which ONE have
you used ON THIS CONFIG ( sun4c with SunOS 4.1.1 ) ?

PLEASE, save the bandwidth, I am willing to do PPP .. BUT the neighboring
BSD-Tahoe VAX IS NOT configured and that cant be done for several months ..

I know .. PPP is the right answer .. been flamed many times already .. Thnx

-- 
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 08:59:33 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP via Token Ring

Yes, a number of companies support TCP/IP over token ring. I think
you'll find most of the PC vendors do; in fact, there's even a token
ring packet driver. Some of the router vendors, like Proteon, cisco
and probably Wellfleet do as well.

Whether non-router and non-PC vendors support IP over token ring is
as problematic as finding a token ring card for something that's not a
PC...

RFC 1042 will do the trick.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 14:39:08 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: bandwidth usage for X applications?

Chris,

While not very sexy, performing file system backups over the net is a
necessary and bandwidth hungry application.  Our corporate communications
folks are concerned that an FDDI backbone might be not be enough to get all
remote systems backed up to come central site in the not too far distant
future.  You might consider loading up 50% of the ring with this sort of
traffic, and then run some of the apps that other people will be suggesting.

Tracy

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 15:27:43 GMT
From:      wied@birdie.sps.mot.com (Bill Wied)
To:        comp.protocols.tcp-ip
Subject:   Re: Need: Enhanced FTP

There seems to be some confusion over this request I posetd earlier. I realize that the IP layer is responsible for routing. But sometimes two networks are seperated by "firewall" machines for security measures (ie. a firewall between a business network and Internet). Thus to log on to an Internet machine from the business side you must first log on to the firewall machine. This keeps the Internet machine directly off your business network, while still allowing you to get access to it. I'm looking for an e







nhanced FTP which will "bridge" this firewall. To make data retrival a one-step process.

Please mail replys directly to me and do not post them. This just clutters the newsgroup.

Thanks 

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 16:03:46 GMT
From:      DAVID@wcc.govt.nz (David Richards)
To:        comp.protocols.tcp-ip
Subject:   Wollongong TCP/IP for VAX/VMS List

Does anybody known if there is a list for the Wollongong TCP/IP for VAX/VMS?

David Richards.

PS. Please reply to david@ccc.govt.nz, my return is incorrect.

Thanks.

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 17:26:33 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software for OS/2 ?


    Has anyone made a list of available TCP/IP software packages that run
    under OS/2 and which Ethernet boards they support?

IBM, FTP Software, Essex Systems, 3Com, and Ungermann-Bass all use the NDIS
software driver interface standard, and so can run on any network card for
which an OS/2 NDIS driver can be obtained (ask the vendor - it's required by
LAN Manager, but Netware uses ODI, which is different).  Most, if not all of
these can use either Ethernet or 802.5 NDIS drivers.  Interlan's offering
requires their intelligent Ethernet adapter.  Novell (Excelan)'s may use NDIS,
or it may use ODI, or it may require their intelligent adapter; I'm not sure.

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

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 18:11:31 GMT
From:      pks%netearth@SHAKTI.ERNET.IN
To:        comp.protocols.tcp-ip
Subject:   Request for x.25 addresses ...

Dear Sir,
	I am interested in knowing some locations which are running x.25
over tcp/ip?
It'll be very kind of you if you can send me list of such locations. 
Thanking you.
Praveen
*==========================================================================*
               	!
	|||||||||| 	!	PRAVEEN KANT SHARMA
	||     |||  !	
	||     ||| 	!	Educational & Reseach Network Project
	||||||||||	!	Dept. of CS&E
	||  		!	Indian Institute of Technology, Delhi
	||          !
	||          !	686-7431, Fax: 686-8765
	||          !	pks%netearth@shakti.ernet.in
			    !
*==========================================================================*

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 19:45:30 GMT
From:      smithfd@weiss.cs.unc.edu (Don Smith)
To:        comp.protocols.tcp-ip
Subject:   TriComm'91 Announcement and Advance Registraton

ANNOUNCEMENT and ADVANCE REGISTRATION


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

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

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

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

                         FEATURED SPEAKERS

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

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

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

                                SESSIONS

COMMUNICATIONS FOR MULTIMEDIA

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

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

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

APPLICATIONS AND  ARCHITECTURES	

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

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

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

COMPUTER CONFERENCING

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

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

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

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

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

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

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

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

PERFORMANCE AND	MEASUREMENT					

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

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

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

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


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

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

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

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

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


TRANSPORTATION

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

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

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

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

ADVANCE REGISTRATION FORM (Clip and mail to address below)

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

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

Name (for name badge) __________________________________________________

Affiliation (for name badge) ___________________________________________

Address ________________________________________________________________
       
        ________________________________________________________________

Phone ______________________________Email_______________________________

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

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

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

HOTEL RESERVATIONS (Clip and mail to address below)

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

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

Guest name___________________________________________________________ 

Phone_______________

Address______________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Arrival date _________________________Departure date_________________

Number in party__________ Share with ________________________________

_________________________________________________

Reservations must be received at the Inn by March 27, 1991. They will be held 
until 6:00 p.m. on the arrival  date unless a one night deposit is received 
or is guaranteed with American Express, Visa, or Mastercard.

Card name ____________________Expiration date ___________

Card number __________________________

Name on card (please print clearly) ___________________________________

Signature ____________________________________________________________
				         

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 20:15:23 GMT
From:      kdenning@pcserver2.naitc.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   POP servers -- where top find them?

Hi!

I need a POP server (in "C" source form) that is compatible with EUDORA (the
MAC POP/SMTP client).  

I have outbound functionality, and understand that it's this server that is
needed for inbound.

If it's small, please email it to me directly; otherwise a pointer would be
appreciated.

Thanks in advance.

-- 
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning@nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 91 23:10:15 GMT
From:      sudji@indo.intel.com (Sudji Husodo)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SLIP for Unix System V/386 R4.0


SLIP for Unix System V/386 Release 4.0 can now be picked up from
iabi.intel.com in pub/slip. The SLIP driver and its utilities is
available in two forms, source and pkgadd binaries.

slip.tar.Z - contains the sources of SLIP. To build and install slip
driver and its utilities from the sources do the following:
	transfer slip.tar.Z
    type "uncompress slip.tar.Z"
    type "tar xvf slip.tar"
    type "cd src"
    type "make"

slip.pkg.tar.Z - contains the binaries of SLIP in the pkgadd format.
To install SLIP and its utilities do the following:
    type "cd /usr/spool/pkg"
	transfer slip.pkg.tar.Z
    type "uncompress slip.pkg.tar.Z"
    type "tar xvf slip.pkg.tar"
    type "pkgadd"

The shell archived sources is also posted in comp.sources.unix:

Good luck!

Sudjiwo Husodo
sudji@indo.intel.com

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 09:32:57 GMT
From:      chris@vision.uucp (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: Registering an "official" port name

In article <1991Mar1.201628.9511@vision.uucp> I asked for pointers to the
method for registering an IP port.

Thankyou to all those who replied.  Here's a summary for interested parties.

RFC1060 (Assigned Numbers) - Jon Postel and Joyce Reynolds handle the
Internet port number assignments.  Email should be send to IANA@ISI.EDU

Chris
-- 
VISIONWARE LTD         | UK: chris@vision.uucp    JANET: chris%vision.uucp@ukc
57 Cardigan Lane       | US: chris@vware.mn.org   BANGNET: ...!ukc!vision!chris
LEEDS LS4 2LE, England | VOICE:  +44 532 788858   FAX:  +44 532 304676
-------------- "VisionWare:   The home of DOS/UNIX/X integration" -------------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 11:37:18 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   POP servers -- where top find them?

I'm in exactly the same position please let me know if you track it
down. thanks

*******************************************************************************
Snailmail: Gordon Byron,  Arts Computing Advisor,Pathfoot Building, 
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786 73171: Ext 7266  Fax: +78651335
*******************************************************************************

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 13:07:19 GMT
From:      efb@slced1.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   cslip crashing Sun 4/20 4.1.1

This evening I thought I had cslip ( UofT SLIP 4.0 with cslipbeta and the
sunos4 fixes ) working .. got connected onto a remote VAX (+e?) .. slattach
dev locip remip .. locally (Sun 4/20) .. slattach devc locip remip baud. 

No errors upon kernel or slattach make .. double checked the three READMEs
for UT, cslipbeta and sunos4.

Mar  6 19:01:39 slced1 vmunix: SunOS Release 4.1 (SLCED-SL) #1: Wed Mar 6 
18:48:11 PST 1991 .. new kernel booted

Got the good slip0 starting IP IP .. baud .. finally was able to route add
hisnet myip 1 .. even got ping and finally rsh running .. compatible compress,
baud .. as the traffic increased .. couldn't find much evidence of what else
may have been going on.  ALL at once with no visible degradation  ..

WHAT IS THE diffs from the above mentioned release configs to make a bullet
proof kernel for an SLC (4/20 Sun) with SunOS 4.1.1 ?  ( NO PPP not an option,
really )  Thank you /Ev/

*************************
/var/adm/messages extract
*************************
Mar  6 21:09:41 slced1 vmunix: slip0: coming up
Mar  6 21:23:43 slced1 vmunix: panic: mclput
Mar  6 21:23:43 slced1 vmunix: syncing file systems... BAD TRAP
Mar  6 21:23:43 slced1 vmunix: pid 234, `tcsh': Data fault
	tcsh has been running stably for many moons .. 
Mar  6 21:23:43 slced1 vmunix: kernel read fault at addr=0x2000034, pme=0x0
Mar  6 21:23:43 slced1 vmunix: Sync Error Reg 80<INVALID>
Mar  6 21:23:43 slced1 vmunix: pc=0xf80a63e4, sp=0xf8112be0, psr=0x1000c3, context=0x7
Mar  6 21:23:43 slced1 vmunix: g1-g7: f8185a5c, ff009fe0, f8138658, 0, f824c000, f8138400, f8138400
Mar  6 21:23:43 slced1 vmunix: Begin traceback... sp = f8112be0
Mar  6 21:23:43 slced1 vmunix: Called from f80a7f38, fp=f8112c40, args=ff027494 1 0 f8148f98 f818ffb4 2000000
Mar  6 21:23:43 slced1 vmunix: Called from f8064638, fp=f8112ca0, args=0 f81227a0 f8129b78 f8147730 f81227a0 f8112c38
Mar  6 21:23:43 slced1 vmunix: Called from f8065258, fp=f8112d00, args=f812266b 4006e6 f8038f44 40 1e6 f8122760
Mar  6 21:23:43 slced1 vmunix: Called from f80edb2c, fp=f8112d60, args=4006e1 0 ff02754c f813e800 ffffffff f8138010
Mar  6 21:23:43 slced1 vmunix: Called from f804f7a4, fp=f8112dc0, args=80 f8122328 f8116c00 f8122328 f8138000 4006e1
Mar  6 21:23:43 slced1 vmunix: Called from f805db24, fp=f8112e20, args=f8122328 800ae3 f8116c00 f813e800 5 2
Mar  6 21:23:43 slced1 vmunix: Called from f805d024, fp=f8112e80, args=ff64f400 f8138c72 f8116c00 f8138c70 68ab0000 237
Mar  6 21:23:43 slced1 vmunix: Called from f80179cc, fp=f8112ee0, args=ff64f400 20 6c 8001e4 8006e4 ff64f400
Mar  6 21:23:43 slced1 vmunix: Called from f8041ba4, fp=f8112f40, args=0 20 f8141768 8001e5 ff651190 ff651180
Mar  6 21:23:43 slced1 vmunix: Called from f8005c0c, fp=f8112fa0, args=1 4000c0 f8017364 0 1e6 f813ef4c
Mar  6 21:23:43 slced1 vmunix: Called from f805039c, fp=f824bb60, args=f8169674 f824bea4 f824beb8 1 1 f824bea4
Mar  6 21:23:43 slced1 vmunix: End traceback...
Mar  6 21:23:43 slced1 vmunix: panic: Data fault
Mar  6 21:23:43 slced1 vmunix: 00000 low-memory static kernel pages
Mar  6 21:23:43 slced1 vmunix: 00694 additional static and sysmap kernel pages
Mar  6 21:23:43 slced1 vmunix: 00016 dynamic kernel data pages
Mar  6 21:23:43 slced1 vmunix: 00163 additional user structure pages
Mar  6 21:23:43 slced1 vmunix: 00000 segmap kernel pages
Mar  6 21:23:43 slced1 vmunix: 00000 segvn kernel pages
Mar  6 21:23:43 slced1 vmunix: 00153 current user process pages
Mar  6 21:23:43 slced1 vmunix: failure dumping user stacks: proc=0xf816f868 as=0xff07dea8 seg=0xff0da2c0
Mar  6 21:23:43 slced1 vmunix: 01026 total pages (1026 chunks)
Mar  6 21:23:43 slced1 vmunix: 
Mar  6 21:23:43 slced1 vmunix: dumping to vp ff020f5c, offset 72108
Mar  6 21:23:43 slced1 vmunix: panic: zero

Mar  6 21:23:43 slced1 vmunix: rebooting...
Mar  6 21:23:43 slced1 vmunix: SunOS Release 4.1 (SLCED-SL) #1: Wed Mar 6 18:48:11 PST 1991
Mar  6 21:23:43 slced1 vmunix: Copyright (c) 1983-1990, Sun Microsystems, Inc.
Mar  6 21:23:43 slced1 vmunix: mem = 8192K (0x800000)
Mar  6 21:23:43 slced1 vmunix: avail mem = 6680576
Mar  6 21:23:43 slced1 vmunix: Ethernet address = 8:0:20:2:da:5c
Mar  6 21:23:43 slced1 vmunix: cpu = Sun 4/20
Mar  6 21:23:43 slced1 vmunix: zs0 at obio 0xf1000000 pri 12
Mar  6 21:23:43 slced1 vmunix: zs1 at obio 0xf0000000 pri 12

  our gadgets .. all appearing as normal ..
 
Mar  6 21:23:43 slced1 vmunix: root on sd0a fstype 4.2
Mar  6 21:23:43 slced1 vmunix: swap on sd0b fstype spec size 40170K
Mar  6 21:23:43 slced1 vmunix: dump on sd0b fstype spec size 40156K
Mar  6 21:37:21 slced1 vmunix: slip0: coming up
Mar  6 21:46:29 slced1 vmunix: BAD TRAP
Mar  6 21:46:29 slced1 vmunix: pid 123, `update': Data fault
Mar  6 21:46:29 slced1 vmunix: bad kernel read fault at addr=0x68692098
Mar  6 21:46:29 slced1 vmunix: Sync Error Reg 80<INVALID>
Mar  6 21:46:29 slced1 vmunix: pc=0xf80a63e4, sp=0xf81abda0, psr=0x1010c0, context=0x3
Mar  6 21:46:29 slced1 vmunix: g1-g7: 401ae4, 8000000, ffffffff, 80, f8116c00, f8138400, f8138400
Mar  6 21:46:29 slced1 vmunix: Begin traceback... sp = f81abda0
Mar  6 21:46:29 slced1 vmunix: Called from f80a7f38, fp=f81abe00, args=ff027494 1 0 f8149770 f81c9778 68692064
Mar  6 21:46:29 slced1 vmunix: Called from f8064638, fp=f81abe60, args=0 f81227a0 f8129b78 f8147730 f81227a0 ff09535c
Mar  6 21:46:29 slced1 vmunix: Called from f80f2650, fp=f81abec0, args=f81abfe0 120 f811ff30 f8120050 f81ac000 f8122760
Mar  6 21:46:29 slced1 vmunix: Called from f80059e4, fp=f81abf58, args=f81ac000 f81abfb4 f81abfe0 f81ac000 f81ac000 f81abfb4
Mar  6 21:46:29 slced1 vmunix: Called from 22c4, fp=f7fff488, args=0 0 3 0 0 f816d75c
Mar  6 21:46:29 slced1 vmunix: End traceback...
Mar  6 21:46:29 slced1 vmunix: panic: Data fault
Mar  6 21:46:29 slced1 vmunix: syncing file systems... done
Mar  6 21:46:29 slced1 vmunix: 00000 low-memory static kernel pages
Mar  6 21:46:29 slced1 vmunix: 00665 additional static and sysmap kernel pages
Mar  6 21:46:29 slced1 vmunix: 00016 dynamic kernel data pages
Mar  6 21:46:29 slced1 vmunix: 00229 additional user structure pages
Mar  6 21:46:29 slced1 vmunix: 00000 segmap kernel pages
Mar  6 21:46:29 slced1 vmunix: 00000 segvn kernel pages
Mar  6 21:46:29 slced1 vmunix: 00002 current user process pages
Mar  6 21:46:29 slced1 vmunix: 00106 user stack pages
Mar  6 21:46:29 slced1 vmunix: 01018 total pages (1018 chunks)
Mar  6 21:46:29 slced1 vmunix: 
Mar  6 21:46:29 slced1 vmunix: dumping to vp ff020f5c, offset 72172
Mar  6 21:46:29 slced1 vmunix: SunOS Release 4.1 (SLCED-SL) #1: Wed Mar 6 18:48:11 PST 1991
Mar  6 21:46:29 slced1 vmunix: Copyright (c) 1983-1990, Sun Microsystems, Inc.
Mar  6 21:46:29 slced1 vmunix: mem = 8192K (0x800000)
Mar  6 21:46:29 slced1 vmunix: avail mem = 6680576
Mar  6 21:46:29 slced1 vmunix: Ethernet address = 8:0:20:2:da:5c
Mar  6 21:46:29 slced1 vmunix: cpu = Sun 4/20
Mar  6 21:46:29 slced1 vmunix: zs0 at obio 0xf1000000 pri 12
Mar  6 21:46:29 slced1 vmunix: zs1 at obio 0xf0000000 pri 12
 
  our gadgets again ..
 
Mar  6 21:46:29 slced1 vmunix: root on sd0a fstype 4.2
Mar  6 21:46:29 slced1 vmunix: swap on sd0b fstype spec size 40170K
Mar  6 21:46:29 slced1 vmunix: dump on sd0b fstype spec size 40156K
Mar  6 21:51:06 slced1 vmunix: slip0: coming up
Mar  6 22:10:54 slced1 vmunix: BAD TRAP
Mar  6 22:10:54 slced1 vmunix: pid 287, `ping': Data fault
Mar  6 22:10:54 slced1 vmunix: kernel read fault at addr=0xff654000, pme=0x0
Mar  6 22:10:54 slced1 vmunix: Sync Error Reg 80<INVALID>
Mar  6 22:10:54 slced1 vmunix: pc=0xf80d7320, sp=0xf8112db0, psr=0x1c3, context=0x7
Mar  6 22:10:54 slced1 vmunix: g1-g7: 4006e4, 400ae1, ffffff80, 0, f82f6000, 0, 0
Mar  6 22:10:54 slced1 vmunix: Begin traceback... sp = f8112db0
Mar  6 22:10:54 slced1 vmunix: Called from f8016900, fp=f8112e10, args=788 ff653878 0 4 24 58
Mar  6 22:10:54 slced1 vmunix: Called from f8018b5c, fp=f8112e70, args=ff653fe8 ff653860 0 f8138f48 ff653858 ff653800
Mar  6 22:10:54 slced1 vmunix: Called from f801783c, fp=f8112ee0, args=ff653fe8 f8138f48 c037 0 f811d400 b
Mar  6 22:10:54 slced1 vmunix: Called from f8041ba4, fp=f8112f40, args=ff653f80 14 f8138f48 0 ff653fe8 0
Mar  6 22:10:54 slced1 vmunix: Called from f8005c0c, fp=f8112fa0, args=0 0 f8017364 0 8001e1 f813ef64
Mar  6 22:10:54 slced1 vmunix: Called from f805eba0, fp=f82f5d38, args=100 4001e3 4000e3 ff653080 0 0
Mar  6 22:10:54 slced1 vmunix: End traceback...
Mar  6 22:10:54 slced1 vmunix: panic: Data fault
Mar  6 22:10:54 slced1 vmunix: syncing file systems... [11] [11] [9] [7] [3] done
Mar  6 22:10:54 slced1 vmunix: 00000 low-memory static kernel pages
Mar  6 22:10:54 slced1 vmunix: 00657 additional static and sysmap kernel pages
Mar  6 22:10:54 slced1 vmunix: 00016 dynamic kernel data pages
Mar  6 22:10:54 slced1 vmunix: 00188 additional user structure pages
Mar  6 22:10:54 slced1 vmunix: 00000 segmap kernel pages
Mar  6 22:10:54 slced1 vmunix: 00000 segvn kernel pages
Mar  6 22:10:54 slced1 vmunix: 00110 current user process pages
Mar  6 22:10:54 slced1 vmunix: 00068 user stack pages
Mar  6 22:10:54 slced1 vmunix: 01039 total pages (1039 chunks)
Mar  6 22:10:54 slced1 vmunix: 
Mar  6 22:10:54 slced1 vmunix: dumping to vp ff020f5c, offset 72004

two more reboots with NO clues .. 
--
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 13:58:59 GMT
From:      pkilllea@unix2.tcd.ie (Tom Killalea)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Re: RARP implimentations for BSD 4.3 tahoe/reno

In <17161@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes:
>The standard BSD 4.3 does not seem to have a 'rarpd' program
>implimented. Is there a public version of the RARP protocol.
>jclark@ucsd.edu

We use bootpd for ip address resolution for ethernetted PCs on a tahoe
running BSD 4.3, but Macs running NCSA Telnet look for rarpd to 
dynamically get an ip number.  Apparently there isn't an rarpd implementation
under BSD for security reasons - it doesn't like user level processes looking
at ethernet packets.  If someone has discovered a workaround for this, other
than assigning ip numbers for the Macs manually, I'd like to hear it.

Tom.
--
Tom Killalea |                          |  Trinity College
             |  pkilllea@unix2.tcd.ie   |

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 14:14:30 GMT
From:      jessea@hbmc.uucp (Jesse W. Asher)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Looking for willing domain name forwarders for UUCP site.

I'm currently setting up a network and would like to get a domain name.
At this point, however, I'm UUCP only.  Does anyone know of some sites
that would be willing to be my forwarder (paying for the service isn't
a problem) besides uunet?  Thanx for any suggestions.

-- 
         Jesse W. Asher                             Phone: (901)386-5061
	                  Home-Bound Medical Care
	       5135 Covington Way, Suite 4, Memphis, TN 38134
                       UUCP: ...!{dynasys,banana}!hbmc!jessea

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 15:38:41 GMT
From:      ty@STYX.DESKTALK.COM (Tyson M. Kostan)
To:        comp.protocols.tcp-ip
Subject:   Re: bandwidth usage for X applications?

Tracy & Chris,
I would never recommend doing all backups to a central machine on such a wide
scale.  Maybe the network could be physically broken (i.e routers) into work-
groups, with a small workgroup server on each workgroup.  This will definately
be more economical overall, considering the requirements on a central server.

...Ty

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 18:05:55 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Need: Enhanced FTP


    The only example of data and control connection "juggling" that I'm aware
    of is in FTP clients that support what I'm in the habit of calling "third
    party copies". The idea is that you can sit at Machine A and use FTP to
    transfer a file from Machine B to Machine C without the data ever darkening
    Machine As doorstep. We support this in both our Windows 3.0 based FTP
    client and also our non-Windows FTP client in the LAN Workplace for DOS.
    I'm not sure if FTP softwares client can do this too but it wouldn't
    surprise me (2.04 couldn't, right James?).

Nobody's ever asked for it in our client, but someone reported a bug related
to this in our DOS FTP server, which will be fixed in the next minor release.
    
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 18:52:08 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  POP2/3, IMAP2/3


I know of the following POP daemons available by anonymous ftp -
For Berkeley-style UNIX:

	ucdavis.edu		/dist/pop3d, /dist/pop2d
	lilac.berkeley.edu	popper-1.7.tar.Z 	  (pop3)
	ics.uci.edu		mh/mh-6.7.tar.Z		  (pop3)
	thezoo.eng.clemson.edu	/pop3/pop3d.shar

For VMS:

	vx.acs.umn.edu			(I don't have file names)
	trident.arc.nasa.gov.

DOS POP clients available by anonymous ftp:

	boombox.micro.umn.edu		POPmail/PC 
	trident.arc.nasa.gov		PCPOP 
	ucdavis.ucdavis.edu		UCDmail

DOS POP clients in commercial TCP/IP packages:

	Sun's Lifeline			POP2 client
	IBM's TCP/IP package 		POP2 client
	FTP Software's PC/TCP 		POP2 and POP3 clients, and PCMAIL.


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

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 19:36:47 GMT
From:      ghelmer@dsuvax.uucp (Guy Helmer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP via Token Ring

In <9103060059.AA06214@asylum.sf.ca.us> romkey@ASYLUM.SF.CA.US (John Romkey) writes:

>Yes, a number of companies support TCP/IP over token ring. I think
>you'll find most of the PC vendors do; in fact, there's even a token
>ring packet driver.

Yes, but the Token Ring driver I looked at in the version 8 packet
driver distribution seems to want the IBM PC LAN Support Program
loaded.  I don't want to load it, and would much rather have a token
ring packet driver that either loads with or coexists with
Novell's IPX that speaks directly to the Token Ring adapter.  Is there
a freely available way to do this?

>		- john romkey			Epilogue Technology
-- 
Guy Helmer--helmer@sdnet.bitnet, wuarchive!dsuvax!ghelmer, uunet!dsuvax!ghelmer
Dakota State University Computing Services ------------------- (605) 256-5264
MidIX -- networks, databases, DOS, UNIX, & MINIX ------------- (605) 256-2788
-------------------------------------------------------------------------------

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 21:24:05 GMT
From:      fbraab@leuze-owen.de (Fritz B. Raab)
To:        comp.protocols.tcp-ip
Subject:   Info abt. TCP/IP <--> HP3000 needed, please !

Hello,
does someone have some knowledge about the Win/TCP implementation for
the HP3000 ?
We must connect such a biest to our net.
We want to send and recieve date to/from the HP3000 database (MM3000).

Is there a programming interface ? I know, that the Win/TCP HP3000 is not
(or better should not be) socket orientated, but there should be a similar
interface called NETIPC (or something like that).

Telnet and FTP are said to be no problem, but SMTP does only run with
HP Deskmanager installed (expensive); that's all I know.

Any hints are appreciated.
Thank you !
Fritz

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 21:30:52 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: "Forking" with MVS TCP/IP

>I am also interested in how one writes concurrent servers on MVS.  I hope
>you have better luck than I did getting answers.  Isn't anyone from IBM
>listening?

You might do better to ask on the IBM TCP/IP list (ibmtcp-l@pucc.bitnet).

Doug Nelson
Michigan State University

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 22:04:07 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Underscores

>underscores are found in some hostnames managed by merit on behalf of
>the nsfnet, e.g. ann_arbor.mi.nss.nsf.net, 129.140.17.77.  until these
>names are changed, it's hard to argue that underscores are illegal,
>just ill-advised.

Ed, the existence of a counter-example is a wonderful way to disprove
theory, but hardly the way to invalidate an RFC....  Just because Merit
uses such names doesn't make them legal.

Doug Nelson
Michigan State University

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 22:32:04 GMT
From:      khoo@aplcen.apl.jhu.edu (Khoo soo)
To:        comp.protocols.tcp-ip
Subject:   sockets



Hi there:
    This is my first posting to the net.  I am seeking a solution to 
a IPC problem using Berkeley sockets on a Unix machine running Ultrix
4.1 and connecting to a Prime computer with its own sockets library.
The protocol family used is SOCK_STREAM.

Description Below.

Premise:
    OS - Ultrix 4.1 on a DEC 5400
    I have developed sockets on this machine to communicate with a PRIME
computer.  It works but the real problem is the time for the client, which
is on the Prime to connect t othe server running on the Ultrix box is 
relatively long (20 - 30 secs).  I have been tinkering with the idea of
keeping the connection open at all times (so that I don't have to establish a
connection every single time I execute this remote command, but I don't know
how to implement a client server connection that is connected always.
It would be extermely difficult to do this on the Prime side. 

I would appreciate it if any of you out there could provide me with some
ideas/hints on how to accomplish this task.  (An example of such a program
would be marvelous).  Thanks.


  Mike Khoo.
  (3/07/91)

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 91 23:49:14 GMT
From:      erik@yarra.oz.au (Erik Lecis)
To:        comp.protocols.tcp-ip
Subject:   Network Management

Hi!

Does anyone have any opinions re: lan management packages? 

I am currently investigating SG's Netvisualyzer, HP's LanProbe and
Sun's SunNet (I am particularly interested in Sun based offerings as the
site has a large investment in their workstations). 
I will summarize responses.

Tx.
-- 
      -m------- Erik Lecis - Systems Engineer          E-mail: erik@yarra.oz.au
    ---mmm----- Pyramid Technology Corporation Pty Ltd
  -----mmmmm--- 1st Floor, 553 St. Kilda Road,
-------mmmmmmm- Melbourne, Victoria 3000, AUSTRALIA       tel: +61 3 521 3799

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 00:02:11 GMT
From:      jim@piggy.ucsb.edu (Jim Lick)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for Unix System V/386 R4.0

sudji@indo.intel.com (Sudji Husodo) writes:
>SLIP for Unix System V/386 Release 4.0 can now be picked up from
>iabi.intel.com in pub/slip. The SLIP driver and its utilities is
>available in two forms, source and pkgadd binaries.

I have been in contact with Sudji.  I was having trouble ftp'ing
to the host.  It seems there is a problem or restriction at some
router somewhere on the net, since he claims the machine is fine,
and he was able to send the files to me.  Anyways, in case anyone
else is having trouble getting this package, I thought I would
make it available here as well.  Ftp to piggy.ucsb.edu and look
in /pub/slip.  Everything should be the same as on iabi.intel.com.


                            Jim Lick		       
Work: University of California	| Home: 6657 El Colegio #24
      Santa Barbara		|       Isla Vista, CA 93117-4280
      Dept. of Mechanical Engr. |	(805) 968-0189 voice/msg
      2311 Engr II Building     |	(805) 968-1239 data 
      (805) 893-4113            |	(805) 968-2734 fax
      jim@ferkel.ucsb.edu	|	Soon: jim@cave.sba.ca.us  

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 07:16:01 GMT
From:      gday@digigw.digital.co.jp (Gordon Day)
To:        comp.protocols.tcp-ip
Subject:   SNMP Architecture

After reading section 3.2.5 of RFC 1157 I would appreciate clarification on the
following:

MIB view - the document states that the MIB view is "For any network element
a subset of objects in the MIB that pertain to that element".  Does "pertain"
imply all those MIB groups that the network element is required to provide as
per RFC 1156?  

Email replies would be preferred to reduce bandwidth on such a specific 
question.  I will summarize if there is interest.


Cheers,

Gordon Day.

-- 
Gordon

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 12:12:28 GMT
From:      keith@ca.excelan.com (Keith Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP via Token Ring

The News Manager)
Nntp-Posting-Host: ca
Reply-To: keith@ca.excelan.com (Keith Brown)
Organization: Novell, Inc. San Jose, California
References: <860@cns.SanDiego.NCR.COM> <9103060059.AA06214@asylum.sf.ca.us> <1991Mar7.193647.9815@dsuvax.uucp>
Date: Thu, 7 Mar 1991 22:43:37 GMT

In article <1991Mar7.193647.9815@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes:
>Yes, but the Token Ring driver I looked at in the version 8 packet
>driver distribution seems to want the IBM PC LAN Support Program
>loaded.  I don't want to load it, and would much rather have a token
>ring packet driver that either loads with or coexists with
>Novell's IPX that speaks directly to the Token Ring adapter.  Is there
>a freely available way to do this?
>

In our ODI workstation software we support both ways. There is an
ODI driver for LANSUP and another that talks directly to the IBM Token
Ring card. The reason for having two is that some folks actually want to
load the IBM LAN support program. They tell me it allows them to run other
bits and pieces of software that use LANSUP concurrently. I believe them,
although I'd be interested to hear from folks that have done something
along these lines and can give me specifics. I tend to use the "straight
to the metal" driver myself.

As for the part about freely available..... Alas we have to pay the salaries
of some 2500 people every day, so we need money! Sorry.....

Keith
-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 13:33:08 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   test

delete this sorry for any annoyance

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 14:54:48 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re:  Network Management

"Hi!

Does anyone have any opinions re: lan management packages?"

We have HP's LanProbe, which uses a specialized hardware box to gather data
and a PCompatible running Windows (ugh) to display info & command the box.
Connections can be direct (9600baud), over the same ethernet you're
monitoring or thru a builtin 2400 baud modem.  I love it for monitoring lower
level performance, and for being able to do some fancy packet tracing AT THE
SAME TIME!  So you can be monitoring netowrk 'health' and debugging somebody's
router problems...  Lots of other neat features...
We've used SGI's Netvisualyzer and, IMO, it's a different kind of beast.  More
like the next level up in terms of the picture you see.  I also believe that
you can't count on seeing *every* packet with a general purpose workstation.
So decide on what level of net mgmt you want.

-------------------------------------------------------------------------------
 Willis F. Marti		Internet: willis@cs.tamu.edu
 Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
 	---Not an official document of Texas A&M---

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 15:32:17 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP via Token Ring

Some history: Long ago (1986 or so), when IBM first shipped 802.5 cards
for the PC, they defined a standard software driver (very much like the
Packet Driver in concept) which all protocol stacks and applications
could use, and thus be hardware-independent.  The spec was entitled
"Adapter Support Interface", and was initially implemented in
TOKREUI.COM (various versions for the different IBM 802.5 adapters).
In order to work with IBM's applications, all the other 802.5 board
vendors implemented ASI drivers, too (PRO4EUI, 3COMREUI, etc.).

So, there is very little software out there which has board-specific
drivers for 802.5 (our LANWatch uses direct-to-the-board interfacing
with Proteon hardware, because ASI doesn't support "match all" as a
security measure).  PC/TCP, Netware, Vines and pretty much everything
else prefers to use the ASI driver (normally IBM's LAN Support Program,
which replaced TOKREUI a few years ago).  Because it is ubiquitous,
we could ship one part for 802.5 where we ship 20 for different
Ethernet boards, and this is very attractive...

The IBMTOKEN Packet Driver uses ASI to talk to many vendors' hardware,
but keep in mind that it is a Class 1 (DIX Ethernet) driver, which
adds the necessary RFC 1042 framing so the protocol stack doesn't have
to be 802.5-aware.  This is good for limited use of DOS TCP/IP stacks
that don't happen to be available in 802.5-aware versions (the free
ones).  However, it breaks down under heavy use (ARP cache in the stack
conflicts with RIF cache in IBMTOKEN) or when you're trying to use
protocols that don't use the same Ether -> 802.5 transform as TCP/IP.

Recently (1990), IBM introduced NDIS drivers as an alternative to the
LAN Support Program, but not many DOS products can use an NDIS driver
for 802.5 yet.  Some of the board vendors have followed suit, but what
I've heard about IBM's own statements of direction indicate that both
ASI and NDIS will continue to be supported in parallel for a while.

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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 15:57:57 GMT
From:      bianco@cs.odu.edu (David J. Bianco)
To:        comp.protocols.tcp-ip
Subject:   SunOS 4.1.1 + SLIP == Need Help 8)

I'm not a TCP/IP guru or anything (which may be part of the
problem), but I cannot seem to get SLIP to work on our sun3
running SunOS4.1.1.  We got UofT's slip-4.1beta package and
rebuilt our kernal to accomodate, but anytime we try a slip
attach, we get "ioctl (I_PUSH) slipen: Invalid argument" in
our syslog.  Does anyone know either what we're doing wrong,
or where we can get some documents on slip (preferably ftp)
to help us figure it out?  Email is appreciated, bu netnews
answers are also great.


	Thanks,
	  David
--
==========================================================
David J. Bianco -- Systems Dude
Old Dominion University
Dept of Computer Science,
Norfolk, VA 23529

<bianco@cs.odu.edu> || <...!uunet!xanth!bianco>

	"That's the short definition of Systems Engineer."
			-- Geordi LaForge (Paraphrased)
==========================================================

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 16:28:15 GMT
From:      lee@gdc.portal.com (Seng-Poh Lee, Gen DataComm, +1 203 758-1811)
To:        comp.protocols.tcp-ip
Subject:   Re: Registering an "official" port name

In article <1991Mar7.093257.16682@vision.uucp>, chris@vision.uucp (Chris Davies) writes:
> In article <1991Mar1.201628.9511@vision.uucp> I asked for pointers to the
> method for registering an IP port.
> 
> Thankyou to all those who replied.  Here's a summary for interested parties.
> 
> RFC1060 (Assigned Numbers) - Jon Postel and Joyce Reynolds handle the
> Internet port number assignments.  Email should be send to IANA@ISI.EDU
> 

For that matter, where can you pick up a copy of all the registered port
numbers? 

-----
Seng-Poh Lee			      	Work:	lee@gdc.portal.com
Technology Center			...!uunet!portal!gdc!lee
General DataComm Ind. Inc.	      	Home:	lee%splee.uucp@hsi.com
					...!uunet!hsi!splee!lee

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 18:29:56 GMT
From:      meggers@mothra.nts.uci.edu (Mark Eggers)
To:        comp.protocols.tcp-ip
Subject:   zero as a subnet number

I know that this was just posted, but since we do not have a zero subnet
number (class B, 255.255.255.0 subnet mask), I didn't pay attention to it.

There is now a net connected to us with a zero subnet, and I need to give
them a detailed explaination of why this is not a good idea.  I found that
I cannot explain this accurately enough.  Could someone please email me a
concise, reasoned explaination?

Sorry to waste bandwidth - Murphy's Law of news and email:

If you pitch it, you'll need it.  If you archive it, you'll run out of
disk space.

thanks - /mde/

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 19:04:19 GMT
From:      phil@shl.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Re: bandwidth usage for X applications?

In article <9103051621.AA05970@cmc.com> chrisv@CMC.COM (Chris VandenBerg) writes:
>QUESTION - Does anyone have a feel for rough bandwidth usage for some of the
>"typical" (if there is such a thing) X client applications? Has anyone run any
>benchmarks which included X sessions across the net? 

I did a quick and dirty 'bandwidth benchmark' a few weeks ago to determine
how much bandwidth a typical X session takes up.

Following is a synopsis of what I did.  Please keep in mind that I was 
using an NCD X Terminal which was *not* blindingly fast.  A faster X terminal
could easily double the bandwidth requirements (I would think).  I'm going to
be performing these tests again sometime in the next few weeks with a fast
SparcStation acting as an X terminal to see what changes.

For those that don't want to wade through this, I found that I used about 
68 kbps average bandwidth for screen redraws.

----

A series of tests were performed and the results analyzed.  The test 
environment consisted of a Sun 4/260 Unix computer on an ethernet along 
with an NCD X terminal.  A LAN protocol analyzer and a network monitoring 
package was also attached to the network. 

The protocol analyzer was set up to record all packets going to or 
coming from the X terminal.  The Ingres 4GL Windows environment was run 
on the Sun computer with all output being directed to the X terminal.  
A sample Ingres Windows/4GL database application was run under the 
Motif window manager during the tests. 

Four sampled tests were conducted: 

- Initiation of the application program.  This involved invoking the 
application through a pull down menu.  The application drew a full screen form 
consisting of about 10 buttons, 3 scroll bars, 15 boxes, and 20 text fields.  
This is a fairly representative X window database form.  The test stopped 
after the form had been completely drawn. 

- Data entry.  Using the above form, the test caught about 1.5 minutes of 
fairly rapid data entry activity which included entering text and numbers, 
checking boxes, and pressing buttons.  Part of the test included pressing a 
button that displayed a 1/2 screen size pop up window with a histogram 
displayed. 

- Switching between two windows.  This test caught the activity that was 
generated when switching between two large and complex windows. 

- Switching between multiple windows.  This test caught the activity that was 
generated when switching between multiple windows in rapid succession. 
 
Results 

Following are the outputs of each test (the times are measured in seconds, 
and the network utilization in kilobits per second): 

awk -f awk.prg form.txt 
Total bytes: 240554  Total time:  34.92  Avg utilization:  68.89 kbps 
 
awk -f awk.prg entry.txt 
Total bytes: 281998  Total time:  96.70  Avg utilization:  29.16 kbps 
 
awk -f awk.prg switch.txt 
Total bytes: 25630  Total time:   6.65  Avg utilization:  38.54 kbps 
 
awk -f awk.prg switch2.txt 
Total bytes: 107276  Total time:  30.24  Avg utilization:  35.47 kbps 

-----

Phil Trubey
SHL Systemhouse Inc.
(Internet: phil@shl.com      UUCP: ...!uunet!shl!phil)
-- 
Phil Trubey
SHL Systemhouse Inc.
(Internet: phil@shl.com      UUCP: ...!uunet!shl!phil)

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 19:18:10 GMT
From:      jim@piggy.pigs.ucsb.edu (Jim Lick)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for Unix System V/386 R4.0

jim@piggy.ucsb.edu (Jim Lick) writes:

>sudji@indo.intel.com (Sudji Husodo) writes:
>>SLIP for Unix System V/386 Release 4.0 can now be picked up from
>>iabi.intel.com in pub/slip. The SLIP driver and its utilities is
>>available in two forms, source and pkgadd binaries.
 
>I have been in contact with Sudji.  I was having trouble ftp'ing
>to the host.  It seems there is a problem or restriction at some
>router somewhere on the net, since he claims the machine is fine,
>and he was able to send the files to me.  Anyways, in case anyone
>else is having trouble getting this package, I thought I would
>make it available here as well.  Ftp to piggy.ucsb.edu and look
>in /pub/slip.  Everything should be the same as on iabi.intel.com.

And of course, the main router here decided to crap out last night.
Everything is back in business now, and ftp to piggy.ucsb.edu should
work fine for everyone.

                            Jim Lick		       
Work: University of California	| Home: 6657 El Colegio #24
      Santa Barbara		|       Isla Vista, CA 93117-4280
      Dept. of Mechanical Engr. |	(805) 968-0189 voice/msg
      2311 Engr II Building     |	(805) 968-1239 data 
      (805) 893-4113            |	(805) 968-2734 fax
      jim@ferkel.ucsb.edu	|	Soon: jim@cave.sba.ca.us  

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 91 21:02:37 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.protocols.tcp-ip
Subject:   Wang's TCP/IP

I'd like to communicate with anyone using Wang's TCP/IP product
for WANG/VS systems.  We're planning to install this software.

Please reply via email.

Thanks
Paul Hardiman
University of Wisconsin - Milwaukee

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 91 00:44:55 GMT
From:      sudji@indo.intel.com (Sudji Husodo)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for Unix System V/386 R4.0

For those who tried to ftp SLIP source or pkgadd binary from iabi.intel.com
( 128.215.19.51 ) and failed, we have resolved its routing problem. Try again
and let me know if you still have problems.

Sudji

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 91 20:08:45 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   DP8390

Geoff Pack
Have been having enourmous difficulty contacting you.
Am trying this message through a number of routes.
Yes, please send the info you have on the DS8390 B problems.
Several others have contacted me for the results.
Thanks
Andrew

Send to ash@omega.uucp or ...!ukc!cctal!andrew, whichever is easier.
-- 

+----------------------------------------------------------------------------+
|  Andrew Hardie                                             ash@omega.uucp  |
|  London, England                                      ukc!cctal!omega!ash  |
+----------------------------------------------------------------------------+

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 91 20:23:45 GMT
From:      tim@appenzell.cs.wisc.edu (Tim Theisen)
To:        comp.protocols.tcp-ip
Subject:   Re: cslip crashing Sun 4/20 4.1.1

In article <8329@suned1.Nswses.Navy.MIL> efb@slced1.nswses.navy.mil (Everett F Batey) writes:
>This evening I thought I had cslip ( UofT SLIP 4.0 with cslipbeta and the
>sunos4 fixes ) working .. got connected onto a remote VAX (+e?) .. slattach
>dev locip remip .. locally (Sun 4/20) .. slattach devc locip remip baud. 
>
>No errors upon kernel or slattach make .. double checked the three READMEs
>for UT, cslipbeta and sunos4.
>
>Mar  6 19:01:39 slced1 vmunix: SunOS Release 4.1 (SLCED-SL) #1: Wed Mar 6 
>18:48:11 PST 1991 .. new kernel booted
>
>Got the good slip0 starting IP IP .. baud .. finally was able to route add
>hisnet myip 1 .. even got ping and finally rsh running .. compatible compress,
>baud .. as the traffic increased .. couldn't find much evidence of what else
>may have been going on.  ALL at once with no visible degradation  ..
>
>WHAT IS THE diffs from the above mentioned release configs to make a bullet
>proof kernel for an SLC (4/20 Sun) with SunOS 4.1.1 ?  ( NO PPP not an option,
>really )  Thank you /Ev/
>
>two more reboots with NO clues .. 

OK, here is a clue.  I found the following bug when I ported cslipbeta to
Ultrix 4.0.  In if_sl.c, there is a spot where the code looks at the data
in the mbuf to do type of service queueing.  However, it just blindly looks
where it expects the data to be.  When IP fragmentation is occuring, the
IP header and data are in seperate mbufs.  The code may access a memory
location off the end of the mbuf.  On the Ultrix MIPS kernel, if you were
unlucky enough to have the mbuf against the top of kernel memory, the access
would generate a trap and the kernel panics.

Here is the fix I applied to cslipbeta.  This might be the cause to your
problem.  In any case, it would not hurt to apply the patch.

*** if_sl.c.old	Sat Mar  9 14:09:12 1991
--- if_sl.c	Sat Mar  9 14:11:35 1991
***************
*** 456,462 ****
  	}
  	ifq = &ifp->if_snd;
  	if ((ip = mtod(m, struct ip *))->ip_p == IPPROTO_TCP) {
! 		register int p = ((int *)ip)[ip->ip_hl];
  
  		if (INTERACTIVE(p & 0xffff) || INTERACTIVE(p >> 16)) {
  			ifq = &sc->sc_fastq;
--- 456,464 ----
  	}
  	ifq = &ifp->if_snd;
  	if ((ip = mtod(m, struct ip *))->ip_p == IPPROTO_TCP) {
! 		register int p = -1;
! 		if (m->m_len > sizeof(struct ip))
! 			p = ((int *)ip)[ip->ip_hl];
  
  		if (INTERACTIVE(p & 0xffff) || INTERACTIVE(p >> 16)) {
  			ifq = &sc->sc_fastq;

Hope this solves your problem,  ...Tim
-- 
Tim Theisen             Department of Computer Sciences
Systems Programmer      University of Wisconsin-Madison
tim@cs.wisc.edu         1210 West Dayton Street
(608)262-0438           Madison, WI   53706

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 91 20:32:32 GMT
From:      mts@TERMINATOR.CC.UMICH.EDU (Michael T. Stolarchuk)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Unix System V/386 R4.0


Well, this may be better new than you would have hoped for.
If it does happen intermittently, then this code may be a trap
since it hasn't fired yet.

mts

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 91 23:21:42 GMT
From:      efb@suned1.Nswses.Navy.MIL (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY Digital phones for SLIP etc (260+ lines)

Thank you to the many who responded.  Hope the edits do proper justice to
all.  This is less filtered and sorted than I hoped for BUT feed this
to the printer and get out a six-pack.  Keep or edit out form feeds
each +/- 58 lines.  AN elegant short haul alternative at bottom.

My goals are to get a few more USN sites glued together better and ultimately
join other DoN sites in trying to get Navy sites inter-connected by common
resources and get out of the unique solutions rut.

The following is a personal work and only attempts to collect the opinions
of others.  You are welcome to this .. IN THESE TERMS .. Not an OFFICIAL
Statement.  

 
On Mar 2, 19:51, cliff bedore* wrote:
 I have seen ads in Black Box and other places adds for "short haul" modems
 that do what you want.  I seem to remember that they are not terribly
 expensive ($100-$200?).  I'm not at work but if you don't have any luck
 elsewhere, send me mail and I'll look it up on Monday.  I've been trying to
 get SLIP running between XENIX systems over USR HST modems and they won't
 work at over 2400 baud.  Slip itself runs just fine at 19.2 but these modems
 won't cut it.  Response at 9600 baud is reasonable for 1-2 logins so if you
 can get one of these long haul modems to work, that should be fast enough. 
}-- End of excerpt from cliff bedore*

On Mar 3,  7:46, John Scoggin wrote:
 We have some Northern Telecom Async-Sync Interface Modules, and they are very
 reliable up to 56 KBPS!  So long as your transmission facilities are clean (we
 use our own fiber cable to provide T-1 service between switches), you should
 have absolutely no problem.  I believe that the async will run up to 19.2 KBPS.
 You need to be careful with the Suns, though; I have read several comments
 about over-running the async ports on them when using SLIP. (Haven't tried it
 myself)  Email: scoggin@delmarva.com
}-- End of excerpt from John Scoggin

On Mar 3, 14:42, Wayne Sung wrote:
 I'll venture answers to two of your possibilities:
 1) if you have direct wire pairs line drivers can work quite well. Which
 exact kind to use depends on whether the lines are loaded. If they are, you
 will need voice band drivers which are less desirable than the Telebit
 possibility. If they are not loaded you can even get 56k at 3 miles. I like
 using DDS CSU/DSU's for line drivers because they are more tolerant of line
 problems.
 2) using any two Telebits at 9600 PEP (and in fact needing only one pair
 instead of two) you should use the leased line mode. This way they can
 restart themselves. We have a number of dedicated control circuits which
 are done this way (although over microwave voice channels). You also get
 error handling which a simple line driver will not give you.
}-- End of excerpt from Wayne Sung

On Mar 3, 17:11, Robert M. Enger wrote:
 If you have access to a 4-wire metalic facility,
 why not go for the gusto.  You should be
 able to run atleast 56Kbps straight end to end,
 with QUALITY csu/dsu equipment.
 You MAY be able to run T1 straight end to end.
 If not, you can certainly get away with it if
 you can put a T1 repeater somewhere along the way.
 (Check with manufacturers of the T1 csu/dsu 
 equipment; you need good HOT line drivers, etc)
}-- End of excerpt from Robert M. Enger

On Mar 6, 14:21, elroy!ISI.EDU!prue wrote:
} Subject: Re:  Digital phones for SLIP circuits, 56KB tariff data, too
   Both GTE and PacBell use an ADN intra-LATA tariff that provides
   digital dedicated service for ~$100 +$6/mile per mo.  The interesting thing
  .. thank you very much .. is that substantially what LOS NETTOS is 
  built upon ?   What class name is that service ??
 
 Los Nettos uses T1 service for all regular members.  T1 runs at 1.544 Mb/s
 about 27 times the 56K service I mentioned.  Los Nettos Associates connect
 to member networks at whatever rate they want to pay for.  The slowest is 9600
 but most use 56K ADN (Advanced Digital Network) service.  Some Associates
 
 use T1 service too.
}-- End of excerpt from elroy!ISI.EDU!prue

On Mar 6, 11:12, elroy!ISI.EDU!prue wrote:
 I dont have specific knowledge of SLIP but I dont think that it depends on
 control signals for flow control.  If your medium is full duplex as are digital
 services that I know of and the modern dial modems, I can not imagine that
 you would have problems.  Some link protocols have flow control based on
 X-ON and X-OFF.  This messes up transparency.  Others use control leads of
 the RS232 interface that would be seen at the other end.  This sort of flow 
 control is often used when the two devices are cable lengths apart not dial
 modem lengths apart.  I don't think SLIP does flow control.
 
 You mentioned using Northern Telecom 9600 digital service.  I know nothing
 of this type service but an interesting thing to note is the ADN tariff
 we are using.  Both GTE and PacBell use an ADN intra-LATA tariff that provides
 digital dedicated service for ~$100 +$6/mile per month.  The interesting thing
 is that the rate is the same for 2400 or 56000 bps.
}-- End of excerpt from elroy!ISI.EDU!prue

On Mar 3, 23:03, efb TO: Wayne Sung wrote:
 If I read you correctly, the telebit, as delivered with RJ11s?, can also run
 on simple metallic pairs with no CO battery, etc or however metallic lines
 are delivered.  IS THIS THE CASE ?  Just a reconfig of the inerts of the 
 telebit ???  /Ev/
}-- End of excerpt from TO: Wayne Sung

On Mar 4, 21:27, TO: Bob Sutterfield wrote:
 Bob .. thanks .. the PPP sounds like the better solution .. except .. on
 the remote end is a MVAX-II running Berkeley-TAHOE, OR a Sun3/260 running
 SunOS 4.1.1.  Noticed much SPARC Sun stuff rans on the S-3s at 4.1.1.
 
 Do you have reason to think the PPP code might make the grade on Sun 3s with
 only trivial fixing ???  Thank you very much .. /Ev/
 
 On Mar 4, 10:24, Bob Sutterfield wrote:
     money for modems, we are trying to pick the most trustworthy and
     easy to accomplish SLIP link.  Sites are within 3 miles, wire, 
  I think you are making your specification too specific.  Do you really
  need to run RFC1055 SLIP, or is the need for an IP channel over a
 
  PPP, the newer RFC1171 Point to Point Protocol.  In fact, we have both
  PPP and SLIP installed in the same kernels and they both work fine,
 
  Whichever you use, be sure it implements RFC1144 TCP header
  compression.  It will improve your performance remarkably.
 
  Get ftp.ee.lbl.gov:cslipbeta.tar.Z (if you must run SLIP) or
  tut.cis.ohio-state.edu:pub/ppp/ppp-sparc4.1.tar.Z (if you want a
  reliable, flexible, high-performance serial line IP connection instead
  of SLIP).
     - We have some available Telebit modems, 
  SPARCstations connected by a T2500 and a TB+, we see 1.3-1.5
  Kbytes/sec FTP throughput, one-way.  Interactive response is
  survivable.  
 
 
     Is there a good way to use these locally over an analog delivered
     voice grade phone line ?
 
  In the Telebit Trailblazer Plus reference manual, please see Appendix
  F, "Leased Line Considerations".  In the manuals for other modem
  models, the appendix may be numbered differently.  
 
     - How would YOU rate from YOUR PERSONAL experience these options,
     for cost effectiveness 
 
  DEFICIENCIES section of RFC1055 and the Introduction of RFC1171 for a
  discussion of why you should avoid SLIP unless you absolutely must use
 
  Our company will soon release a product that implements both SLIP and
  PPP in a convenient-to-install-and-use package.  We have no explicit
  plans right now to support the Sun-3 line, but it should be no great
  problem to do the port if you need it.  Perhaps we could have
  temporary Internet access to your systems while we do the work.
  Please contact Jamey Laskey at +1-800-558-7827 or write to
  marketing@morningstar.com to find out more.
 }-- End of excerpt from Bob Sutterfield
}-- End of excerpt from TO: Bob Sutterfield

On Mar 4, 14:12, Robert M. Enger wrote:
 We run Dowty T1 csu/dsu units.  they are model 7055060
 
 I recall they cost about 1500 each.
 These are extended super frame units (which
 allow out of band end-to-end monitoring
 of link error rate, remote monitoring of
 distant end csu/dsu unit, etc).
 
 They are also capable of B8ZS operation
 allowing you to put full 1.536Mbps user data.
 They act as the dsu (putting on framing, etc)
 so that you can plug the sun, or a router 
 directly into this unit (v.35 connector, 
 need v.35 to rs422 adapter from Blackbox if
 computer has rs422 connector).
 
 You won't be able to drive these from the console
 port on a sun (and you wouldn't want to anyway
 since console port is NOT DMA and causes an
 interrupt per character :-(   ).
 You'll need to get a Synchronous data board
 for your suns, or use routers.  The routers
 will remove some load from your suns.
 
 I like Cisco AGS+ routers, but they will be
 overkill for your situation (probably, don't
 know all your specifics).
}-- End of excerpt from Robert M. Enger

On Mar 5,  9:57, Bob Sutterfield wrote:
    Bob .. thanks .. the PPP sounds like the better solution .. except
    .. on the remote end is a MVAX-II running Berkeley-TAHOE, OR a
    Sun3/260 running SunOS 4.1.1.
 
 
 Get PPP for VAX BSD4.3 from lancaster.andrew.cmu.edu:pub/ppp/ppp.shar.
 This is Drew Perkins' <ddp@andrew.cmu.edu> original PPP
 implementation, developed (as I understand things) as a proof exercise
 while writing the RFCs.  It's the ancestor of the stuff in
 tut.cis.ohio-state.edu:pub/ppp/ppp-sparc4.1.tar.Z.
 
    Noticed much SPARC Sun stuff rans on the S-3s at 4.1.1.  Do you
    have reason to think the PPP code might make the grade on Sun 3s
    with only trivial fixing ???
 
 Yes, and I think folks are already doing just that.  Brad Clements
 <bkc@omnigate.clarkson.edu> took Drew Perkins' VAX code and ported it
 to a Sun386i under SunOS 4.0.1, adding TCP header compression and
 STREAMS support along the way.  Karl Fox <karl@morningstar.com> took
 that result and ported it to a Sun4 under 4.0.3, 4.0.3c, 4.1, and
 4.1.1, removing some assumptions and cleaning up some bugs along the
 way.  I strongly suspect that you'll be able to build the same 4.1
 code into your Motorola 4.1 kernel with no changes at all.  If you
 find any assumptions that remain after the Intel-to-SPARC port that
 make it unable to run on a Motorola machine, please let Karl and me
 know and we'll plow them back into the distribution again.  I doubt
 there are any such problems, and I think I've heard of people running
 this stuff on their Sun3s, but I can't put my finger on the reference
 just now.
}-- End of excerpt from Bob Sutterfield

On Mar 6, 13:23, TO: elroy!ISI.EDU!prue wrote:
} Subject: Re:  Digital phones for SLIP circuits, 56KB tariff data, too
  You mentioned using Northern Telecom 9600 digital service.  
   I mis-spoke .. feature of Meridian Phones .. digital with analog cards at
   subscriber end.
  of this type service but an interesting thing to note is the ADN tariff
  we are using.  Both GTE and PacBell use an ADN intra-LATA tariff that provides
  digital dedicated service for ~$100 +$6/mile per month.  The interesting thing
 .. thank you very much .. is that substantially what LOS NETTOS is 
 built upon ?   What class name is that service ??
  is that the rate is the same for 2400 or 56000 bps.
}-- End of excerpt from TO: elroy!ISI.EDU!prue

On Mar 9,  7:59, C Pratt wrote: } Subject: SLIP on TP ( Ed. Twisted pair ? )
     If your pairs are dry, you can implement full 802.3 over 2 pair for 2300
 per end with Network Application Tech Bridges and Black Box or RAD 64KB line
 drivers. These are good for 6 miles (422/449) and WORK. This is how we did the
 floors and buildings in CC after all the high tech solutions failed (due to
 artificial roadblocks set up by NC building managers and the phone company
 (C&P). The pairs we had to use are noisiest imaginable and elevator motors
 induced massive noise spikes on the line every time someone went upstairs. I
 had no money left as my predecessors spent it all on equipment that would not
 work. We stuck serial connections on all the systems just to get something
 going and then one of my vendors came up with these "cheap" bridges. 64KB isnt
 T1 but T1 is pricey. The bridges will standalone or you can buy even cheaper
 versions that do the same thing but are just cards that fit in a dead AT (they
 don't use the AT buss for anything but power). This makes a cheap multiport
 bridge for the headend of a star.
}-- End of excerpt from C Pratt
-- 
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 91 12:52:56 GMT
From:      larry@nstar.rn.com (Larry Snyder)
To:        comp.protocols.tcp-ip,comp.protocols.ibmpc,comp.sys.ibm.pc.hardware
Subject:   ncsa telnet

I am having problems getting ncsa telnet working from my dos machine -

ftp works just fine - but telnetting to the unix boxes results in what
appears to be multiple concurrent logins and improper key mapping

could someone be so kind as to mail me their telnet configuration file
along with their keyboard remapping file?

thanks - larry

-- 
   Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis)
                        regional UUCP mapping coordinator 
               {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 91 13:06:18 GMT
From:      GBODSO1@NUSVM.BITNET (HC Eng)
To:        comp.protocols.tcp-ip
Subject:   NETDATA & UUENCODE

I don't know whether this is the right place to pose the following questions.
If not, would some kind soul please advice otherwise.

What is UUENCODE?  What is NETDATA format?  I am a user of BITNET.  I dial
up to a VM host from a PC.  These two terms have stumped me when I try to
FTP files, binary & ASCII, on SIMTEL20.ARMY.MIL to my PC.  I understand that
it has something to do with my VM host being an EBCDIC machine and also not
capable of receiving 8 bit data.

Thanks.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 91 13:23:50 GMT
From:      tony@uhcmtg.phys.hawaii.edu (Antonio Querubin)
To:        comp.protocols.tcp-ip
Subject:   CSLIP on SunOS 4.0.3 & KA9Q

I recently installed the cslip-beta code on a Sun 4/330 running SunOS 4.0.3.
The SUN is connected to a PC running KA9Q with the serial port configured
for SLIP.  These two machines previously had no trouble talking to each other
when plain SLIP was running on the SUN.  But with CSLIP on the SUN (and nothing
changed on the PC), a telnet or ftp connection from either machine to the 
other results only in a 'connection established' message and nothing more.
However, I have no problems pinging either machine from the other.  

Is there some switch that needs to be set in NOS so that it will handle CSLIP?

Looking at the source code for slattach.c I noticed there were some flags that
could be set to disable compression so I tried those too.  Unfortunately, I
got the same results - ping works, but no telnet and no ftp beyond the initial
'connection established' message.

Anyone got any clues as to what I might be doing wrong here?  

Antonio Querubin
tony@uhcmtg.phys.hawaii.edu

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 91 14:12:51 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1078

In article <tb.668246280@elwood> tb@Materna.DE (Torsten Beyer) writes:
+---------------
| Recently I stumbled across RFC 1078. I have never seen this implemented, but
| maybe I'd like to use it. Before I start doing it myself, has anybody else
| already done it or is awar of an implementation ?
+---------------

SGI's "Irix" comes with TCPMUX support built into "inetd". I don't
know who else supports it (it doesn't seem to be in BSD 4.3-Reno).
From internal comments it would appear that SGI's version is:

 *  Based on TCPMUX.C by Mark K. Lottor November 1988
 *  sri-nic::ps:<mkl>tcpmux.c

so you might look there if you want to implemente it yourself.
(I just looked, and the file's still there.)

Lottor's "tcpmux.c" runs as a separate intermediate server program,
forked from "inetd" whenever anyone connects to port 1, which is how
you'll have to do it if you don't have sources to your "inetd". SGI
just happened to choose to embed it in "inetd", which saves a separate
process and a separate configuration file. SGI's "inetd.conf" syntax
was extended to allow TCPMUX services to be specified, as in these
examples:

tcpmux/+date	stream	tcp	nowait	guest	/bin/date	date
tcpmux/mydate	stream	tcp	nowait	guest	/usr/tmp/mydate	/usr/tmp/mydate

As with Lottor's "tcpmux.c", in the first case the prefixed "+" means
that an RFC 1078 "positive acknowledgment" will be given by "inetd"
before running "date"; in the second case the "mydate" program will
be responsibile for the positive or negative acknowledgment.


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 91 16:13:05 GMT
From:      ron@TROUT.NOSC.MIL (Ron Broersma)
To:        comp.protocols.tcp-ip
Subject:   Re: CSLIP on SunOS 4.0.3 & KA9Q

Be aware that the cslipbeta/sunos4 stuff ALWAYS does compressed SLIP.  If
the remote node can't handle compressed packets, you won't be able to
communicate.

It is fairly easy to add the code to make it do both.

--Ron

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 00:51:28 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: bandwidth usage for X applications?


My apology if I don't understand the context of this but doing backups
from a central machine has two parts.

1) If you are moving all the data to a central machine then you have a
serious problem.

2) If you are controlling the backup process from a central machine then
you don't have a problem assuming you have distributed tape drives per
network "spur".

-Rudy

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 05:02:10 GMT
From:      majumdar@bgsuvax.UUCP (anindo Majumdar)
To:        comp.protocols.tcp-ip
Subject:   Blocking /non blocking


Are the sendto and recvfom calls (between datagram sockets) blocking or
non blocking? The manual says both cas return the no of bytes send/recd.
Does this mean that the call blocks untill the no of bytes specified is sent
or recd by the destination address.

E-mail (Internet) : majumdar@andy.bgsu.edu        

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 08:51:49 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Re: Blocking /non blocking

In-Reply-To:  your letter rec'd 11-MAR-1991 15:06:15.40


All the socket system calls (send, sendto, recv & recvfr ...) are blocking
calls. Blocking send means the send will be blocked if the send buffer is not
big enough (currently) to hold the data. If u choose to un-block the calls,
the system call returns whatever bytes u can put into the send buffer. For
the datagram calls, it the send data is larger than maximum set (can be
changed using setsockopt()), then the system will only send the maximum
allowed and return to u about the bytes send. Bon-blocking recv means
if there is no data present, the calls will just return -1 with errno
set EWOULDBLOCK.
Hope this helps.

- Beng Hang (email: taybengh@nusdiscs)

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 11:57:06 GMT
From:      kaba@acdhq.north.de (Kai Bartels)
To:        comp.protocols.tcp-ip
Subject:   Re: Re:  do FINs count as 1 like SYNs ?

> >Hi!
Hi!

> Kai --
> 	RFC 791 (which updated 763) describes the closing sequence pretty
> well and illustrates this case in Figure 13 (page 39).  The packet that ACKs
> the FIN will have an ACK number one greater than the FIN's sequence number.
> So, yes, the sequence number is incremented after the FIN is transmitted
> (so that ACK will == snd.NXT).
> 	You may want to also get a copy of RFC-1122 (Requirements for Internet
> hosts): this document clarifies a number of points in both the TCP and IP
> protocol specifications that have been interpreted in different (and frequently
> incompatible) ways.
Thanks a lot! This rfc1122 is really great! I think it'll help me with a
bunch (spelling?) of problems in the future.

> 				-- Frank Solensky / Clearpoint Research Corp.
greetings, Kai
--------------------
Kai Bartels    | kaba@acdhq.UUCP      | The sound of bombs
Hudemuehler 37 | kaba@acdhq.north.de  | Has given way to childrens cries
D-2800 HB 41   | G14B@DHBRRZ41.BITNET |                      <Fischer-Z>
(0421)34636-13 |g14b@sie.rz.uni-bremen.de|------------------------------
bang: {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmger!acdhq!kaba

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 13:29:28 GMT
From:      subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
To:        comp.protocols.tcp-ip
Subject:   Re: Blocking /non blocking

In article <7123@bgsuvax.UUCP> majumdar@bgsuvax.UUCP (anindo Majumdar) writes:
>
>Are the sendto and recvfom calls (between datagram sockets) blocking or
>non blocking? The manual says both cas return the no of bytes send/recd.
>Does this mean that the call blocks untill the no of bytes specified is sent
>or recd by the destination address.

I'd assume so, unless you did an fcntl(socket, F_SETFL, FNDELAY)
somewhere that would set it to non-blocking.  


			-Kartik

--
internet# find . -name core -exec cat {} \; |& tee /dev/tty*
subbarao@phoenix.Princeton.EDU -| Internet
kartik@silvertone.Princeton.EDU (NeXT mail)  
SUBBARAO@PUCC.BITNET			          - Bitnet

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 14:09:09 GMT
From:      c_rstine@HNS.COM (Robert Stine)
To:        comp.protocols.tcp-ip
Subject:   IP performance evaluation & spray


I'm evaluating the network performance of a single-board computer that
runs ethernet and TCP/IP; the board has an 82596CA LAN controller.  In
one of the tests, I use the program "spray", executed from a Sun SPARC
IPC, to see how well the board can handle high volume IP inputs.

(I have used the default settings for ICMP ECHO requests, in which
Spray hammers the target board with 1162 ICMP echo requests in frames
of 86 bytes each, sent as fast as the Sun can generate them.  Spray can
generate either RPC or ICMP traffic.  Because the board under
evaluation does not run a spray daemon, I am banging it with the ICMP traffic.)

The Sun and the target board are on the same MTU.  For the tests, I put
the MTU in loopback mode, to avoid nasty looks from other LAN users :-)

What are reasonable drop rates?  In "System Performance Tuning," Mike
Loukides suggests that the RPC drop rate should be under 5%.  Is this
also reasonable for ICMP?  I am observing drop rates considerably over
5% (e.g., over 20%).

Thanks,

Bob Stine
c_rstine@hns.com

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 14:38:02 GMT
From:      pkilllea@unix2.tcd.ie (Tom Killalea)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP implimentations for BSD 4.3 tahoe/reno

The problem...

>In <17161@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes:
>>The standard BSD 4.3 does not seem to have a 'rarpd' program
>>implimented. Is there a public version of the RARP protocol.
>running BSD 4.3, but Macs running NCSA Telnet look for rarpd to 
>dynamically get an ip number.  Apparently there isn't an rarpd implementation
>under BSD for security reasons - it doesn't like user level processes looking
>at ethernet packets.  If someone has discovered a workaround for this, other
>than assigning ip numbers for the Macs manually, I'd like to hear it.
 
The solution...

If you use MacTCP, the "server" mode first looks for Fastpath-like devices
configured to hand out dynamic addresses, then looks for a Rarp server, then
looks for a bootp server.  This works as of version 1.01.
Dan Magorian                                                    (301) 405-3004
Computer Science Center                                    magorian@ni.umd.edu

Thanks to those who replied, and in particular to Dan for the above.

Tom.
--
Tom Killalea |                          |  Trinity College
             |  pkilllea@unix2.tcd.ie   |

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 14:47:09 GMT
From:      brown@dlogics.com (Steve Brown)
To:        comp.protocols.tcp-ip
Subject:   Looking for Cheap Ethernet <-> 56/64 kb Bridge

Subject says it all.  I will summarize mail to the net.

Steve Brown
Datalogics, Inc.
441 W. Huron St.
Chicago, IL 60610
312-266-4380				brown@dlogics.com

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 14:49:37 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software for OS/2 ?

fillmore@emrcan writes:

>Has anyone made a list of available TCP/IP software packages that run under
>OS/2 and which Ethernet boards they support?
>I am aware of IBM's product but would like to know what else is available,
>including public domain software.
>Thanks in advance..
Ftp software have a product, as do 3COM and Excelan.
I can only answer for FTP which runs over any NDIS compliant driver.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 15:51:58 GMT
From:      qureshi@WSU-ENG.ENG.WAYNE.EDU (Imran U. Qureshi 7-0108)
To:        comp.protocols.tcp-ip
Subject:   (none)

I have the following setup on a ethernet:

HP9000 with 3 X-terminals booting from it.
3 VAX stations running TCP/IP and DECNET.
Cisco router with only TCP/IP turned ON.

The problems are:
1.The arp cache of both HP9000 & Cisco show the MAC address of X-Terminals 
corresponding to a VAX station.

2. I cleared the Cisco arp and tried to ping the X-terminal, the entry in the arp cache related to the X-terminal comes back with same VAX MAC address. This thing happens even if the X-Terminals are not on the network.

3. Surprisingly this process works with X-terminals booting from HP9000. The overhead is packets  going first to the router and then to HP9000. However after some hours Cisco fails to route the packets and the X-terminals lockup.

Question:

 Can the Cisco get MAC level addresses from HP9000 or from any other host when X-terminals are not on the network?

Thanks in advance	

qureshi@trace.eng.wayne.edu

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 15:53:33 GMT
From:      JAFFE@SSCVX1.SSC.GOV
To:        comp.protocols.tcp-ip
Subject:   SNMP packages for the Macintosh?


I am looking for any information on public domain software packages which allow
a Macintosh to query SNMP agents.  Pointers to possible FTP sites would be
appreciated.  Thanks in advance.

Mike Jaffe
SSC Laboratory

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 17:34:53 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: IP performance evaluation & spray


    What are reasonable drop rates?  In "System Performance Tuning," Mike
    Loukides suggests that the RPC drop rate should be under 5%.  Is this
    also reasonable for ICMP?  I am observing drop rates considerably over
    5% (e.g., over 20%).

Well, I am aware of certain high performance networking devices that
consider ICMP, and especially responding to pings, a low priority task.

Can't you spray the box with the sort of packets you would like it to
handle during its eventual normal operation?  RPC, UDP discard and TCP
discard all seem like better ideas...

BillW
-------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 17:39:26 GMT
From:      kwe@BU-IT.BU.EDU (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: bandwidth usage for X applications?


	Some people here in Information Technology at Boston
University set up a test to measure network load from one X terminal
doing specific X things.  Here is an excerpt of what they did:


       +------------+                      +--------------+
       |            |                      |              |
       | diskful    |                      | Visual       |
       | server     |                      |              |
       |            |                      | X19 turbo    |
       |            |                      |              |
       +------------+                      +--------------+
             ||                                   ||
   =================================================================
                                ||
       subnet            +--------------+
                         |              |
                         | LANalyzer    |
                         |              |
                         +--------------+


	They ran some test cases for a variety of X terminal
activities.  The only traffic on the network was traffic from the X
terminal and the diskful server, including all X traffic and some NFS
traffic for diskless font service on the X terminal.  The window
manager, twm, was running on the diskful server and not on the X
server.  All X clients are running on the diskful server.

	TEST		pkts/sec		kBytes/sec

	maze		425			30
	xterm tftpboot	303			92
	twm:
	  move win	220			18
	  resize	220			18
	  hold button	220			18
	plaid		220			17
	ico		67			12
	xbench		50			20
 2 xtermwins cat'ing	45			23
	xclock		0.0166-1		~~
	move mouse
	 out of win	3-5 pkts		~~


	These numbers from the LANalyzer measure Ethernet frame data;
source and destination MAC addresses, protocol type field, user data
payload and CRC, but do not include the preamble or interframe gap.

	For reference purposes, Ethernet at 10Mbit/sec can transfer
about 1,000 kBytes/sec of Ethernet data in maximum sized frames, after
subtracting the preamble and minimum interframe gap times.  The
maximum number of Ethernet frames per second, assuming minimum sized
legal frames, is 14,880 frames/second.

	These tests do not factor in the presence of routers between
the X terminal and server, nor do they account for the diskful server
load, given that the diskful server is bootloading, running all window
managers and all X client processes and all processes under the
clients (such as shells).  These tests do not measure actual usage
patterns.

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

	Those who really did the work:

	Mike Amirault (ambi@bu-it.bu.edu)
	Jason Heirtzler (jdh@bu-pub.bu.edu)
	Chuck von Lichtenberg (chuckles@bu-it.bu.edu)

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 18:03:16 GMT
From:      nolet@cns.SanDiego.NCR.COM (Jason Nolet)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software for OS/2 ?

In article <5B030411361603DB-MTAEMR1*fillmore@emrcan> fillmore@emrcan writes:
>Has anyone made a list of available TCP/IP software packages that run under
>OS/2 and which Ethernet boards they support?
>I am aware of IBM's product but would like to know what else is available,
>including public domain software.
>Thanks in advance..
>

I recently posted a similar query.  Here were the results (no adaptor info
though):

FTP Software V1.1 (in beta as of 2/91)
3com's 3+TCP for LAN Manager
IBM TCP/IP for Os/2 V1.1
Ungermann-Bass (this may be a rumor)
Excelan (Novell) LAN Workplace

Good luck...

/******************************************************/
/* Jason Nolet                                        */
/* Network Products Div. - San Diego, NCR Corporation */
/* email:  Jason.Nolet@SanDiego.NCR.COM               */
/* Phone:  (619) 578-9000  Fax: (619) 963-5705        */
/******************************************************/

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 19:02:28 GMT
From:      parker@mprgate.mpr.ca (Ross Parker)
To:        comp.protocols.tcp-ip
Subject:   SLIP and IP routing problem

Hi...

I'm having a routing problem with the following configuration:

2 Sun 3/260 (one with SunOS 4.0.3, the other with SunOS 4.1),
	one here in Vancouver, the other in Ottawa connected
	with a 4800 baud dedicated line
Slip 4.0
gated 1.9.1.7

I can get the two systems talking to each other just fine (with or
without gated running). However, I'm trying to configure the
network (and gated) so that other systems on my local network can
see the system in Ottawa. I'm not having much luck.

Currently, the Ottawa systems and the systems here are using the
same IP address space - both in the class B address '134.87'. I can
understand routing failing with this configuration... with only one
network address, there's nothing to route *to*. I have, however,
tried setting up the SLIP line with it's own address (we have a
class C address at our disposal, and the route to Ottawa still isn't
reachable.

Here's a diagram of the situation:

         Ottawa                                 Vancouver
        'mprott'                                'mprgate'
    ------------------                     ------------------
    |                |                     |                |
    |134.87.137.1    |                     |   134.87.131.12|
 ___|______^         |                     |          ^_____|___
    |                |                     |                |
    |      192.67.9.1|   Slip line         |192.67.9.13     |
    |          ^_____|_____________________|______^         |
    |                |                     |                |
    ------------------                     ------------------

The ethernet interfaces are on 134.87..... The slip interfaces are
the 192.67.9 addresses, and are named mprott_slip and mprgate_slip

I have added a static route to the Ottawa office through the slip line
(e.g. 'route add mprott_slip mprgate_slip 1'). Gated is running on both
ends as 'RIP supplier' (I've tried 'RIP yes' and 'RIP pointtopoint' as
well), and I can see RIP traffic going across the line. None of the
other systems in my local ethernet, however, ever see mprott_slip, even
if I add a static route to it through mprgate_slip. In fact, I have to
add a static route to mprgate_slip (through mprgate) before the
Vancouver end of the slip line is visible from my other systems. Gated
has both ends of the SLIP line set up in 'trustedripgateways' and in
'sourceripgateways'.

Can anyone suggest what I may be doing wrong? I'm hesitant to try
installing the class 'C' address on all systems in Ottawa (because it's
a pain to do) until I know that that'll solve my problem. I'm hoping
that I've just configured gated incorrectly.

Thanks,

-- 
Ross Parker			| Why do they put me down?
				| Make out that I'm a clown?
parker@mprgate.mpr.ca		| I drink scotch whisky all day long
uunet!ubc-cs!mprgate!parker	| Yeah I'm gonna save my money
				| (gonna put it all away...)
(604)293-5495			| 'Cause I'm a Scotsman

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 20:25:05 GMT
From:      cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   commercialization of the internet

A few months ago (during a discussion of Merit, Inc. and stuff)
someone mentioned a mailing list devoted to discussing the
commercialization of the internet.  Can someone send me a pointer to
this list and its archives?  I'm writing a term paper on the topic.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 91 22:39:33 GMT
From:      skunz@iastate.edu (Kunz Steven L)
To:        comp.protocols.tcp-ip
Subject:   tn3270 protocol doc

Where can I find a document outlining the tn3270 protocol?  I know that 
tn3270 uses the TCP-IP protocol as a transport medium - but what gets
transported?  Raw EBCDIC block-mode streams (as come over an IBM channel)?
What about the "start up" protocol?  It appears many micro tn3270 packages
are in line mode until something in the protocol from the host kicks them
into block mode.

We've already checked for an RFC in the "nic" RFC repository - doesn't seem
to be one.  Does the protocol standard come out of IBM?

Steve Kunz -- Iowa State University Computation Center

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 00:57:55 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   V3.2 vs V4 UDP and NFS


I seem to be having a problem with V4 systems and UDP.  It appears that
an NFS-based test between two V3.2 systems that I run shows up under
Netwatch as follows:

  	IP: src addr -> dest addr <value> UDP <value2> -> <value3> <value4>
where
	value: is some number apparently less than 1000 (but I can't prove that)
	value2: is either 2049, 1043, or 1045 (there may be others, Netwatched
		was stopped for some reason when I wrote this up)
	value3: appears to be of the same group of numbers as value2 but never

	value4: was either 104, 1152, or 124.  Those were the only values I saw.

With V4 to V4 systems its more like:
	IP: src addr -> dest addr 1500 UDP Fragment
And its *always like that.

I don't have data on what happens between V4 and V3.2 systems. 

Question:  what do these numbers mean, what does Netwatch mean by
Fragment (and how does he know its a fragment?), and why does either
Netwatch see things differently between the two scenarios or why is
there a difference?  Can it be related to the rsize/wsize default
values?  Where are these values specified?  I'm not specifying these
values in the mount command.

Comments?  Suggestions?

Michael J. Hammel        | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Recycle.  Just do it."

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 01:18:55 GMT
From:      CHAPMAN@MATHOM.CISCO.COM (John T Chapman)
To:        comp.protocols.tcp-ip
Subject:   HSSI


Eugene,

You were interested in HSSI.  HSSI stands for the High Speed Serial
Interface.  It is a serial data interface capable of running up to 52
Mbps.  The electrical signal levels are balanced ECL, and the
connector/cable used is the same as is used in SCSI-2.

HSSI was conceived and designed by cisco Systems and T3plus Networking
as an interface between cisco's router product and T3plus's DS3 DSU
product.  cisco and T3plus have put this spec forward as an open
specification for industry use.

Originally defined in October of 1989, it is now in use by over 50
companies world wide.  HSSI is becoming a defacto industry standard
for data interfaces which need to communicate to DS3 equipment, or to
other data facilities which exceed 10 Mbps.

I will send you a copy in the mail.  If anyone else would like a copy,
please contact me at the address below.  Your name will also go on a
distribution list to receive any future updates.

John T. Chapman

chapman@cisco.com

cisco Systems
1525 O'Brien Drive
Menlo Park, Ca 94555

-------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 02:47:59 GMT
From:      efb@suned1.Nswses.Navy.MIL (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   CMU/Tek 6.5-3 Config Problem

One of our neighbor sites just installed CMU/TEK 6.5-3 on his MV-II under
VMS 5.4-1 .. we gave it the name of the dns master within our Class B net,
(137.24), engsun.nswses.navy.mil ... the name / ident of the gateway etc

And the only hosts we can reach are those wired into the original install.
We have done IPNCP NETEXIT and all the other choices except reboot and still
it only talks to two hosts for which it was given hard addresses at build 
time.  It further disavows any knowledge of a nameserver on the the name
servers IP address .. it is on the net with a 255.255.0.0 mask .. can op-
erate with IP addresses but CANT resolve names .. 

CAn anyone on a similar site send us copies of their ascii files as affect 
CONFIG, IP_STARTUP, etc.  Noticed a logical for file named something like
IPNCP_CNF.... where the symbol pointed to sys$manager and the file does not
exist .. 

Any help , suggestions welcome and appreciated .. /Ev/

-- 
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 02:52:55 GMT
From:      mab@mentor.cc.purdue.edu (Mike Brown)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
Subject:   AIX & MS-DOS ports of tcpdump

Is anyone out there working on a port of tcpdump to AIX and/or MS-DOS?
I have a definite need for this (or another package with similar
capabilities) for network/protocol analysis/support/troubleshooting.

If anyone if working on this, please let me know...



Mike Brown, Network Systems Programmer		Internet: mab@cc.purdue.edu
Purdue University Computing Center		Bitnet:   xmab@purccvm
1408 ENAD, Room 130A				Phone:    (317) 494-1787
West Lafayette, IN 47907, USA			Fax:      (317) 494-0566

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 06:11:39 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: commercialization of the internet


com-priv@uu.psi.com

 A few months ago (during a discussion of Merit, Inc. and stuff)
 someone mentioned a mailing list devoted to discussing the
 commercialization of the internet.  Can someone send me a pointer to
 this list and its archives?  I'm writing a term paper on the topic.

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 06:23:19 GMT
From:      schoff@PSI.COM (Marty Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   NREN discussion mailing list


Aside from the public policy discussion on the commercialization
and privatization, there is an open mailing list to discuss
the NREN (National Research and Education Network).

Send email to

	nren-discuss-request@psi.com

to be added.

It is a high energy and volume redistribution mailing list.

Marty

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 07:50:42 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: commercialization of the internet


   A few months ago (during a discussion of Merit, Inc. and stuff)
   someone mentioned a mailing list devoted to discussing the
   commercialization of the internet.  Can someone send me a pointer to
   this list and its archives?  I'm writing a term paper on the topic.

The name of the list is "com-priv".  I don't have copy of the
description of what is supposed to be discussed on the list, but the
archives should give you a good idea.  The list is not mentioned in
the ARPANET list of lists (nisc.sri.com:/netinfo/interest-groups), nor
in any other list of mailing lists that I am aware of, so you're
forgiven for asking here rather than looking it up yourself :-)

Back issues can be ftp'd from
com-priv		uu.psi.com:/archive/com-priv/

Requests to join go to com-priv-request@uu.psi.com.

The tcp-ip mailing list gateway chews on my name, sorry.

I'd like a copy of your term paper once it's done.
-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	emv@msen.com

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 08:50:33 GMT
From:      mdb@bridge2.UUCP (Mark D. Baushke)
To:        comp.protocols.tcp-ip
Subject:   Re: UnderscoresDIR/NEW

On 2 Mar 91 23:16:51 GMT, oberman@amazon.llnl.gov said:

Kevin> In article <9103022255.AA04928@ucbvax.Berkeley.EDU>,
Kevin> dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton") writes:

> RFC 821 and 822 weren't very clear on what characters a hostname could
> contain.  RFC 952, "DOD Internet Host Table Specification" clarifies
> what characters are legal.  The legal characters are letters, numbers,
> and the hyphen, and the hostname must begin with a letter, and end with
> a letter or digit.  The exact syntax is:

[...and RFC 1123 in section 2.1 modifies RFC 952 to allow leading digits...]

Kevin> That stated, they are quite common and most implementation will
Kevin> allow them. The only problem is when you hit a system that
Kevin> doesn't. So, please follow the rules and don't use them. I
Kevin> would also recommend against numeric first characters as many
Kevin> implementation have not been changed since 1122/1123 were
Kevin> issued.

Our site (3Com.COM) has a fair amount of experience with numeric first
characters :-). 

I can say from experience that there are still hosts running software
which rejects our domain as illegal. For the most part, these machines
are either DEC-20 machines (like NIC.DDN.MIL) or IBM mainframes
(typically BITNET sites). There are upgrades for each kind floating
around, but it is sometimes difficult to fight intertia and get the
system administrators to install the new software.

If you have a choice, avoid using illegal characters in your names.
You will save yourself a large hassle.

Also, if you are designing software which checks names, be liberal in
what you accept...the rules may change again.

-- 
Mark D. Baushke
Internet: mdb@ESD.3Com.COM
UUCP:     ...!{3comvax,auspex,sun}!bridge2!mdb

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 10:14:02 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   ARP problem (was Re: (none))

In article <9103111554.AA09237@hub.eng.wayne.edu> qureshi@WSU-ENG.ENG.WAYNE.EDU (Imran U. Qureshi 7-0108) writes:
>2. I cleared the Cisco arp and tried to ping the X-terminal, the entry in
>the arp cache related to the X-terminal comes back with same VAX MAC
>address. This thing happens even if the X-Terminals are not on the network.

Sounds like the VAX is sending proxy ARP responses for some reason.
Perhaps its subnet mask isn't set properly, and it thinks the ARP requests
are for a different subnet, and it thinks it is the router to that subnet.

> Can the Cisco get MAC level addresses from HP9000 or from any other host
>when X-terminals are not on the network?

Any host can answer an ARP broadcast, whether or not the actual destination
host is on the network.  Many routers support proxy ARP, for the benefit of
hosts that don't implement subnetting; the router responds to ARP requests
for any host on one of its other interfaces, giving its own MAC address,
whether or not the destination host actually exists.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 11:29:00 GMT
From:      SCOTT@SKLIB.USASK.CA (Peter Scott/Order Unit Manager/U of Saskatchewan Library/6016)
To:        comp.protocols.tcp-ip
Subject:   Book: Internetworking with TCP/IP

Just published:

Douglas E. Comer
Internetworking with TCP/IP Volume 1: Principles, protocols, and
	architecture.
Second edition
Prentice-Hall, 1991  ISBN 0-13-468505-9.

Tells you everything you need to know about TCP/IP.

   ...................................................................
  |                    Peter Scott  .  Phone:    306-966-6016         |   
  |             Order Unit Manager  .  FAX:      306-966-6040         |   
  | Univ of Saskatchewan Libraries  .  ad079@yfn.ysu.edu              |   
  |                      Saskatoon  .  Internet: SCOTT@SKLIB.USASK.CA |   
  |   Saskatchewan, Canada S7N OWO  .  an682@cleveland.freenet.edu    |   
   ...................................................................  

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 13:20:55 GMT
From:      fbraab@leuze-owen.de (Fritz B. Raab)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   HP3000 <--> Win/TCP form MPE/V HELP !!

Has anybody already had to to with an installation or use
of Win/TCP on MPE V HP3000 ?
If so, would you please contact me ?
Our dealer here in Germany doesn't have much experience
with this product, and I don't want to throw away $ 40000...

I need to connect a HP3000 system to a UNIX network, so 
please give away your know how to me.
Thank you all,
Fritz

 (-%   Fritz B. Raab                 # email: fbraab@leuze-owen.de          %-)
 (-%   Leuze electronic, Abt. TDV    # voice: +49 7021 573185 fax: 573200   %-)
 (-%   In der Braike 1               # Member of EurOPEN, GUUG              %-)
 (-%   D7311 Owen / Teck W.Germany   #        C A R P E   D I E M  ! !      %-)

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 13:35:26 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   High speed standards

Hi all,

I was wondering if any of you could help me on the following issues.
I'm looking for technical description of some of the "new" high speed
communication standards (and any other info you have).

Of special interest are the standards used in the NSF GigaBit testbeds :

- SONET (CCITT 1988 standards , blue books ?)
- ATM
- HIPPI
- any other ?

Any info or pointers welcome.

Thanks,

Marten
--
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Phone    : +31 20 592 5102                           Amsterdam, The Netherlands

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 17:38:53 GMT
From:      kdb@macaw.intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: mac to mac ftp with NCSA Telnet 2.3?

In article <63352@eerie.acsu.Buffalo.EDU>, tksjmi@sybil.cs.Buffalo.EDU (JoAnn
Illuzzi) writes:
> Path: intercon!uupsi!rpi!zaphod.mps.ohio-state.edu!ub!tksjmi
> From: tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi)
> Newsgroups: comp.protocols.tcp-ip
> Subject: mac to mac ftp with NCSA Telnet 2.3
> Lines: 11
> Nntp-Posting-Host: sybil.cs.buffalo.edu
> Originator: tksjmi@sybil.cs.Buffalo.EDU
>
>
>  I posted this question to  telnet@ncsa.uiuc.edu on 1/22, but apparently
>  that is a dead list, I didn't receive any replies.
>
>  Does Mac NCSA Telnet support mac to mac ftps directly?  I don't want
>  to sign onto a mainframe/mini to ftp stuff between two macs.  I
>  thought ncsa telnet 2.3 had this feature, but I don't see it
>  documented.
>
>  JoAnn
>

BYU probably has what you want.  All that NCSA has is a FTP server builtin, but
others have added client capabilities to it over the years, both PD and
commercial.

BYU
InterCon
TWG
And probably others.

Hope this helps.


Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 17:42:46 GMT
From:      kdb@macaw.intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP packages for the Macintosh?

In article <910311095333.20208334@SSCVX1.SSC.GOV>, JAFFE@SSCVX1.SSC.GOV writes:
>
>
> I am looking for any information on public domain software packages which
 allow
> a Macintosh to query SNMP agents.  Pointers to possible FTP sites would be
> appreciated.  Thanks in advance.
>
> Mike Jaffe
> SSC Laboratory

I too would be interested in this, as I think that only SNMP station currently
for the Mac is our commercial one.  It would be interesting to see what PD ones
are available as well.

Kurt

Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 18:54:54 GMT
From:      jerobins@eos.ncsu.edu
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove my name from the tcp/ip relay.  I was in error when I
asked to subscribe.  I was under the impression that the service was
slightly different.
   Thank you,
		James E. Robinson, III

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 19:59:18 GMT
From:      hellwig@skipper.dfrf.nasa.gov (Oliver Hellwig )
To:        comp.protocols.tcp-ip
Subject:   Re: UDP 901 info needed

In article <9102251927.AA27889@gateway.mitre.org> hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes:
>
>In our IP trace we see UDP protocol port 901 in some datagrams.
>However, I can't find anything that tells me what protocol or system this
>might be associated with.  Has anyone come across UDP 901 before and
>can supply some info on it??
>
>Thanks in advance   -Hal.


UDP port 901 is used by an Atalkad daemon.  This daemon provides routing
information for Fastpath and Gatorbox Appletalk/IP gateways.


Oliver


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


inews fodder
inews fodder

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 20:48:00 GMT
From:      rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   Attempts to e-mail Everett Batey

Netlanders, 

	Please forgive the intrusion for such a relatively trivial matter, 
but I have attempted to e-mail responses to Everett Batey.  He has sent a 
couple of mailnotes to the list lately, namely one on SLIP and I believe 
the other was about a CMU package.  Since my mailer has bounced my responses 
back, I realize the problem is likely on my end.  However, can someone give 
me a more reliable address or perhaps a phone number for Mr. Batey?  

	My apologies to whomever may have their patience tried by this note.  
I can assure you, my patience with my mailer is wearing somewhat thin with 
this problem as well.  Why can't it be more forgiving, instead of asking me to?

						Kathy Rinehart
						Rinehart@AEDC-VAX.AF.MIL
						DSN 340-3899 COM (615) 454-3899

	P. S. (Technical-ese gives way to human-ese in paragraph 2.)

	P. P. S.  Thanks to all netlanders for patience and/or help.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 20:53:49 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: Book: Internetworking with TCP/IP

SCOTT@SKLIB.USASK.CA (Peter Scott/Order Unit Manager/U of Saskatchewan Library/6016) writes:
>Just published:
>
>Douglas E. Comer
>Internetworking with TCP/IP Volume 1: Principles, protocols, and
>	architecture.
>Second edition
>Prentice-Hall, 1991  ISBN 0-13-468505-9.
>
>Tells you everything you need to know about TCP/IP.

I have a copy on my desk, and am waiting patiently for the copy of _Volume_2:_
_Implementation_and_Internals_ to show up so that it will tell me everything
_else_ I need to know about TCP/IP....

-Johnny Book

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 21:07:07 GMT
From:      dhuber@aut.autelca.ascom.ch (Daniel Huber)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.terminals
Subject:   WANTED: map3270 entries for a bunch of terminals


Hi

Sorry for crossposting....

I'm searching for a few initial terminal (keyboard) entries for 
the /etc/map3270 file. This file is read by tn3270 on startup...

The following keyboards are in use at our site and I need their entries
in the map3270 file:

- xterm (X11, NCD 101)
- hpterm (X11)
- hp700/92
- hp 300h
- freedom200
- sun (all sun keyboards)

If sombody could mail me their own keyboard mapping for the keyboards
above, I would be very happy :-)
I would not like to write each mapping by myself, since I have bearily
time for it (altough I would do it).

Thanks.

Daniel

-- 
Daniel Huber AD-KT2.6   VOICE: +41 31 52 96 64 FAX: +41 31 52 97 51
Ascom Autelca AG        Network Engineer, Network,Mail and News Manager
CH-3073 Guemligen       EMAIL:  dhuber@autelca.ascom.ch
Switzerland             UUCP:   uunet!chx400!hslrswi!aut!dhuber

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 21:31:04 GMT
From:      phillip@BARTAL.COM (Phillip M. Vogel)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   flakey network (HELP!!!)

We are experiencing a strrange problem on our network.  Transfers
between {"UNIX-2" or "UNIX-3"} and "UNIX-1" are often corrupted.

Transfers over *ANY* other path work fine. This includes
transfers from "UNIX-4" to "UNIX-1" which pass through both
interfaces on "UNIX-2"; "UNIX-2 to "UNIX-4"; "UNIX-2" to internet
sites; and every other path we have tried.

The corruption occurs during FTP and NNTP transfers.  The nature
of the corruption appears to be bad tcp packets repeated along
with the correct packet. This leads to a file approximately 120
to 300 bytes larger than the original. 

Software on unix systems is:
Interactive Unix 2.2.1  and  TCP/IP 1.2.0 update SSU.4a.

It's a real hair puller here, so we turn to the net for help.
Any takers?


                       Thin Ethernet #1
----+--------------------+----------------------+---------------
    | WD8003EBT          | WD8003EBT            |
    |                    |                      |
 +--------+          +----------+           +----------+
| UNIX-1 |          | 10MHz XT |           | Proteon  |-------> Slip 9.6K Link
| 386/20 |          | PC-ROUTE |           | P4100+   |         To Internet
+--------+          +----------+           +----------+
                         |
                         | SLIP 19.2K V.32/V.42
                         | Both routers have 16550's
                         |
                    +----------+
                    | 8MHz  XT |
                    | PC-Route |
                    +----------+
                         |
                         | WD8003E           Thin Ethernet #2
----+-------------+------+------+--------------------------------
    | WD8003E     | WD8003E     |
    |             |             |
 +--------+    +--------+   +-----------+
| UNIX-2 |    | UNIX-3 |   | 12 MHz AT |
| 386/20 |    | 386/20 |   |  PC/TCP   |
 +--------+    +--------+   +-----------+
    |
    | SLIP 19.2K PEP, both ends have 16550's
    |
 +--------+   +-----------+   
| UNIX-4 |   | 10 MHz AT |
| 386/20 |   |  PC/TCP   |
 +--------+   +-----------+
    |             |
    | WD8003EBT   | WD8003E
----+-------------+-------------
     Thin Ethernet #3

--
Phillip M. Vogel, President             | #include "/disclaimers/std.h"
Bartal Design Group, Inc.               | phillip@bartal.com
318 Marlboro Road, Englewood, NJ 07631  | (201)567-1343   FAX:(201)568-2891

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 22:38:27 GMT
From:      phil@shl.com (Phil Trubey)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: TELNET slow through bridge.

In an earlier posting to comp.dcom.lans, I mentioned a problem we were
having telneting to an HP 3000 through a bridge using PC/TCP.  Well, it
turns out that the problem is not related to the bridge, and is actually
composed of three separate problems.

The original problem was that telneting from PC/TCP on a PC to the HP 3000
would occationally slow way down when the HP was outputing lots of text
to the PC's screen.  In the middle of transmission, it would start to display
one line at a time every four seconds.

With a protocol analyzer we were able to determine what was going on.

The problem occurs when the PC drops a packet.  The HP doesn't realize
that this has occured, of course, and merrily blasts the TCP window size
number of bytes to the PC.  The PC meanwhile keeps sending an ACK that
acks everything up to the dropped packet.  So far so good.  The HP 
realizes that the PC has dropped a packet when its timeout timer
kicks in (4 seconds later).  It then proceeds to retransmit the
dropped packet and just the dropped packet.  The PC, not having kept
the packets after the dropped packet, calmly acks the retransmitted
packet from the HP and waits for the HP to send the rest of the packets.
The HP waits for another retransmission interval and then retransmits
the next packet that it had sent.  This continues until the HP has sent
all outstanding packets - at a rate of one every four seconds.

Questions:

1. Is it normal for PC TCP implementations to drop packets fairly
frequently?  Ie about one packet every 100 or so?

2. The original TCP spec seems to be silent here, but surely this can't 
be the 'standard' way retransmission works?  I would have though that
the retransmitter would send all outstanding packets all at once after
an ack timeout, rather than one packet every timeout interval, the way
the HP 3000 does.

3. Is it normal for TCP implementations to discard all out of sequence
packets?

Thanks for any info!

-- 
Phil Trubey                     |  Internet: phil@shl.com      
SHL Systemhouse Inc.            |  UUCP:     ...!uunet!shl!phil
50 O'Connor St., Suite 501      |  Phone:    613-236-6604 x667
Ottawa, Ontario, Canada         |  Fax:      613-236-2043

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 91 23:55:36 GMT
From:      montjoy@babbage.ece.uc.edu (Robert Montjoy)
To:        comp.protocols.tcp-ip
Subject:   Packet Sizes


Hi.

Can some one give me an idea on packet sizes of various things.

I am doing network monitering for the frist time can some tell 
me what is in a 60 Byte packet(in general)(note our network
has 35% 60 byte packets,is that good or bad). Are they mostily
broadcasts. 


How can you tell if you have to many broadcasts. 

Thanks.

Rob Montjoy
--
Rob Montjoy                   		- Rob.Montjoy@UC.Edu
Computer Engineer    	      		- montjoy@ucbeh.BITNET
University of Cincinnati      		- montjoy@babbage.ece.uc.edu
Electrical and Computer Enginering	- uunet!uceng!rmontjoy

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 02:17:41 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   TCP and long pauses

While investigating a curious problem on some DECstations and AIX
systems connected via some modems and a SLIP link, I ran across
a curious feature (?) of TCP that perhaps someone here can explain.

The problem was that, although the link seemed up and alive, and
all UDP-absed applications (ping, tftp, NFS, among others) seemed
to work just fine, all TCP-based applications were subject to long
pauses.  There seemed to be a 4K size somehow involved, and roughly
a 2-minute timeout.

One scenario is illustrative:  We put line monitors on both serial
ports, and did an rlogin across the link.  So far, so good.  We 
cd'ed to a big directory and typed "ls -l".  The listing started
to appear in the window, ran for a few pages, and halted in its
tracks.  Looking at the monitor, we could see that about 4K more
data had been delivered than had appeared on the screen.  After
about 2 minutes, the last 4K was retransmitted, and everything
ran fine for a while, until it stopped again.

In reading through several documents on the subject (including Comer's
famous book), it eventually struck me that perhaps this behavior is
implicit in TCP.  All the texts describe a sliding window protocol,
in which the ACKs include the number of bytes correctly received.
Suppose that the first packet in the window is garbled, and all the
rest get though OK.  The receiver can't send any ACKs, because it
hasn't correctly received the first packet in the window.  So it sits,
hoping that the sender will remember to send that first packet.  After
a while, the sender times out the ACK, and retransmits the first packet,
which is dutifully ACKed by the receiver.  But meanwhile, the sender
sees that the second packet has also timed, out, and retransmits it,
etc.  Given the speeds of processors and networks, it is pretty much
guaranteed that the entire window will be queued for retransmission
before an ACK is received.  It's unlikely that many implementations 
have a method for deleting ACKed packets from the send queue, so they 
all get sent.

Comer and others also describe somewhat vaguely a dynamic scheme for
adjusting the timeout interval.  It seems that on a slow link such as
a 9600-baud modem, a 2-minute timeout is a fairly reasonable value for
this scheme to produce.  This implies that such long pauses are part
of TCP's normal behaviour, and there's probably not much I can do to
correct the problem, which pretty much makes most TCP-based tools
unusable across a SLIP link.  (It's amusing that NFS+cp works, but
ftp doesn't.)

Any comments?  I'd sure like to hear that I'm wrong.  Even better,
I'd like to hear about tools that might exist (or which I might be
able to implement with the right information) to correct the problem.

For instance, I'm not at all shy about opening /dev/kmem, lseeking to
some place that nlist() has told me about, and writing a new value in
the appropriate bytes.  If there's a way to dig out the kernel's values
that control the timeout, I can certainly zap them.  But so far my
perusing TFM and /usr/include/*/*.h haven't turned up any hints as
to where the timeout value might be hidden.  I suspect that it isn't
actually stored in one place, but is an implicit value that is some
function of several variables.  Not having access to the source is
somewhat limiting at this point...

(Responding via email might be helpful, as I'm about 200 articles
behind in this newsgroup.  ;-)

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 02:34:13 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   802.2 issues

Here are several 802.2 issues I could use some help with. Any info
would be appreciated:

1) The 1985 IEEE 802.2 standard book says that "A number of LSAP code
points have been identified for particular uses. A list of these code
points can be obtained from the IEEE standards office". Does anyone
have a list of these handy?

2) I know informally about the SAP "AA", which goes with a SNAP
discriminator. Is "AA" one of these code points? Where can I find a
formal description of the "AA" SAP and SNAP?

3) What SNAPs have been defined to date?

4) Is there any public domain Unix software for 802.2 monitoring on a mixed
ethernet/tcp-ip and 802.2/802.3 lan. I regularly use tcpdump, nnstat,
nfswatch, and etherfind on a Sun to monitor the ethernet traffic, but
don't have a good way to sort out the 802.2 traffic at the same time.


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

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 02:57:19 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   ow is the object-id address space managed?

Here's my silly question of the day:  If I wanted to use some
object identifier for a private MIB of my own, who would I
ask to be apportioned a branch of the tree?

I'm involved in a couple of project that would like to use
ASN.1 encoding, and we're having fun trying to learn how you 
go about doing that.  One problem is that I'd like to make 
up a set of small examples for teaching purposes, and the
examples shouldn't use someone else's MIB variables.  It
seems what we need is one or more portions of the address
tree that are called object identifiers.  Various docs have
examples of them, including several variants of SNMP, CMIP,
etc.  Can someone summarize how this address space is apportioned?

One possibility is that we could go to the SNMP people and ask
to use a branch off their tree.  This might work, because we
are building SNMP agents, anong other things.  But then again,
they might react to our request by saying that it has absolutely
nothing to do with SNMP, and we should ask somewhere else.

It looks like there is probably a tree of authorities, with ISO
at the root, assorted mysterious international and national agencies
at the next levels, maybe a few companies dangling from branches,
and so on.  So if I or some other gang of hackers wanted to hang
their own personal ornament on the tree, where would we go to get
permission?

Responses will probably all end up in a doc for a course...

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 05:38:18 GMT
From:      tsudik@pollux.usc.edu (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Sizes

If I recall correctly, 60 byte packet are usually generated by 
TELNET.

Gene Tsudik
USC

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 14:29:54 GMT
From:      haugen@bulus3bma.com (John M. Haugen)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Support for FTP Software's PDS Spec?

There is an interesting article in The Feb 1991 issue of LAN Technology about
supporting two connections through one card. One connection would be to the
Novell world, the other being to the TCP/IP world.  In the article, there
is mention of FTP Software's Packet Driver Specification (PDS). This format
is supported by Clarkson and BYU code.  My question is if Sun's PC-NFS supports
this specification or does anyone else?

Thanks

John M. Haugen              Domain:  haugen@bma.com
Bull Micral of America      UUCP:    ...!uunet!bulus3!haugen
900 Long Lake Road          ATT:  612-633-5660
New Brighton, MN  55112-6400

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 18:15:28 GMT
From:      majumdar@bgsuvax.UUCP (anindo Majumdar)
To:        comp.protocols.tcp-ip
Subject:   Any way of sending an interrupt to a program whenever message arrives in socket

Is there anyway an interrupt can be sent to a program whenever a message
intended for it arrives on a socket?Is there a standard signal available in
Berkeley 4.2 BSD Unix for such an interrupt ?Basically I do not want to wait
on a recvfrom call.At the same time I would like to handle any messages.(A recvfrom call with a non blocking option set doesn't help as it returns an error
E_WOULDBLOCK if there are no messages when the recvfom is executed).Any pointers will be appreciated.

Internet : majumdar@andy.bgsu.edu

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 19:56:00 GMT
From:      JOHNGALT@CCIT.ARIZONA.EDU ("Dr Galt, I presume?")
To:        comp.protocols.tcp-ip
Subject:   Re: Book: Internetworking with TCP/IP

>Just published:
> 
>Douglas E. Comer
>Internetworking with TCP/IP Volume 1: Principles, protocols, and
>	architecture.
>Second edition
>Prentice-Hall, 1991  ISBN 0-13-468505-9.
>
>Tells you everything you need to know about TCP/IP.

  I hate books!  Just when you buy one, they come out with a new edition!
  Why can't we get change files to books?  Or trade-in allowances.
  This is an excellent book!  I will be buying the second edition.
  Anybody want a copy of the first edition, cheap?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  "Dr. John Galt"                Internet : johngalt@ccit.arizona.edu   %
%  University of Arizona          BITNET   : johngalt@arizrvax           %
%  P.O. Box 3328                  Voice    : (602) 623-5444              %
%  Tucson, AZ 85722                                                      %
%                                                                        %
%  I shared a room in New Orleans with Ray Kaplan!  (See info-VAX)       %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 91 20:09:33 GMT
From:      jeffv@bisco.kodak.com (Jeff Van Epps)
To:        comp.protocols.tcp-ip
Subject:   Archive Site?  SunOS TCP Speedup?

The performance we're getting from TCP under SunOS 4.1 on a Sparc IPC
is somewhat less than optimal.  In the book _UNIX Network Programming_,
reference is made to Usenet messages in comp.protocols.tcp-ip in 1988
from a V. Jacobson describing improvements to SunOS TCP.  I seek education
regarding these improvements.

	Were they ever included in SunOS?
	What exactly gets tweaked?
	What if any side effects do they have?

The message-id is given in the book's Bibliography, but I haven't been
able to find an archive site holding old comp.protocols.tcp-ip messages.
Can anyone point me to these messages?

[ I hope you'll forgive me if this is a common inquiry, but I don't normally
  read this newsgroup and I didn't see a FAQ posting within the last 680
  messages. ]

-- 
If the From: line says nobody@kodak.com, don't believe it.

    Jeff Van Epps          jeffv@bisco.kodak.com
                           rochester!kodak!bisco!jeffv

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 00:47:42 GMT
From:      brad@cerberus.bhpese.oz.au (Brad Keifer)
To:        comp.protocols.tcp-ip
Subject:   What is tn3270 and where can I get source.

I am curious as to what tn3270 is.
Does it take 3270 data streams as I/O and convert this to display on a users
terminal.
If it performs a similiar function to this can somebody tell me an ftp site
for the source. I am looking at running this on a UNIX SVR3 system, with BSD
hooks.
Thanks.
-- 
Brad Keifer, BHP Information Technology, Newcastle Region, Australia
internet: brad@bhpese.oz.au      	Phone: +61 49 402126

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 02:06:22 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP packages for the Macintosh?

Quoting from today's MacLeak:

"Much to the delight of network managers and developers, Apple has dropped
its plans for a proprietary network-management scheme and switched to an
industry standard (i.e. SNMP). [...]".

We might see something in this area after all. The same article mentions
Intercon's SNMP net monitor "WatchTower", due out in May 91. 
-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 02:12:58 GMT
From:      kevinr@tandem.Tandem.COM (Kevin J. Rowett)
To:        comp.protocols.tcp-ip
Subject:   Re: Tandem 6530 terminal emulator (tn6530?)

In article <1991Feb23.154759.6918@dramba.neis.oz>, janm@dramba.neis.oz (Jan Mikkelsen) writes:
|> 
|> While on the subject of Tandem 6530 terminal emulators, does anyone know
|> of a 6530 emulator with IXF file transfer for Unix?  Any flavour, but
|> preferably System V, rel 2 or 3.

Just use FTP.  If your on a UNIX box doing 6530 emulation, you must be
using a TCP/IP on a Tandem, hence you've got access to FTP.

kevinr@tandem.com

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 02:50:00 GMT
From:      SCOTT@SKLIB.USASK.CA (Peter Scott/Order Unit Manager/U of Saskatchewan Library/6016)
To:        comp.protocols.tcp-ip
Subject:   Re: Book: Internetworking with TCP/IP

In response to those people who pointed out that Comer's book was not 
"new", I should have said it was new to me.
 
Be that as it may, you might like to know that volume II will be 
published  April 4th, with the sub-title "Details, Implementation, and 
Internals"

Peter Scott

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 04:43:19 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: TELNET slow through bridge.

>In an earlier posting to comp.dcom.lans, I mentioned a problem we were
>having telneting to an HP 3000 through a bridge using PC/TCP.  Well, it
>turns out that the problem is not related to the bridge, and is actually
>composed of three separate problems.
>
><<problem description deleted>>
>Questions:
>
>1. Is it normal for PC TCP implementations to drop packets fairly
>frequently?  Ie about one packet every 100 or so?
>

It depends on a number of factors - not the least of which is the PC's
interface...

>2. The original TCP spec seems to be silent here, but surely this can't 
>be the 'standard' way retransmission works?  I would have though that
>the retransmitter would send all outstanding packets all at once after
>an ack timeout, rather than one packet every timeout interval, the way
>the HP 3000 does.
>

Eghads NO! !-) If you were to do that, it would be asking for your
network to go into congestive collapse ;-( When that timer pops (the
first one at least...) the ONLY thing that you can surmise is that the
first packet was lost - you really do not know if any of the other
packets were lost. When (if) you upgrade the MPE/V systems to an XL,
you will find that the XL code is much better in its handling of those
situations (it started-out like the V code, but I changed it ;-) It
does NOT do batch-rtx, but will clear-out the rtxq much faster than
the V code will.

>3. Is it normal for TCP implementations to discard all out of sequence
>packets?
>

Only on little systems like PC's where there is not much memory for
the TCP code to hold onto. I think that newer PC code might be better
though. 

>Thanks for any info!
>
no problem, I live to defend the honor of the MPE networking code ;-)

___   _  ___
|__) /_\  |    Richard Anders Jones   | HP-UX   Networking   Performance
| \_/   \_/    Hewlett-Packard  Co.   | Was:  MPE/XL  Networking  Person
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 08:10:26 GMT
From:      fbraab@leuze-owen.de (Fritz B. Raab)
To:        comp.protocols.tcp-ip
Subject:   Email address of Wollongong Inc., please !

Hello, can someone mail or post the email address of
Wollongong Inc, California, please ?

Thank you,
Fritz

 (-%   Fritz B. Raab                 # email: fbraab@leuze-owen.de          %-)
 (-%   Leuze electronic, Abt. TDV    # voice: +49 7021 573185 fax: 573200   %-)
 (-%   In der Braike 1               # Member of EurOPEN, GUUG              %-)
 (-%   D7311 Owen / Teck W.Germany   #        C A R P E   D I E M  ! !      %-)

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 13:52:00 GMT
From:      rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   Attempts to find Everett Batey (Thanks)


Dear helpful netlanders, 

	Thank you for your responses to my query regarding attempts to 
find Everett 
Batey.  I have received several helpful suggestions.  Once 
again, people are helpful in assisting a novice Internetter (spelling?) 
with directions thru what can seem to be a maze on occasion.  

	Thanks again.

						Kathy Rinehart
						Rinehart@AEDC-VAX.AF.MIL

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 14:09:35 GMT
From:      ram@attcan.UUCP (Richard Meesters)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Re: WIN-TCP Problem on 3B2/500

In article <1991Feb27.220337.29559@cbnewsj.att.com>, duckie@cbnewsj.att.com (john.c.mc millan) writes:
> 	- TCP under WIN/3Br3.2 seems to be argumentative with
> 		earlier releases: rumor has it that as a result
> 		of fixing a long-term bug regarding window-sizing,
> 		negotiation-arguments occasionally erupt between
> 		3.2 systems and earlier ones.  I've seen 99% of
> 		system CPU disappear for 30 minutes running.
> 
> 		It's possible the now-available version has
> 		employed some strategy to counter this, but I'd
> 		confirm that, or convert all your 3B2's AND 386's
> 		at one time!  We did convert, and we're quite
> 		enthusiastic about the result.
> 

I was wondering if the version you were running was the original version I 
obtained from the States.  But this confirms it.  The release version of
WIN TCP 3.2 has a switch in /etc/master.d/tcp caled 42COMPAT (or COMPAT42,
I can't remember which way around) that defaults to the BSD4.2 window size.
If you're going to run a network with 3.2 and 3.01 TCP/IP intermixed, you 
_have_ to set this and rebuild the system (Defaults to unset 42COMPAT = 0).

Regards,

------------------------------------------------------------------------------
     Richard A Meesters                |
     Technical Support Specialist      |     Insert std.logo here
     AT&T Canada                       |
                                       |     "Waste is a terrible thing
     ATTMAIL: ....attmail!rmeesters    |      to mind...clean up your act"
     UUCP:  ...att!attcan!ram          |
------------------------------------------------------------------------------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 14:21:39 GMT
From:      palter@cs.Buffalo.EDU (Bill Palter)
To:        comp.protocols.tcp-ip
Subject:   Re: Email address of Wollongong Inc., please !


In article <1863@leuze-owen.de>, fbraab@leuze-owen.de (Fritz B. Raab) writes:
|> Hello, can someone mail or post the email address of
|> Wollongong Inc, California, please ?
|> 
|> Thank you,
|> Fritz
|> 

	Who at Wollongong do you want to get in touch with, their domain name
is twg.com. 

Bill Palter
Palter@twg.com

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 14:26:23 GMT
From:      DASCHER@BROWNVM.BROWN.EDU (David Ascher)
To:        comp.protocols.tcp-ip
Subject:   Bug in Berkeley popper

This is very important to all people using popper as a pop server.
reposted from comp.sys.mac.comm.


   From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
   Newsgroups: comp.sys.mac.comm
   Date: 13 Mar 91 21:51:51 GMT
   References: <DA.91Mar8111526@igor.cs.brown.edu>
 <1991Mar8.185229.20456@ux1.cso.uiuc.edu> <1991Mar9.002825.5868@parc.xerox.com>
   Sender: usenet@ux1.cso.uiuc.edu (News)
   Organization: University of Illinois at U-C
   Lines: 22


   I give up.  No response out of Berkeley, so...

   You can all have my version of popper, which is a slightly hacked 1.7b4.
   Anonymous ftp to pequod.cso.uiuc.edu, and get pub/popper1.7b4.tar.Z.

   If you are running popper version 1.6, YOU NEED THIS POPPER.
   If you are running popper version 1.7 (actually, 1.7b5 or later), YOU NEED
   THIS POPPER.

   Version 1.6 can corrupt maildrops, and 1.7b5 and later will very happily
   lose all your mail if anything goes wrong during a network connection.
   (UNIX gurus may be able to get it back from /usr/spool/mail/.popYOURLOGIN).

   I have had NO problems with popper1.7b4.

   Yes, I know I'm probably violating some copyright.  I wouldn't do it if
   the bugs were not so serious, and I will withdraw this version of popper
   as soon as Berkeley puts a fixed version on their server.
   --
   Steve Dorner, U of Illinois Computing Services Office
   Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 14:36:00 GMT
From:      JIM@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)


>>Just published:
>> 
>>Douglas E. Comer
>>Internetworking with TCP/IP Volume 1: Principles, protocols, and
>>	architecture.
>>Second edition
>>Prentice-Hall, 1991  ISBN 0-13-468505-9.
>>
>>Tells you everything you need to know about TCP/IP.
>
>  I hate books!  Just when you buy one, they come out with a new edition!
>  Why can't we get change files to books?  Or trade-in allowances.
>  This is an excellent book!  I will be buying the second edition.
>  Anybody want a copy of the first edition, cheap?

Anybody who brought Comer's first edition 6months before the second
edition came out should ask for a rebate from Prentice-Hall.  Sometimes It 
hard to convience the wife that spending another 50 dollars is really worth 
it.


jim

jrjones@alex.stkate.edu

612-690-6856

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 16:36:27 GMT
From:      sean@NISD.CAM.UNISYS.COM (Sean Kirkpatrick)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove my name from the tcp/ip relay.

Sean R. Kirkpatrick

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 20:51:34 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 protocol doc

There is no document that defines TN3270 as such.  The upper-layer HRRFC
(1123) has a really basic explanation of block-mode Telnet, but that's
all.  There has never been an RFC because most of the community that uses
it feels that it is inferior, and needs to be updated to reflect advances
in IBM system software and terminal functions.  RFC 1041 represents an
attempt at this, but it has never been widely implemented.  There is
occasional discussion of revising it on "tn3270@terminus.umd.edu" and
at IETFs.

Here's a summary of the current protocol:

Both Telnets agree on the Terminal Type option, then the client sends
a terminal type of IBM327x-y (see RFCs 1091 and 1060).

You may agree upon the Telnet EOR option, but there are implementations
out there that don't, so don't insist.

When you agree upon Telnet Binary, the data stream switches to EBCDIC, with
3270 command codes and AID bytes at the beginning of each block and buffer
orders mixed with the data, using IAC EOR as end-of-block delimiter.

If either side disables Telnet BInary, back to NVT until it is re-enabled.

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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 91 21:55:57 GMT
From:      barron@desci.wharton.upenn.edu (Daniel Barron)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   Wanted: and INT14 redirector

Hi, folks...

I'm looking for a program that will allow you to redirect INT14 to
an ethernet board, so you can use something like kermit over the
board.  I've been told public domain or shareware versions exist, but
I've looked to no avail.

If you can send one to give me a pointer I'd appreciate it.  Please
use e-mail, and I will post a summary if warranted.

Thanks in advance,
Dan

-- 
_______________________________Daniel Barron__________________________________
                                     | E-mail: barron@scrolls.wharton.upenn.edu
"Hunger only for a taste of justice. |         barron@wharton.upenn.edu        
 Hunger only for a word of truth."   |         barron@rm105serve.sas.upenn.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 01:36:03 GMT
From:      garvey@johnny5.uucp (Joe Garvey)
To:        comp.protocols.tcp-ip
Subject:   Making terminal servers just like internal serial ports

It seems to me that with all the Sun accessories that live off the SCSI
bus, that someone in the terminal server market should be doing something
similar.

I'd have loved to have a terminal server, where I had actual device files
on my system to address individual serial ports.

It seems to me that you could do this with psuedo-ttys and a daemon that
monitored the slave side of these devices.

The real problem would come when you needed so set the baud rate or
handshaking mode. The actual flow of bits would be pretty simple.

Why doesn't anyone do this? Is there a protocol under developement?

I have seen an add for the Annex III. It claims something like this...
anyone know more?


-- 

Joe Garvey                       uucp: sumax!quick!johnny5!garvey
J5 Research                      map entries are wrong for johnny5. They're
Bothell, Wa.                     being fixed. Please use address above.

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 02:17:39 GMT
From:      smitty@essnj1.ESSNJAY.COM (Hibbard T. Smith JR)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   FTP ISC 2.2 Woes.

At a particulr site, we have 4 systems running ISC 2.2.  2 of them are
33 Mhz. 386 ALR's, 1 is an Intel 25 Mhz 386 , and the new one is a 33 Mhz 486 
ALR power cache 4/e.  They all use Adaptec 1542-a/b host adapters to run
disks and an Archive 2150s tape drive.  For network support, they all use
3-COMM 3C503 (Etherlink 2) cards.  The first 3 work great, reliable networking
and all, including FTP.  The new one's FTP server doesn't work at all.  
You can log into it from another machine, but you can't do anything which
requires an outbound data transfer.  The message seen at the client is:

	"421 Service not supported.  Server disconnected"

Inbound traffic works fine, and running the server at another machine to
this client is also fine.  All other networking appears to work fine.

We have torn apart all the config files and can't find any errors.  We're
running FTPD from INETD with the -d and -l options.  No error messages
appear in the errlog or message files.

Multi User Systems (our distributor in Hollis NH) says "must be hardware".
I'm willing to buy that as a possibility, but what hardware?  I also
believe hardware's unlikely since NFS and rcp file xfers work fine both
ways, and use all the same hardware paths.  I have personally moved ~200
MB of data to this system with NFS (mounted file systems). The software is
identical on all the affected systems also. 

I'd sure appreciate any help or advice on this one, as I'm about out of
ideas. ;-(  Thanks in advance for any and all help.
-- 
		Smitty
-------------------------------------------
Hibbard T. Smith JR                 smitty@essnj1.ESSNJAY.COM	
ESSNJAY Systems Inc.                uunet!hsi!essnj1!smitty

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 03:20:05 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital phones for SLIP circuits

In article <8204@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey II) writes:
>- We have access to a four wire metallic circuit, not conditioned.  Is
>there an economical, recent or old, technology four wire modem YOU USE to
>support 9600 baud SLIP ?

You can go at 19.2K or 9.6K using a pair of Gandalf LDS309A short haul modems.
I used them quite successfully for two years plugged into an Annex
terminal server as my SLIP host until I upgraded to a faster technology.
I've got a pair of them sitting unused here.  Interested?

>- We have some available Telebit modems, no two alike and NO T2500.  Dont
>think any are the newer of V32/V42 which ever that is.  The last neighbor we
>knew using these a 200 mile dialup phone path spent lots of time restarting
>the circuit.  Is there a good way to use these locally over an analog
>delivered voice grade phone line ?

At least the TB2500 has a leased line option (don't recall about the others).
The TB2500 in V.32 mode works well for voice-grade analog leased lines,
but the line turnaround time necessary in PEP mode (all that's available
with the TB+) is not very desirable.

>- How would YOU rate from YOUR PERSONAL experience these options, for cost
>effectiveness and ease ( idiot-proof-ness ) of installation ?

A pair of LDS309A's using a metallic (LADS) circuit comes very close to
idiot proof.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 03:31:44 GMT
From:      jdh@bu-pub.bu.edu (Jason Heirtzler)
To:        comp.protocols.tcp-ip
Subject:   how to control the size of TCP packets in BSD 4.3?


In BSD 4.3 TCP (SunOS/Irix/whatever), is there an easy way to force a write(2) to
immediately push a packet out to the network?  It looks like the kernel wants to
buffer things and some analysis with our network analyzer confirms that large packets
are always being sent (~1500 bytes, which you would expect) regardless of the length
given to the write(2) system call.  Attempts to convince it otherwise, with fsync(2),
or send(2) have no effect.  If I use setsockopt(2) and change SO_SNDBUF it will force
small packets to be sent over the wire, but it seems to also have the undesirable side
effect of reducing the size of what's buffered inside the kernel as well, since then
performance is terrible (more than I guess it should be.)

The reason is that I need to control the size of packets going over the wire (at this
point I'm not real concerned about the size of the various headers) is to do various
performance tests on throughput.

Thanks for your help,

Jason Heirtzler

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 07:51:55 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sources.wanted
Subject:   Wanted lpr server ........

I'm looking for some sort of a print server that I can compile to run
on SCO unix and SCO xenix.   What I am trying to do is to be able
to send a print request to a queue on another machine.   Something
that will also accept print jobs from cutcp's remote printing 
facility would be usefull.

The sco-tcpip package documentation suggests something like:

	cat filename |rcmd machinename lp 

but this is not really the way I wanted to do it.

		
		Thanks,
			Stuart Szabo
			sgs@rand.mel.cocam.oz.au

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 10:19:02 GMT
From:      jlp@hamblin.math.byu.edu (Jan L. Peterson)
To:        comp.protocols.tcp-ip
Subject:   Re: mac to mac ftp with NCSA Telnet 2.3?

Simple solution:  use BYU Telnet 2.3.4.  This is NCSA Telnet with the
ability to do client ftp added in.  Contact Jim Logan
(loganj@yvax.byu.edu) for more information.

	-jan-
--
        Jan L. Peterson		Network Systems Manager
EMail:  jlp@hamblin.math.byu.edu
Mail:   Math Department -- 292 TMCB; BYU; Provo, UT 84602 (USA)
Phone:  +1 801 378 2183		FAX:  +1 801 378 2800

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 15:39:07 GMT
From:      griff@Xylogics.COM (Scott Griffiths)
To:        comp.protocols.tcp-ip
Subject:   Re: Making terminal servers just like internal serial ports


I tried to respond to Joe Garvey directly but the mail kept bouncing so I
decided to post this here.

For some time now, the Xylogics family of terminal servers has provided a host
based utility called rtelnet (reverse telnet). This program allows the user 
to specify a /dev/device_name entry for use with applications which are used 
to talking to /dev/tty types of devices. A data path is set up between 
the host and a specified port on the terminal server so these applications 
work without modification. The most often used applications are for printers 
and modems on the network (lpd, cu, tip and uucp).

The utility actually works as follows. A free pty is found and reserved for
use (by opening the master side). The user specified device name is linked to 
the corresponding slave device. Finally, a telnet connection is opened between
the host and the specified terminal server port.

Please let me know if you need any more information on this capability.

Scott Griffiths					phone: (617) 272-8140
Xylogics Annex Technical Support		email: griff@xylogics.com
-- 

Scott Griffiths					phone: (617) 272-8140
Xylogics Annex Technical Support		email: griff@xylogics.com

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 16:09:29 GMT
From:      roelofjs@bssi.nl (Roelof Jan Sneep)
To:        comp.sources.wanted,comp.os.msdos.misc,comp.protocols.tcp-ip
Subject:   Extended File Transfer (EFX) wanted

There should be a file transfer protocol called EFX. Does anybody know what it
is and where I can find it?

Thanks!
-- 
Roelof Jan Sneep
roelofjs@hp.bssi.nl
..!uunet!mcvax!hp4nl!bssi!hp!roelofjs

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 16:23:48 GMT
From:      phil@shl.com (Phil Trubey)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Summary: TCP retransmission questions (Was Telnet slow through bridge)

Thanks to all those that replied to me questions about TCP/IP retransmissions
relating to the interop problem we've been having regarding getting a
PC telneting robustly to an HP 3000.

I've put together a summary of what I've received for your general edification.

As an update: There exists patches to the HP 3000 software to do fast
retransmission and we are tracking down these patches.  The Win/TCP
software for PCs used to hold onto
out of sequence packets in an earlier release, but they dropped
this feature in the latest release due to memory constraints!

Even if I'm (currently) no further along than before, at least I know
more!  Thanks a lot to all those that responded!

---

1. Is it normal for PCs to drop packets...

The consensus here seems to be: yes - depending on the ethernet board
you're using.  I was using a 3Com 3c523 (microchannel).  At some point
I'm going to try using a Western Digital board and see if it changes
the drop rate.

---
From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)

No, not in my experience.  Unless you have a lousy Ethernet card or
a faulty transceiver connection, your packet loss rate should be
at least a couple orders of magnitude lower than this.
---
From: romkey@asylum.sf.ca.us (John Romkey)

It depends on your ethernet interface. If you're using an old card
like a 3COM 3C501, expect lots of lost packets. Packet loss will vary
with the type of card and load on the net. It may also be a function
of the driver.
---
From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett)

Late '89 or early '90, my firm was working on a response to an RFP and had
a number of PC clones of various manufactures and operating systems in for
evaluation.  Out of curiousity, I ran a small ping test with the following
command:

        ping x.y.z 64 100

from a VAX 11/750 running 4.3BSD with a 3Com, shared memory, ethernet inter-
face and a VAX8250 running VMS 5.1 and WIN/TCP using a shared driver with
the DEBNI ethernet interface.

As a class, the PC clones were marvelously erratic in their response times.
As I recall, the response times ranged from somewhere around 16ms to 78ms
with average response times in the high 20's and low 30's.  There were, gen-
erally, 2 to 8 dropped packets.

RISC machines that were being evaluated at the same time, dropped fewer pack-
ets--if they dropped any--but had greater variance in their response times.
I seem to recall some response times in excess of 100ms.  The average response
times were, however, in the mid to high 20's range.
---
From: dotytr@nscultrix1.network.com (Ted R. Doty)

It really depends on how fast the packets arrive.  Many (most?) of the
Ethernet boards for PCs don't handle back-to-back packets very well
(if two packets arrive very close together, the board can't keep up
with them and drops the second).  I suspect that newer boards are
better, but since workstations are getting faster too, this problem
might be around until PCs can handle full media speed (the number I hear
is 14,800-ish packets per second).  So if you get a bunch of Telnet
packets back-to-back, you might expect to see dropped packets.
---

2. Is it normal for TCP/IP implementations to retransmit only the lost 
packet...

I read RFC1122 after I asked this - it recommends that when you retransmit,
you send a maximum sized paket containing whatever is in the retransmit
queue - not just retransmit the exact packet that was dropped.

---
From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)

The retransmission behavior you see is "typical".  No reason to waste
bandwidth if there's a chance the receiver already has the rest of the
packets.  What's _not_ typical is the PC's behavior of not saving the
"extra" packets.

What the protocol spec actually says it that it's "suggested" that
senders retransmit only the next packet, "suggested" that receivers
save "extra" packets, but "required" that the two interoperate
(albeit at what performance is not specified) even if the other end
doesn't follow the suggestion.
---
From: raj@hpindwa.cup.hp.com (Rick Jones)

Eghads NO! !-) If you were to do that, it would be asking for your
network to go into congestive collapse ;-( When that timer pops (the
first one at least...) the ONLY thing that you can surmise is that the
first packet was lost - you really do not know if any of the other
packets were lost. When (if) you upgrade the MPE/V systems to an XL,
you will find that the XL code is much better in its handling of those
situations (it started-out like the V code, but I changed it ;-) It
does NOT do batch-rtx, but will clear-out the rtxq much faster than
the V code will.
---
From: romkey@asylum.sf.ca.us (John Romkey)

It depends on how you're trying to treat the intervening network. If
you're trying to avoid congestion, you penalize the one for the good
of the many. If you're not, you don't.
---
From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett)

Strategies are left to the implementor and are not part of the protocol spec-
ification.  How often and when should the receiving station send an acknowl-
edgement when it has detected the loss of a packet?  How frequently should
the transmitting station send a packet to compensate for potential packet
loss?  How does the transmitting station determine that the receiving station
does not buffer out of sequence packets when there is no requirement to send
an acknowledgement to an out of sequence packet?
---
From: dotytr@nscultrix1.network.com (Ted R. Doty)

Can you use your analyzer to see what size is negotiated for a TCP
window?  I seem to recall a window of 512 bytes when we used Excelan
boards (TCP on the board).  Check to see if one of the machines is
violating the window size.  I don't think that the sender should have to
retransmit *all* unacknowledged segments, but when it gets the act for
the (single) missing one, it *should* send the others.  (this is so you
don't waste lots of bandwidth retransmitting segments that the receiver
might have received and buffered, but couldn't ack because the first
segment was dropped)
---

3. Is it normal for TCP implementations to discard all out of sequence
packets?

No, but if marketing thinks it is more important to conserve memory on
an antiquated architecture (DOS), they'll tell the programmer to slash
'features' :-(.

---
From: raj@hpindwa.cup.hp.com (Rick Jones)

Only on little systems like PC's where there is not much memory for
the TCP code to hold onto. I think that newer PC code might be better
though.
---
From: romkey@asylum.sf.ca.us (John Romkey)

When the ratio of the amount you get yelled at is proportionate to how
much space your code takes up, many things are possible.
[I think John hit the nail on the head with this one - phil]
---
From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett)

The specification states that you need the ability to receive out of sequence
packets and re-assemble the data in the proper order once the missing data
is received.  Reality may have intruded in the implementation that you're
using--not enough memory space to store out of sequence packets.
---
From: dotytr@nscultrix1.network.com (Ted R. Doty)

No.  If the PC were more robust (no flame here, just an observation), it
would buffer all out of sequence segments.  for example:  Suppose sender
S sends ten segments (1-10).  Segment #1 is lost; segments 2-10 are
received by receiver R.  R will not be able to ack receipt, since the
window starts at #1, and #1 was lost.  S will time out and resend 1.
When R receives #1, it will ack #10.  I'm not clear on whether S should
retransmit 1-10 or just 1.  My suspicion is that it should *not*, since
dropped packets are frequently a sign of router congestion, and
retransmitting the entire window would exacerbate this.  Check RFC 1122
and 813, 816, and 817.


-----

That's it.  Thanks again to all those that responded.


-- 
Phil Trubey                     |  Internet: phil@shl.com      
SHL Systemhouse Inc.            |  UUCP:     ...!uunet!shl!phil
50 O'Connor St., Suite 501      |  Phone:    613-236-6604 x667
Ottawa, Ontario, Canada         |  Fax:      613-236-2043

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 16:34:28 GMT
From:      mcdonald@aries.scs.uiuc.edu (Doug McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: mac to mac ftp with NCSA Telnet 2.3?


In article <813@skipper.dfrf.nasa.gov> hellwig@skipper.dfrf.nasa.gov (Oliver Hellwig ) writes:
>
>Currently NCSA telnet for the MAC can only accept incomming ftp's (i.e.
>you won't be able to ftp out of a MAC with NCSA telnet 2.3).  It's
>a small inconvience compared the other overall quality of this excellient
>piece of free software.
>

I would say that not being able to ftp out (like ftpbin does with 
NCSA_Telnet for the PC) renders the whole thing worthless for me. 
(How, for instance, do you download files from anonymous ftp sites.
How do you transfer files from a Mac with a CD ROM player to a PC -
when you are always needing to change CD-ROMS and the PC is in 
another room?)

Besides, you cannot properly set up key mappings with the Mac version.
Therefore I would conclude that the Mac version is, to use the classic Usenet
phrase, terminally brain-dead. 


Doug McDonald

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 16:34:28 GMT
From:      hellwig@skipper.dfrf.nasa.gov (Oliver Hellwig )
To:        comp.protocols.tcp-ip
Subject:   Re: mac to mac ftp with NCSA Telnet 2.3?

In article <63352@eerie.acsu.Buffalo.EDU> tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi) writes:
>
> I posted this question to  telnet@ncsa.uiuc.edu on 1/22, but apparently
> that is a dead list, I didn't receive any replies.
>
> Does Mac NCSA Telnet support mac to mac ftps directly?  I don't want
> to sign onto a mainframe/mini to ftp stuff between two macs.  I 
> thought ncsa telnet 2.3 had this feature, but I don't see it
> documented.
>
> JoAnn



Currently NCSA telnet for the MAC can only accept incomming ftp's (i.e.
you won't be able to ftp out of a MAC with NCSA telnet 2.3).  It's
a small inconvience compared the other overall quality of this excellient
piece of free software.

Oliver

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 19:09:14 GMT
From:      john@loverso.leom.ma.us (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: Making terminal servers just like internal serial ports

> Why doesn't anyone do this? Is there a protocol under developement?

Some terminal server vendors do let you do this.  There are several ways.
The easiest involves something on the order of a user-level "reverse"
telnet daemon that runs on your host, connects to a pty pair, and makes
a telnet connection to the terminal server.  This gives you a device
that you can poke random programs at.  Xylogics provides source to such
a program with the software distribution that comes with the Annex.
cisco provides a similiar program via anonymous ftp access.  One or
two other such programs have been posted to comp.sources in the past.

The pty approach has several hazzards, as it stretches the abilities
of the pty mechanism in various ways.  However, it is a good 90% solution.
Of course, it can reek havoc with the performance of your machine - as
can anything based upon the traditional BSD telnetd/pty interaction.
Using the "in-kernel" telnetd support code can remove this performance
problem.

At least one company (Artecon) resells [Annex] terminal serves with a
SunOS device driver that does the telnet connection in the kernel and
links directly to the tty stack.  This supposedly removes several of the
problems with the pty approach, but I've never used it, so I can't comment
further.

John

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 20:36:04 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Packet Sizes

You don't mention the type of network you're using; I presume it's
ethernet.

If you're looking at raw ethernet packet lengths (as opposed to IP
datagram lengths), you'll see lots of 60 byte packets on the net
because ethernet has a minimum packet length of 60 bytes. Any packets
that are shorter are padded out to 60. IP can tell how many bytes it
should pay attention to because it has its own length field. IEEE
framing over ethernet uses the type field as a length field for a
similar reason.

All ARP packets should be under 60 bytes. Many TCP/IP packets fall in
here, too: acknowledgements, packets with little data (for instance,
packets initiated by a telnet client will almost always be 14 bytes
of ethernet header + 20 bytes of IP + 20 bytes of TCP + 1 or 2 bytes
of data = roughly 55 bytes long).
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 91 20:41:17 GMT
From:      amir@SPOT.COLORADO.EDU (KHAN AMIR AFZAL)
To:        comp.protocols.tcp-ip
Subject:   Request for addition to email list

I would like to be added to the mailing list.
email address: amir@spot.colorado.edu

Thanks
Amir Khan

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 91 00:11:55 GMT
From:      hlh@raybed2.msd.ray.com (HOWARD HANTMAN)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and IP routing problem

In article <1991Mar11.190228.15146@mprgate.mpr.ca>, parker@mprgate.mpr.ca (Ross Parker) writes:
> I'm having a routing problem with the following configuration:
> 
> Currently, the Ottawa systems and the systems here are using the
> same IP address space - both in the class B address '134.87'. I can
> understand routing failing with this configuration... with only one
> network address, there's nothing to route *to*. I have, however,
> tried setting up the SLIP line with it's own address (we have a
> class C address at our disposal, and the route to Ottawa still isn't
> reachable.
> 
I believe your problem is that you can't have a disjoint IP network.
Putting a Class C address on the SLIP interfaces does not change the
fact that the hosts in Vancouver on network 134.87 are on (or SHOULD be on)
the same network as the hosts in Ottawa on network 134.87. I don't think
its legal to set up a route to network X from network X via network Y!
The easiest solution would probably be to use subnetting. From your diagram:
>          Ottawa                                 Vancouver
>         'mprott'                                'mprgate'
>     ------------------                     ------------------
>     |134.87.137.1    |                     |   134.87.131.12|
>  ___|______^         |                     |          ^_____|___
>     |      192.67.9.1|   Slip line         |192.67.9.13     |
>     |          ^_____|_____________________|______^         |
>     ------------------                     ------------------
> 
The third byte of the IP address for the two LANS is already different.
If that third byte is consistant at the two sites you can set the
network mask to 255.255.255.0 and then Ottawa and Vancouver will have
two separate IP networks legally linked by a third one. If due to number
of nodes, you cannot devote an entire byte to subnets, you may need to
look into changing whatever the smallest number of addresses is to get some
number of significant bits to be different and subnet on that.

A second solution, much clumsier but a last resort if there is no way
to change addresses to meet the above, is to use proxy arping. On each local
gateway, you would need to put a static route for each remote node you
wish to reach. You would then also need to add proxy arp entries for each
of the remote hosts. Local hosts would not require any routing information.
As far as they would see all nodes on their network (134.87) would be
directly reachable via ethernet, just as they should be.

					Howard Hantman
					Computing Consultant
					Software Development Center
					Raytheon Co.
					hlh@swlvx2.msd.ray.com
					...{linus,applicon,cg-atla}!raybed2!hlh

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 91 00:28:42 GMT
From:      hlh@raybed2.msd.ray.com (HOWARD HANTMAN)
To:        comp.protocols.tcp-ip
Subject:   Re: Any way of sending an interrupt to a program whenever message arrives in socket

In article <7134@bgsuvax.UUCP>, majumdar@bgsuvax.UUCP (anindo Majumdar) writes:
> Is there anyway an interrupt can be sent to a program whenever a message
> intended for it arrives on a socket?Is there a standard signal available in
> Berkeley 4.2 BSD Unix for such an interrupt ?Basically I do not want to wait
> on a recvfrom call.At the same time I would like to handle any messages.(A recvfrom call with a non blocking option set doesn't help as it returns an error
> E_WOULDBLOCK if there are no messages when the recvfom is executed).Any pointers will be appreciated.

Using fcntl's it is possible to mark a file descriptor as being asynchronous.
When this is done, a SIGIO signal (or SIGURG for out of band urgent data) is
sent to the process or process group receiving such signals whenever IO is
possible on the descriptor. To set the descriptor to be asynchronous, get
the current flags using the F_GETFL fcntl. OR in the FASYNC flag and set
them back using F_SETFL. To set the process/process group to receive the
signals use F_SETOWN. If the argument is negative it is used as a process
group, otherwise it is used as a process id.

While my experience is actually with Ultrix, I believe this is available on
any Berkeley based system. I have seen some systems, including older Ultrix
systems, however, where FASYNC is available only if the descriptor references
a tty.

					Howard Hantman
					Computing Consultant
					Software Development Center
					Raytheon Co.
					hlh@swlvx2.msd.ray.com
					...{linus,applicon,cg-atla}!raybed2!hlh

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 91 16:29:00 GMT
From:      JRJONES@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   ncsa telnet


I have been hearing alot about ncsa telnet on the net.  I understand
from the messages that it is for macs and pc systems.  Where is there an
anonymous ftp site that has this software??  I would like to try it
since we are concidering some commercial packages.  An info on sites would
be appreciated.


jim

jrjones@alex.stkate.edu

612-690-6856

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 91 16:29:46 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Email address of Wollongong Inc., please !

Try "service@twg.com" or "postmaster@twg.com" for The Wollongong Group.

Merton Campbell Crockett                                 Contel Federal Systems
System Software Manager           Government Systems Group, Westlake Operations
IDHS Engineering                                31717 La Tienda Drive, Box 5027
01(818)706-5573                               Westlake Village, CA   91359-5027

Internet:  mcc@WLV.IMSD.CONTEL.COM   Easynet: DECWRL::"mcc@WLV.IMSD.CONTEL.COM"

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 91 17:09:13 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   re: V3.2 vs V4 UDP and NFS


   Date: 12 Mar 91 00:57:55 GMT
   From: decwrl!ames.arc.nasa.gov!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!chinacat!uudell!Kepler.dell.com!mjhammel  (Michael J. Hammel)
   Organization: Dell Computer Corp.

    I seem to be having a problem with V4 systems and UDP.  It appears that
    an NFS-based test between two V3.2 systems that I run shows up under
    Netwatch as follows:

Are you actually having an NFS problem, or is the Netwatch output just not
being clear?

	   IP: src addr -> dest addr <value> UDP <value2> -> <value3> <value4>

value is the length of the IP packet. value2 is the UDP source port.
value 3 is the UDP destination port. value4 is the length of the UDP
packet (as I recall).

   With V4 to V4 systems its more like:
	   IP: src addr -> dest addr 1500 UDP Fragment
   And its *always like that.

   Question:  what do these numbers mean, what does Netwatch mean by
   Fragment (and how does he know its a fragment?), and why does either
   Netwatch see things differently between the two scenarios or why is
   there a difference?  Can it be related to the rsize/wsize default
   values?  Where are these values specified?  I'm not specifying these
   values in the mount command.

Fragment means the packet is fragmented at the IP layer. There's
information in the IP header that says "this packet has been
fragmented" as well as where it fits in the reassembled packet.
Netwatch won't tell you more because it's not sure what the UDP port
numbers are since the packet is fragmented. It could've picked them up
out of the first packet, but I didn't check on that when I wrote it.

I don't know enough details about NFS to relate this to particular
versions, but it does like to send large (8Kbyte) packets and fragment
them into pieces you can actually transmit over the ethernet (roughly
1500 bytes or less). That's what you're seeing in the second
situation. Someone else will have to answer the NFS-specific
questions.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 91 01:37:40 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   FTP ISC 2.2 Woes.

Here's a guess...

SCO uses Lachman's TCP. ISC bought Lachman (much to SCO's
consternation, I expect). I see a similar problem on my SCO system
sometimes. One thing that brings it out is if my system can't resolve
the hostname of the client. So, verify that it can resolve your
client's hostname (try telneting to the ISC system and then netstat to
see if the name is listed). If it can't, try reconfiguring your system
so it can and try it again.

I doubt *very* much that it's a hardware problem. If it is, it's
probably something like an ethernet board that drops packets and is
consistently dropping a packet. Are you using a 3C501? Anyway, I do
doubt it's a hardware problem.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 91 04:48:29 GMT
From:      jxr@thumper.bellcore.com (Jonathan Rosenberg)
To:        comp.protocols.tcp-ip
Subject:   Adjusting Effective Bandwidth

Hi,

We are starting a project looking at the real-time delivery of interactive multimedia documents over a range of bandwidths.  We are going to be building a prototype that is two workstations connected by their own Ethernet.  In order to control the effective bandwidth, we are planning on atually implementing the network as 2 networks with a workstation in the middle.  This workstation in the middle would take packets from 1 workstation and forward to the other ensuring that the specified bandwidth was not e









xceeded.

Has anyone ever fooled with this kind of thing?  Anyone know of software available?  This just seems like the kind of thing that others may have fooled with so I though I'd ask.  Any help appreciated.

Oh -- please reply to me via e-mail (jxr@thumper.bellcore.com) as I don't normally read this newsgroup.

Jonathan Rosenberg
Manager, Information Networks Research

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 91 22:53:21 GMT
From:      phil@atlas.abccomp (Phil Stenson)
To:        comp.protocols.tcp-ip
Subject:   Interactive Unix + AT&T EN100 NAU board

If anybody has used or tried to use an AT&T EN100 NAU board with
Interactive's TCP/IP I would appreciate greatly if you could e-mail
me information on how you went. I have not been able to get any drivers
from my distributer for the board and it is not listed as a known
network card in Interactive's documentation.

Any information will be greatly appreciated - thanks.

-- 
Phil Stenson               |   Internet   phil@atlas.abccomp.oz.au
TurboSoft Pty Ltd          |   JANET      phil%atlas.abccomp.oz.au@uk.ac.ukc
248 Johnston St, Annandale |   UUCP       uunet!munnari!atlas.abccomp.oz!phil
NSW 2038    Australia      |  Telephone   +(612) 552 1266

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 07:08:57 GMT
From:      DAVID@wcc.govt.nz (David Richards)
To:        comp.protocols.tcp-ip
Subject:   My Problem with TCP-IP between VAX & SCO UNIX BOX

We have a SCO UNIX System that had TCP-IP run time installed.
I could Telnet the VAX, and I could Telnet it (The UNIX Box) from the VAX.

After the TCP-IP got screwed up I re-instelled TCP-IP on the box, but I can no
longer telnet the VAX.

The UNIX Box has a Western Digital WD8003E Ethernet controler which is
connected to thin wire ethernet with a VAX on the other end.

Can anybody help.

My return address is "david@ccc.govt.nz" not the one in the From: field, so
please send mail to "david@ccc.govt.nz" and use the REPLY command as the
network is not setup correctly.

Thanks	David Richards.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 09:53:23 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   SLIP InFO

Could some kind soul explain  to me exactly what SLIP is, it's pro's
and cons? Please forgive my naivety. Thanks
G. Byron Stirling University. gsb1@uk.ac.stirling.forth

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 11:46:46 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: What is INADDR_LOOPBACK for in sockets?

>>>In article <MCGRATH.89Dec1142539@paris.Berkeley.EDU>, mcgrath@paris (Roland
>>> McGrath) writes:
>>>INADDR_LOOPBACK is 0x7f000001, Internet address 127.0.0.1, usually called
>>>`localhost'. Talking to this address gets you back to where you started from
>>From: ea.ecn.purdue.edu!housel@ee.ecn.purdue.edu  (Peter S. Housel)
>>  The nifty thing is that (on many systems with BSD-derived
>>networking) you can disable the loopback-net, through which address
>>127.0.0.1 is routed. Running "ifconfig lo0 down" will disable the
>>"loopback interface" and the machine will be unable to talk to itself.
>I can't resist adding that you have to be careful, though, of
>situations where you lose a route to 127.0.0.1 but you have a
>"default" route floating around your net.  For example, I used to see

1) On my IBM TCP/IP for VM, "own-address" goes through the network, as you say.
2) But trying FTP 127.0.0.1 gets me talking to the first non such router on the
   path to the Internet.
3) 14.0.0.0 is used instead to stay local.
4) and, of course, ftp 14.0.0.0 from a host whose Internet path I am on gets
   to my system.

So, it looks like the specific address is implementation dependent.
A question is: how can a procedure (script or whatever) wishing to use the
loopback address be made portable when there is no "localhost" to refer to
in the dns?

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 13:42:10 GMT
From:      BRUCE@UMDD.BITNET (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   Re: What is INADDR_LOOPBACK for in sockets?

>1) On my IBM TCP/IP for VM, "own-address" goes through the network, as you say.
>2) But trying FTP 127.0.0.1 gets me talking to the first non such router on the
>   path to the Internet.
>3) 14.0.0.0 is used instead to stay local.
>4) and, of course, ftp 14.0.0.0 from a host whose Internet path I am on gets
>   to my system.
>
>So, it looks like the specific address is implementation dependent.
>A question is: how can a procedure (script or whatever) wishing to use the
>loopback address be made portable when there is no "localhost" to refer to
>in the dns?

In this respect, the IBM TCP/IP (FAL) is broken (maybe it has been fixed
in version 2).  The "Assigned Numbers" RFC (RFC-1010) states:

   (g)   {127, <any>}

      Internal host loopback address.  Should never appear outside
      a host.

I.e., any class A network address that starts with a 127 in the first
octet is a loopback address.  This has been brought to IBM's attention
in the past and the response is that it is this way for historical
purposes and compatibility to previous versions.  The fact that it will
actually place a 127.x.x.x number on the network is just plain broken.
If it isn't fixed in version 2 (which is just now getting out to people),
I will try to make a SHARE requirement of it at the next SHARE meeting.

                                       Bruce

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 14:44:24 GMT
From:      JCALVO%ANDESCOL@CUNYVM.CUNY.EDU (Jorge Mario Calvo)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Unix System V/386 R4.0

Hola Hugo :

Esta muy interesante, pero tu ya lo trajiste ?.

o quieres que lo traiga y lo instale.

Atte

Jorge M. Calvo

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 16:22:32 GMT
From:      dug@CORNELLC.CIT.CORNELL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: HyperFTP

There was a question on this list about client FTP implementations for
the Macintosh.  Here's some information from the author, Doug Hornig,
about a Hypercard-based FTP client from Cornell.

Mark Bodenstein  (mab@cornellc.cit.cornell.edu; 607-255-8059)
Cornell University
----------------------------Original message----------------------------
Mark,
Yep HyperFTP is in the public domain.  I first send copies to
sumex-aim.standford.edu where it can be anonymously FTPd from the
/info-mac/comm directory.  I've seen it show up in other places as well.
-- Doug

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 16:47:00 GMT
From:      JRJONES@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   uucp and the internet


I have a several questions, relating to the interaction of uucp and the
internet.  I know very little about uucp, and I have several users that need
to contact uucp users.  Any info would be appreciated.

1. Is there a way for uucp users to get to the internet via a gateway?
2. If there is a public gateway, were is it?
3. What information do uucp users need to know inorder to send
   mail to internet users?
4. What do internet users need to know inorder to send mail to uucp users?

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

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 18:35:10 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  What is tn3270 and where can I get source.

There have been a lot of questions along this line, lately. Just to 
clarify things...

Several TCP/IP implementations use the name "tn3270" for telnet with a
tn327x emulator. (Some such programs are probably available with
source - I'm not a good source for that information.)  These programs
will differ, however, as various ftp's differ. People who want help
with, or information on, a telnet will get faster and more accurate
answers if they can specify what implementaion they are asking about.
These lists have an expert or two for just about everything!


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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 19:09:20 GMT
From:      i_donald@uk.ac.glasgow.edrc (Ian Donaldson)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Desparately seeking CMU-TEK tcp-ip for VMS

I'm looking for CMU-TEK - the tcp/ip implementation for VMS machines.
Can anyone provide an e-mail address through which I can begin the process of
acquiring this from CMU.  Failing that, a postal address would be appreciated.
Many thanks.
-------
janet:    <i_donaldson@uk.ac.glasgow.edrc>             | phone: +44 41-945-0908
internet: <i_donaldson%edrc.glasgow.ac.uk@nsfnet-relay>| FAX:   +44 41-946-5020
BITNET:   <i_donaldson%edrc.glasgow.ac.uk@ukacrl       | ~~~~~~~~~~~~~~~~~~~~~
-- Engineering Design Research Centre, Glasgow University, Glasgow, G20 0XA, UK

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 20:01:34 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   Xyplex print server question

Does anyone have a method of printing to a Xyplex print server that allows
BSD lpr to effectively use both the if and of filters.  the xyplex example
code allows one or the other but it is tough to make use of all the lpr
features without being able to initiate both filters.

Details:

If the xyplex example code opens the socket to the printserver as, let's say,
the "of" so that I can get all the header-page stuff, the "if" filter
isn't executed so that I can pick up the page-layout (size, etc.) stuff
for changing characteristics of the printer.

Any pointers to good methods or errors in my logic are much appreciated.

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

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 21:00:16 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  Public domain NFS

Last I heard, there were no PD NFS clients. There is a PD NFS 
server (SOS - Stan's own Server). Commercial NFS clients for
PCs are available from FTP Software, Sun Microsystems, Beame &
Whiteside, and Wollongong.


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

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 22:06:45 GMT
From:      spm@md.interlink.com (Steve Morgan)
To:        comp.protocols.tcp-ip
Subject:   lpr/lpd request

Could anyone who knows of publicly available lpr/lpd facilities drop me a
line and let me know where?  Thanks much.

Steve Morgan
Interlink Computer Sciences
spm@interlink.com
301 317 6600

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 91 23:53:43 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   Packet versions of pcip s/w

Sorry, beginner's question:
I am interested in running the packet version of the pcip stuff.
Got the software, but the documentation in the files I got does not
explain how to configure netdev.sys to use a packet driver.
Could someone kindly oblige with a doc file that does or a one-liner
pointer? I just don't know enough to work it out from first principles.
Thanks
Andrew
-- 

+----------------------------------------------------------------------------+
|  Andrew Hardie                                             ash@omega.uucp  |
|  London, England                                      ukc!cctal!omega!ash  |
+----------------------------------------------------------------------------+

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 03:09:32 GMT
From:      scottp@se-sd.SanDiego.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   subnetting


  I am trying to build up a case for proper coordination of subnet
masks on hosts and gateways in a medium sized network.  There is a 
central router which employs the 8-bit subnet mask connecting 8 physical
nets in a class B network.  Some hosts on the segments have 8-bit
subnet masks and others do not.  The network functions with this hodge-podge
config, but when I want to further subnet off one of the segments I run
into problems that I feel are attributed to the subnet config.  When this
further segmented net tries to reach hosts on the segment which it has the
direct connection to it fails if the host is not using the subnet mask. 

  What are some other specific reasons for not having hosts on the same
network have different subnet masks?  Also, what problems may arise
if there is a gateway with one interface using masking and the
other interface not?  
  If you feel this discussion is inappropriate for the group, please
email.  Thanks.

	+-------------------------------------------------------+
	|	   Scott Platenberg, NCR NPD-San Diego		|
	|	   9900 Old Grove Road, San Diego, CA		|
	|	 Scott.Platenberg@se-sd.SanDiego.NCR.com	|
	|	VOICE: (619) 693-5714, VOICEplus: 442-5714	|
	|		    FAX: 619-693-5705			|
	+-------------------------------------------------------+

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 04:05:48 GMT
From:      mark@badger.dosli.govt.nz (Mark Wright)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   slip over 9600 baud?

We are looking at setting up a wide area network based on tcp-ip. We
currently have several Ethernets in different district offices. These
Ethernets have Ultrix workstations using TCP-IP, PCs running Novell
(with BYU IPX, packet drivers and CUTCP).

The major reason for the WAN is the centralisation of management
information at head office, with "terminal" access from the district
offices. As we would like to use the (dedicated) lines for other
traffic (file transfer, mail, news and print spooling), we intend to
use TCP/IP.

Our intended plan is to use 9.6 kb lines for the smaller offices,
moving to faster lines for the larger offices. My main question is
what sort of performance can we expect from the 9.6 kb lines? Is it
reasonable to run say three terminal sessions over such a line with
TCP/IP ? Also, does the entire setup sound realistic, what sort of
problems can I expect?

Any comments from people experienced with such a situation would be
appreciated: are we on the right track?

Cheers, 
Mark.
-- 

 Mark Wright.                    Dept. of Survey and Land Information,NZ.
 email: mark@dosli.govt.nz       phone: 64 4 710-380 ext 8688

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 04:06:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

In article <9103182100.AA10350@ftp.com>, fks@FTP.COM (Frances Selkirk) writes:
> Last I heard, there were no PD NFS clients. ...

What about the 4.3BSD-Reno NFS implementation?  It may not be serve the
original requestor's purpose, and there is some evidence it is a
little rough.  It's not public domain, but is it unlike the rest of the
BSD networking code, freely distributable?


Vernon Schryver,   vjs@sgi.com

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 04:53:43 GMT
From:      ftpam1@acad3.alaska.edu (MUNTS PHILLIP A)
To:        comp.protocols.tcp-ip
Subject:   Looking for J. Postel

Can somebody provide an email address for J. Postel, author of RFC925?

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 14:37:43 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

You're right - there is the Berkeley one. My job being what it is, I 
occasionally start thinking of everything in terms of PCs...  :)


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

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 15:27:55 GMT
From:      mleech@bnr.ca (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital phones for SLIP circuits

In article <6902@spdcc.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes:
|> In article <8204@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey II) writes:
|> A pair of LDS309A's using a metallic (LADS) circuit comes very close to
|> idiot proof.
|> 
Having recently worked for Gandalf, I can also recommend some of their newer
  technology--I seem to recall a beast called the LDS709 which gives you
  19.2k full-duplex on a two-wire circuit.  For slightly longer-hauls
  they have a series of "metro-modems" LDM409, and LDM419 (only vaguely
  recall the model numbers).

-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 15:38:02 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip,comp.terminals,comp.sys.dec
Subject:   LAT <==> TELNEt protocol converters

Does anyone have information on Telnet <==> LAT protocol converters.  Esp. ones
that sit on a network and do all the hard work.  I've seen the Datability one.

John Bourke								 O-O
Systems Support,			<bourkej@ul.ie>			  | 
Information Technology Department,	Phone: +353 61 333644 x2008	# _ #
University Of Limerick, Ireland.	FAX:   +353 61 330316		 ###

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 18:26:45 GMT
From:      bstrong@sleepy.bmd.trw.com
To:        comp.protocols.tcp-ip
Subject:   Re:  lpr/lpd request


I, too, am interested in any public domain lpr/lpd software.  If anyone
knows of any, could you please reply via e-mail?   THANKS!!

Bryan Strong
TRW / OEO  Computing Services
Internet:  bstrong@oz.bmd.trw.com
Phone:     (801) 625-8331

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 18:29:20 GMT
From:      ken@opusc.csd.scarolina.edu (Ken Sallenger)
To:        comp.protocols.tcp-ip
Subject:   Re: Book: Internetworking with TCP/IP

In article <A744BF72D19FA04604@ccit.arizona.edu>
	JOHNGALT@CCIT.ARIZONA.EDU ("Dr Galt, I presume?") writes:

=>   I hate books!  Just when you buy one, they come out with a new edition!
=>   Why can't we get change files to books?  Or trade-in allowances.

O'Reilly & Associates [home of the Nutshell books] _does_ give trade-in
allowances.  If you send them the title page from the old edition, you
get 25% off the new one. 

Now, if we could just convince them to do the definitive TCP/IP book...
-- 
          Ken Sallenger   ken@bigbird.csd.scarolina.edu 
#include <disclaimer.h> /* No connection with ORA except as customer */

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 19:14:05 GMT
From:      jpm@logixwi.UUCP (Jan-Piet Mens @ Logix GmbH, Wiesbaden)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.xenix.sco
Subject:   How can I use TCP-IP ?


Hello Netters,

I have two SCO-UNIX 3.2.2 boxes running on 386, and 486 and two
Toshiba laptops running either Unix or Mess-Dos. Now to the point.

I would like to be able to hook up all these crates with Ethernet, Cheapernet
or whatever and TCP/IP or PC-NFS. Can anyone suggest hardware, software,
problems that will occur, costs and so forth ?

What is Slip ? Can one use it over modem lines at 2400bd ? Is it always 
included in any TCP-IP Software packages ?

I would much appreciate any answers, since this is complete newland for
me.

If there is enough response I am willing to post a summary.

Thank you very much.

/JP
-- 
Jan-Piet Mens, Logix GmbH				    jpm@logixwi.UUCP
Moritzstr. 50, D-6200 Wiesbaden            ...!uunet!mcsun!unido!logixwi!jpm

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 21:09:25 GMT
From:      pbh@CERBERUS.CFSMO.HONEYWELL.COM (Paul Henninger)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

unsubscribe paul henninger

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 21:43:02 GMT
From:      JLENNIE@VM.UOGUELPH.CA (Jim Lennie)
To:        comp.protocols.tcp-ip
Subject:   traceroute

Can someone tell me where I can get a copy of traceroute for Ultrix 4.0?

===========================================================
Jim Lennie                           jlennie@vm.uoguelph.ca
Communications Services              519-824-4120  Ext 2588
University of Guelph
Guelph, Ontario
===========================================================

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 22:05:42 GMT
From:      dzoey@terminus.umd.edu (Joe Herman)
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   How do I detect an active TCP/IP (IBM) under OS/2?

Hello, I have a program running under OS/2 that would like to take advantage
of TCP/IP if it's installed on the machine.  Unfortunatly, I can not think
of a good way for the program to detect the presense of TCP/IP.

At first, I thought this could be done by checking the return code
from the socket() (or sock_init()) call.  However, if inet is not
functioning the call to socket() causes the program to exit.  Since
the program can still function without TCP/IP, this is not a desired
behavior.

Does anyone know of a method to detect the presense of TCP/IP under OS/2?

			Thanks,
			Joe Herman
			U. of Maryland

dzoey@terminus.umd.edu
-- 
"Everything is wonderful until you know something about it."

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 22:23:45 GMT
From:      rhaller@phloem.uoregon.edu
To:        comp.protocols.tcp-ip
Subject:   list of whois,finger, etc. servers wanted

There are now lists of online library catalogues that are regularly updated
and distributed. Is there an equivalent for whois/finger/etc or other
tcp/ip directory service type servers for the Internet? For example, we
provide such service for 'uoregon.edu' based on our campus phone book (plus
some email stuff we tracked down and added) from the host
'oregon.uoregon.edu'. I happen to know that Stanford has a comprehensive
whois service out of 'stanford.edu', and that a number of sites are
participating in the Nsyernet White Pages project. What I am looking for is
a list of as many such sources as possible, ideally searchable on
institution, like "University of Chicago".

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 23:11:17 GMT
From:      raisch@Control.COM (Robert Raisch)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS


There is a PD (almost) NFS client.

MD-DOS/IP from Univ of Maryland.

Package includes:

	TCP/IP Kernel
	Berkeley Sockets lib
	Telnet/Ftp/etc.
	LPR/RSH/TFTP
	NFS client

	All sources and manuals

It's an interesting package and although it takes up scads of RAM, 
(QEMM'able, thank the gods), it's very stable.

It's available to edu clients for a small price, I think ~= $200.
(I'll post contact info if there is interest.)

The development team answers their mail, too.  <smile>
-- 
"I ate his liver with some fava beans and a nice chianti." -Lector

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 91 23:31:56 GMT
From:      sudji@indo.intel.com (Sudji Husodo)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Updated SLIP for Unix System V/386 R4.0


An updated version of the SLIP driver for Unix System V/386 R4.0
is now available in iabi.intel.com (128.215.19.51) in pub/slip.
The update was placed at noon on the March 15, 1991.

The previous version has a memory leak problem in the SLIP driver
(driver/io/slip.c) which is fixed by adding a call to freemsg as shown
in the following context diff output.


*** slip.c	Tue Mar 14 09:39:08 1991
--- slip.old	Tue Feb 25 09:42:09 1991
***************
*** 758,764 ****
  		STRLOG (SLIPM_ID,1,0,SL_TRACE,"slip_dl_cmd: DL_UNITDATA_REQ");
  		if (p_slip->state == DL_IDLE) {
  			STRLOG (SLIPM_ID,2,0,SL_TRACE,"slip_dl_cmd: putq (%x, %x)", q, mp);
- 			freemsg (response);
  			putq (q, mp);
  			return;
  		}
--- 758,763 ----


I apologize for the delay on this posting.

Sudji Husodo (sudji@indo.intel.com)

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 03:26:00 GMT
From:      HARISH@ITIVAX.BITNET
To:        comp.protocols.tcp-ip
Subject:   Query on SCO's MultiScreen-like PD software

Though my question is not directly related to TCP/IP, I'm sure some of the
readers of this newsgroup know of the existence of a piece of PD software very
similar to SCO Unix's Multiscreen.  I'm told that it is called Screen and was
written by someone in Europe.  I'd like to find out where I can get hold of it.
I could not find it at simtel20.  E-mail your replies please and as usual, if
there is sufficient interest, I'll post a summary.

On a TCP/IP issue, I recall someone asking a while back about which interface
to program for - sockets or TLI.  I'd like to know what the general consensus
was.  I believe it was to go with sockets.

Thanks and regards.

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

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 12:20:00 GMT
From:      pjd@eagle.inesc.pt (Paulo Jorge Delgado)
To:        comp.protocols.tcp-ip
Subject:   tn3270 and AS/400


	Anyone know where I might find the sources for tn3270? I need it
to telnet from a DG AViiON to an IBM AS/400 with TCP/IP.
        I have the (beta test) version 3 of tn3270, from Greg Minshall
(minshall@berkeley.edu). It seems to be a 1986 version of the program, and
I couldn't make it work properly. It seems to always negotiate the connection
in line mode, which is no good for the AS/400.

Thanks in advance for any help.

Paulo Jorge Delgado

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

--
 Paulo Jorge Delgado
 INESC, Lisboa, Portugal
 Email: pjd@eniac.inesc.pt

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 12:22:03 GMT
From:      pjd@eagle.inesc.pt (Paulo Jorge Delgado)
To:        comp.protocols.tcp-ip
Subject:   AS/400 ftp


        The guide to TCP/IP for the AS/400 states (chapter 7) that ftp can't
be used to transfer save files (*SAVF). Is that final? Because that was one
of the purposes I intended to use ftp for: backup things to a save file and
then ftp'ing it to a remote UN!X box where it would be stored in a 8mm tape.
        As anyone worked around this limitation to AS/400 ftp? Hello ibm.com,
are you listening?
        Many thanks in advance for any help.

Paulo Jorge Delgado

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

--
 Paulo Jorge Delgado
 INESC, Lisboa, Portugal
 Email: pjd@eniac.inesc.pt

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 12:30:07 GMT
From:      john@wekiwa.uucp (John Carter)
To:        comp.protocols.tcp-ip,comp.unix.questions,alt.sys.sun
Subject:   Reliable UDP transport

I am working on an application which will require a Sun workstation to 
communicate with an external device via UDP.  We need to implement some
simple means of reliability (hopefully nothing too fancy).  If anyone can
point me to a publication or even sources, it would be greatly appreciated.

Please respond via email, as I have a limited news feed here.

Thanks in advance

John

-- 
John Carter - Melbourne, Fl.            Musta been a barge comin' through!
home: john@wekiwa.mlb.fl.us                  -- Calvin & Hobbes
UUCP: uunet!slopoke.mlb.semi.harris.com!wekiwa!john

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 14:15:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: how to control the size of TCP packets in BSD 4.3?

> In BSD 4.3 TCP (SunOS/Irix/whatever), is there an easy way to force a
> write(2) to immediately push a packet out to the network?

Get a stream pointer for the socket (fxxsomething or other), and then
issue an "fflush()" call after your writes.

- Bob Stine

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 15:06:15 GMT
From:      news@m2xenix.psg.com (Randy Bush)
To:        comp.protocols.tcp-ip
Subject:   Help designing address allocation in a metronet

We have a metronet here in the Portland area, RAINet.  We are using SLIP (often
with PC-Route), and most sites have multiple hosts on a local ether.

With one exception (a private C), we are all sharing a single class C using a
subnet mask of 0xf8.  As each of the SLIP links must be a subnet, we're chewing
up our class C rather quickly.  So, we seek advice on how to best regroup and
reorganize.

We have read the paper by Tsuchiya, "On the Assignment of Subnet Numbers",
which describes a scheme for managing a net in which subnet masks differ in
length.  But are confused by the following question.  If all the neighbors of a
router have a subnet mask <= n bits, how does this router send to a distant
site whose subnet mask is > n bits.  To elaborate (thanks to Alan Batie):

   Suppose you have Subnets A (1001), B (010), C (110), D (001) and E (1000).
       A <-> B <-> C <-> D <-> E
   All three of C's interfaces (link to B, link to D and local network
   interface) have a subnet mask of 11100000.  My theory is that C will
   send all packets for subnet addresses 100 to E, except for packets for
   a host "10010000", which won't exist, because that is A's "this network"
   address.

   To be fair, he does say that you need support for varying subnet masks,
   and specifically mentions OSPF, which does propagate the subnet mask as
   well as the address.

In general, we are unsure whether the varied software (PC-Route, SysV/386,
Xenix, NeXT, VMS/TGV) in RAINet will be able to handle varying subnet masks.

We also have another concern.  As many of the inter-site links are or will be
V.32 or so, we are worried that RIP will eat up bandwidth.

Some of the alternatives we see are:

  o get a class B and subnet with a mask of 0xfff0, with SLIP links still
    eating up a subnet apiece,

  o get a class B and subnet with a mask of 0xff00, but keep the current
    class C for the SLIP links using a subnet mask of 0xfc,

  o each site get its own class C (even if they have but two hosts), and use
    the current C for the SLIP links using a subnet mask of 0xfc, thereby
    creating a gawdawful lot of underutilized class Cs,

  o get n class Cs, where n is, for example, sites/5, and clump multiple sites
    in each C according to physical topology in order to cut down RIP use of
    the small bandwidth, and

  o we're sure there are others.

We presume that we're missing something obvious, that others have gone before
us, and so await your sagely advice.

-- 
Randy Bush  / news@psg.com  / ..!uunet!m2xenix!news 

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 16:13:26 GMT
From:      JCALVO%ANDESCOL@CUNYVM.CUNY.EDU (Jorge Mario Calvo)
To:        comp.protocols.tcp-ip
Subject:   Re: Updated SLIP for Unix System V/386 R4.0

Hola Hugo :

Le cuento que ya traje el slip.tar.Z y lo tengo en mi codigo del U 6000
bajo el directorio src, pero tengo el problema que no compila por que faltan
algunos encabezados del sistema.

Tambien me lo lleve para la pegasus que es tambien System V y SUN es el pro-
pietario de SLIP y tampo compila.

Atte

Jorge Mario

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 16:21:28 GMT
From:      jburt@anasaz.UUCP (John Burtchaell)
To:        comp.protocols.tcp-ip
Subject:   TN3270 and RFC 1041

RFC 1041 states that the 3270-regime command code is 29. We have found it
to be 24 (x'18'/ctrl-X).  Has anyone had a similar experience or any
comments/suggestions to offer? Thanx in advance.
-- 
--
{ames!ncar!noao!asuvax,mcdphx}!anasaz!jburt     anasaz!jburt\ 
John Burtchaell  (602) 395-1743              anasaz.UUCP!jburt>@asuvax
1309 E. Northern Ave., Phoenix, AZ 85020     jburt%anasaz.UUCP/   \.eas.asu.edu

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 18:00:00 GMT
From:      warringt@NPRDC.NAVY.MIL (Jim Warrington)
To:        comp.protocols.tcp-ip
Subject:   Removal from Distribution

Please remove me from tcp-ip mail distribution. Thanks

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 18:03:26 GMT
From:      drubin@prism.poly.edu (Dave Rubin)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   WIN-TCP 3.2 for AT&T 3B2s


After recommendations from various helpful netnews readers, I called AT&T and
upgraded my Wollongong 3.0.1 TCP/IP software for our 3B2/522 to version 3.2.  
Happily, this fixed the dreaded Kernel MMU fault and sendmail problems, 
but created another major problem:

The TCP timeout seems to be set very low.  When opening connections to remote
nodes, after less than 1 second, the response is "Connection timed out."
Does anyone know how to change this timeout value, and is AT&T aware of this
rather significant problem?

Please respond via E-mail. Thanks..

--
Dave Rubin
Polytechnic University, Brooklyn, NY
drubin@prism.poly.edu

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 20:49:20 GMT
From:      CRINGOLO%DUVM@PUCC.PRINCETON.EDU (GINO CRINGOLO)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe


     Please unsubscribe Gino Cringolo

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 20:54:42 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   Need Comparison Of X.400 And SMTP

Can someone tell me what are the key features present in X.400 addressing
that are missing from SMTP-style addresses?  As I understand it, X.400
is a superset of existing mail systems that tries to capture enough
information in the mail address to make it unique on a global network.
Specifically, what does it do in this respect that SMTP cannot do, and
what are some of the other advantages of X.400?

Thanks,
Will Estes        (apple!cup.portal.com!Will)

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 21:14:37 GMT
From:      mahesh@pyrhard2.pyramid.com (Mahesh Jethanandani)
To:        comp.protocols.tcp-ip
Subject:   Re: IP performance evaluation & spray

In article <9103111409.AA10491@hns.com> c_rstine@HNS.COM (Robert Stine) writes:
>
>I'm evaluating the network performance of a single-board computer that
>runs ethernet and TCP/IP; the board has an 82596CA LAN controller.  In
>one of the tests, I use the program "spray", executed from a Sun SPARC
>IPC, to see how well the board can handle high volume IP inputs.

I have done similiar testing between our systems Ethernet board ( I am not
sure what chip it uses) and MIPS 120 box. Here are the results. Actually
these are some of the worst results, I have seen. Generally I would say
anything less than 5% drop in case of RPC and anything less than 10%
for spray with ICMP echo request is good enough.

With spray the most important factor is the buffer you have on the Ethernet
board to receive packets.

Testing with RPC ... Sending 10000 packets
        2457 packets (24.570%) dropped by orville
Testing with ICMP echo request ... Sending 10000 packets
        711 packets (7.110%) dropped by orville
Testing with RPC ... Sending 20000 packets
        4707 packets (23.535%) dropped by orville
Testing with ICMP echo request ... Sending 20000 packets
        14800 packets (74.000%) dropped by orville
Testing with RPC ... Sending 30000 packets
        17076 packets (56.920%) dropped by orville
Testing with ICMP echo request ... Sending 30000 packets
        22802 packets (76.007%) dropped by orville
Testing with RPC ... Sending 40000 packets
        21448 packets (53.620%) dropped by orville
Testing with ICMP echo request ... Sending 40000 packets
        44 packets (0.110%) dropped by orville


mahesh

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 91 23:07:02 GMT
From:      cliff@garnet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in Berkeley popper

The problem with popper reported here last week is real, and serious.  It
appears to have been introduced into popper around September, 1990.  It
would occur if you had compiled popper with -DDEBUG, and then run popper
without the "-d" (debug) flag.

If you compiled popper without -DDEBUG then you are not vulnerable to this
particular bug.  Unfortunately, the Makefile in the popper-1.7.tar.Z file
has -DDEBUG set as the default.

I have changed the default in the makefile in popper-1.7.tar.Z in the ftp
repository.  There is also a popper-1.81beta.tar.Z there which fixes two
other problems.  I believe 1.81 is stable, but will wait for some time
before removing the 1.7 file.

The ftp repository is ftp.CC.Berkeley.EDU.  Its current addresses are:
128.32.136.9, 128.32.206.9, 128.32.206.12, 128.32.136.38.

	Cliff Frost
	UC Berkeley

Re: <9103141743.AA04692@ucbvax.Berkeley.EDU>

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 00:14:03 GMT
From:      bb16@prism.gatech.EDU (Scott Bostater)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   POP2 and POP3 specs

Excuse me if this is not the right place, but I'm looking for documentation
for POP2 and POP3.  Is there an anonymous ftp site that has a complete (and 
concise) document that lists all the communication rules?

Thanks in Advance,


-- 
Scott Bostater      Georgia Tech Research Institute - Radar Systems Analysis
"My soul finds rest in God alone; my salvation comes from Him"  -Ps 62.1
uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16
Internet: bb16@prism.gatech.edu

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 00:53:44 GMT
From:      sfrazier@vlink01.UUCP (Steven E. Frazier)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP SLIP

Could someone help me out?  I have SCO Unix TCP/IP.  It only allows
one SLIP connection at a time.  Does anyone (Interactive, are you out
there) that makes a TCP/IP package that will allow more that one
SLIP connection at a time?

I would like to do something like this:

Location 1             Location 2                 Location 3
Machine A              Machine B                  Machine C
SLIP ----------><------SLIP  SLIP -----------><-------SLIP

I would like to have all three machines up @ 9.6 speed all of
the time with this arrangement.  Any ideas?  Please email
me what you think if you would.

Thanks.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 02:45:01 GMT
From:      tester@cmcl2.nyu.edu (L Testerville)
To:        comp.protocols.tcp-ip
Subject:   Re: Updated SLIP for Unix System V/386 R4.0

JCALVO%ANDESCOL@CUNYVM.CUNY.EDU (Jorge Mario Calvo) writes:
>Hola Hugo :
>Le cuento que ya traje el slip.tar.Z y lo tengo en mi codigo del U 6000
>bajo el directorio src, pero tengo el problema que no compila por que faltan
>algunos encabezados del sistema.
>Tambien me lo lleve para la pegasus que es tambien System V y SUN es el pro-
>pietario de SLIP y tampo compila.
>Atte
>Jorge Mario

Hmmm, is this a joke or maybe part of the problemo?

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 03:00:08 GMT
From:      droms@SOL.BUCKNELL.EDU (Ralph E. Droms)
To:        comp.protocols.tcp-ip
Subject:   Re: list of whois,finger, etc. servers wanted


   There are now lists of online library catalogues that are regularly updated
   and distributed. Is there an equivalent for whois/finger/etc or other
   tcp/ip directory service type servers for the Internet?

I have a student who is compiling such a list.  He's working on
automatic mechanisms for generating a list of known servers and server
types.

This project is part of the "netaddress" service.  When complete,
netaddress will search the list of known servers for likely candidates
to query in addition to the current default servers like
whois@nic.ddn.mil, whois@sh.cs.net, etc.

I'd like to hear of any other, similar compilations.  Maybe someone
can save my student some work...

- Ralph Droms                 Computer Science Department
  droms@bucknell.edu          323 Dana Engineering
                              Bucknell University
  (717) 524-1145              Lewisburg, PA 17837

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 13:00:39 GMT
From:      heinhuis@dri.nl (Gustaaf-Jan Heinhuis)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Novice NFS questions

Being new to news I hope some of you out there can help me with a 
problem.

I'm, together with a fellow student (Gerti Schoemaker), working on
a graduation project in computer science concerning NFS.

For those who want to know, we study at the HIO in Enschede which
is a department of the Higher Technical School. Those who are 
familiar with the Dutch school system will know what this is.

Back to the problem. We know that with NFS one can't share peripheral 
devices. What we would like to know is:
		
		1) why this isn't possible,
		2) if you have a neat way to get around this .
(e.g. for back up's we use: 
find / -print | cpio -ocv | rsh <system name> dd of=/dev/rmt0 bs=5k)
		   
In the "Network User's and Administrator's Guide Vol.2" for the 
ICL DRS6000 running system V.4 I found the following:
		"The objects that can be shared through NFS include any 
		whole or partial directory tree or file hierarchy-including
		a single file. A machine cannot share a file hierarchy that
		overlaps one that is already shared. Special device files,
		as well as ordinary files, can de shared over NFS; however, 
		peripheral devices such as modems and printers cannot be shared."
I'd very much like to know what, in this context and in general, is meant 
by "special device files". I, in my innocence, would say such a file
represents a device (like a printer), but apparently I'm wrong.

If it is possible with NFS to share printers and alike we would like to 
know how this is done.

Gustaaf-Jan Heinhuis & Gerti Schoemaker.
heinhuis@dri.nl		   schoemak@dri.nl

             ***************** I is a brane *****************

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 14:44:51 GMT
From:      rl@slimer.webo.dg.com (Ross Leibowitz)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Streams based RFC 1001/1002

Does anyone have, or know of anyone that has an AT&T V.4 Streams
implementation of RFC 1001/1002?  I'm mostly interested in B nodes, but
any information on M or P nodes would be appreciated.
Thanks
--
----------------------------------------------------------------------
Ross Leibowitz / rl@slimer.webo.dg.com 
Data General Corporation, Westboro, MA     Standard disclaimers apply.
----------------------------------------------------------------------

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 15:18:30 GMT
From:      lrogers@oasys.dt.navy.mil (Larry Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re: list of whois,finger, etc. servers wanted

In article <9103210300.AA01972@sol.bucknell.edu> droms@SOL.BUCKNELL.EDU (Ralph E. Droms) writes:
>   There are now lists of online library catalogues that are regularly updated
>   and distributed. Is there an equivalent for whois/finger/etc or other
>   tcp/ip directory service type servers for the Internet?
>
>This project is part of the "netaddress" service.  When complete,
>netaddress will search the list of known servers for likely candidates
>to query in addition to the current default servers like
>whois@nic.ddn.mil, whois@sh.cs.net, etc.

I would like to know if this database will contain its own entry as a 
default server.  Will it then be classified as mere default server, as opposed
to the meta-default server it set out to be?
   There seems to be a note of history sounding around here...
:-)
 
>
>- Ralph Droms                 Computer Science Department
>  droms@bucknell.edu          323 Dana Engineering
>                              Bucknell University
>  (717) 524-1145              Lewisburg, PA 17837

Please forgive my horrible mangled interpretation of a philosophic debate of
immense importance.  Also I should attribute these things better.

Waxing philosophic,
Larry

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 16:14:51 GMT
From:      cam@md.interlink.com (Chris Markle)
To:        comp.protocols.tcp-ip
Subject:   Routers, IP networks, and wide-area networks

Folks,

(Please respond directly to me and I will summarize for the net.)

When IP routers are connected to each other via X.25 networks, is the X.25
network treated as a single IP network/subnetwork, or is each "point-to
point" link (ie. X.25 virtual circuit) treated as a separate network/sub-
network? (Or are the "links" not treated as networks at all?)

For example, assume that I have an X.25 network with three routers connected
to it, R-a, R-b, and R-c; each router knows about the other two. Each router 
is attached to a single Ethernet; for simplicity, each Ethernet is a separate 
IP network - R-a is attached to 192.1.1, R-b to 192.1.2, and R-c to 192.1.3 
(class C networks all).

Would the X.25 network be assigned a single network number, say 192.1.4, and
each router would have an X.25-side IP address of 192.1.4.x? Or would each
"link" (VC) between each router have network numbers assigned to it (eg.
R-a <-> R-b is 192.1.4, R-a <-> R-c is 192.1.5, and R-b <-> R-c is 192.1.6)?

I'm sure that there's no "cut and dried" answer to this, but I was just
wondering how this is "usually" or "commonly" handled with current IP routers.

(If each link gets an IP network/subnetwork address, it seems like in a big 
X.25 or other wide-area network many addresses will be chewed up just on these
point-to-point links. Even subnetting results in many subnets addresses being
consumed. Like Arsenio says, "hmm...")

Chris Markle
Interlink Computer Sciences

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 16:20:55 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip
Subject:   mbuf header file for ISC TCP/IP 1.2

Below is a discussion I had with someone here at Dell.  My question is: 
is mbuf defined in ISC's TCP/IP 1.1.2 (or 1.2)?   Doug McCallum?  You
out there?  Is Tim right (no pun intended)?

In article <tim.669547641@holly>, tim@dell.co.uk (Tim Wright) writes:
|In <16842@uudell.dell.com> mjhammel@Kepler.dell.com (Michael J. Hammel)
 writes:
| 
| >I'm trying to build some snmp agents and managers (the MIT distribution)
| >and one file uses the following:
| >         struct  mbuf            mbufBuf;
| >But I can't find this anywhere under /usr/include, including in
| >/usr/include/sys/mbuf.h!  Any ideas?  I've seen references to mbufs all
| >over the place, so it must be defined somewhere, I just can't find where.
 
| >I'm know this is a TCP/IP construct (I remember Michael Karels from UCB
| >talk about it being in the BSD distribution at the tutorial I took at
| >Interop last year).  I looked in all the net-based include directories
| >but couldn't find it.  I even know what the structure looks like (its in
| >the text from the tutorial).  I just can't find the right header file.
| 
| Dirty trick warning ! If my memory serves me correctly, you won't find much
| to do with mbufs in V.3 for V.4. They were only a kludge (like clists) to
| do give a memory pool for the socket/TCP code. I'm fairly certain that the
| streams-based TCP-IPs we have use the streams dblocks to store data.
| This is borne out by the fact that if you look at /usr/include/sys/mbuf.h,
| you'll find all the defines reference structure tags such as b_datap, b_wptr
| etc. A quick look at /usr/include/sys/stream.h reveals these to be part of
| struct msgb, so I guess you just alias struct mbuf to struct msgb.
| It's a pity that Lachman or whoever didn't edit the comments in the include
| files to reflect these changes !
| Your mileage may vary :-)
| 
| Tim
| --
| Tim Wright, Dell Computer Corp., Bracknell    |  Domain: tim@dell.co.uk
| Berkshire, UK, RG12 1RW. Tel: +44-344-860456  |  Uucp: ...!ukc!delluk!tim
| Smoke me a Kipper, I'll be back for breakfast - Red Dwarf

Michael J. Hammel        | mjhammel@{Kepler|socrates|feynman}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet 
#define CUTESAYING "Bwahahahahahahahahaha!!!"

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 17:34:30 GMT
From:      kwe@bu-it.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: Help designing address allocation in a metronet

> From: news@m2xenix.psg.com (Randy Bush)
> Newsgroups: comp.protocols.tcp-ip
> Subject: Help designing address allocation in a metronet
> Date: 20 Mar 91 15:06:15 GMT
> 
> We have read the paper by Tsuchiya, "On the Assignment of Subnet Numbers",
> which describes a scheme for managing a net in which subnet masks differ in
> length.  But are confused by the following question.  If all the neighbors of a
> router have a subnet mask <= n bits, how does this router send to a distant
> site whose subnet mask is > n bits. 
> ...

	The router only has to worry about variable subnet masks for
the subnetted net that it participates in.  For distant nets it uses
the netmask that it derives from the net class.

	Within the variably subnetted net, the router must have the
mask for each route.  This is most easily gotten from the routing
protocol and most easily stored in the routing table.

> In general, we are unsure whether the varied software (PC-Route, SysV/386,
> Xenix, NeXT, VMS/TGV) in RAINet will be able to handle varying subnet masks.
> 
	They will all have to support OSPF or some other protocol with
variable length subnet support or else don't vary the subnet mask
length.  (Try gated.)

> We also have another concern.  As many of the inter-site links are or will be
> V.32 or so, we are worried that RIP will eat up bandwidth.
> 
	Another argument for OSPF, which is link state and not
distance vector.  Milo Medin has documentary evidence of reduced
routing bandwidth in the NASA internet to prove that link state is
better in this regard.

	The way most people do this sort of thing is to have one
network for the WAN and each site has its own independent network
space.  Is Class C big enough for RAINnet itself?  Set the subnet mask
all the way down to two nodes per subnet.  That's two bits for the
host part, 0 and 3 are reserved, 1 and 2 are the endpoints of the
link.  Make every subnet in the RAINnet net the same length.  Every
host or router not directly on RAINnet simply routes to the netmasked
route.  That should work and it won't waste subnet space.  If the mask
size is constant you don't need OSPF.  If you are passing around all
RIP routes, try judicious use of default routes.  Prefer dynamic
default via RIP.  If that isn't good enough then try OSPF or some
other link state algorithm to reduce traffic levels.

	--Kent

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 91 18:20:14 GMT
From:      jordan@tcs.com (Jordan Hayes)
To:        comp.protocols.tcp-ip,comp.unix.questions,alt.sys.sun
Subject:   Re: Reliable UDP transport

John Carter <john@wekiwa.uucp> writes:

	I am working on an application which will require a Sun
	workstation to communicate with an external device via UDP.  We
	need to implement some simple means of reliability.

If you need reliability, you have selected the wrong protocol.  If you
selected ("required"?) UDP for it's "light-weight-edness" then you
missed the point.  Rolling your own reliability in user-space will be
more expensive than getting the kernel to deliver your bytes reliably
over TCP.

/jordan

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 00:32:04 GMT
From:      DRWilliams@cup.portal.com (Dave Richard Williams)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: slip over 9600 baud?

I've played with slip connections a bit at 9600, and haven't had any major
problems.  Only had one active session at a time, and was doing pings 
between each host just to see how things went.  The session seemed
alright and the pings were timeed around 240ms per.  
 
Don't know if it'll help at all.  I'm just getting started in all this 
mess myself.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 00:42:29 GMT
From:      DRWilliams@cup.portal.com (Dave Richard Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP SLIP

SCO Unix 3.2 only allows one SLIP at a time?  Did you find this someplace
in the documentation?  IF so please pass info as to where.  I'm working
on a systemm where we'll need to do what you show. (2 SLIPS off one host)
and would hate to get boxed in if that is truly the case.
 
 Mind you I'm new at all this and my SLIP experience on SCO is very
limited.  I've managed to establish a session from a PC running KA9Q's NET
but that's about it.
 
Have you tried doing multiply "slattach"es?  I would think it should
be possible as it labels the connections as "sl0" to indicate the first
SLIP.  Don't have the specs handy, but just type "slattach" for param
lists.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 03:05:07 GMT
From:      stlouis@unixg.ubc.ca (Phill St. Louis)
To:        comp.unix.sysv386,comp.mail.uucp,comp.protocols.tcp-ip
Subject:   UUCP over TCP/IP

I am trying to get UUCP to function over TCP/IP on InterActive Unix 2.2. 

At the start of the Dialers file is a message that says "Types that appear
in the 5th field must be either built-in functions (..., TCP, ...) or ...

My question is how do you use this built-in function?  What I get (with
uucico in x9 debugging mode) when I place TCP in the 5th column is

TCP not found in Dialers file
set interface UNIX
getto ret -1
Call Failed: CAN'T ACCESS DEVICE
exit code 101
Conversation Complete: Status FAILED


My Devices file contains the following line for TCP
TCP,et el - Any TCP -

My Systems file contains the following line for the mirek machine:
cartnet Any TCP - - in:--in: Umirek word: mnuucp1

Any assistance would be much appreciated.

Phill

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 07:50:36 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP SLIP

In article <5@vlink01.UUCP> sfrazier@vlink01.UUCP (Steven E. Frazier) writes:
>Could someone help me out?  I have SCO Unix TCP/IP.  It only allows
>one SLIP connection at a time.  Does anyone (Interactive, are you out
>there) that makes a TCP/IP package that will allow more that one
>SLIP connection at a time?
>
>I would like to do something like this:
>
>Location 1             Location 2                 Location 3
>Machine A              Machine B                  Machine C
>SLIP ----------><------SLIP  SLIP -----------><-------SLIP
>
>I would like to have all three machines up @ 9.6 speed all of
>the time with this arrangement.  Any ideas?  Please email
>me what you think if you would.
>
>Thanks.

I have been trying to get a difinitive answer from SCO on this for
about 5 weeks.  A person at SCO, ericd, told me it was possible to
have more than one slip.  It was reiterated by paul@bohdan.  He
supposedly sent a script which let this happen.  The script either
didn't arrive, or got eaten somewhere.  I fired off a request to
support@sco.com but have heard nothing but all the machines at sco
tell me the message was delivered.

Paul, if you are out there, the script didn't arrive. Please send it
again.

SCO, if you are out there, a response, negative or positive, would be
appreciated, besides the return receipt (which I didn't ask for) from
each of the people that get mail under support@sco.com.

Anyone else?

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

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 13:32:18 GMT
From:      ramsey@NPIRS.Purdue.EDU (Ed Ramsey)
To:        comp.protocols.tcp-ip
Subject:   Vitalink TransLan IV needed

Our project is moving off-campus in a month or two and we were
just informed that the computing center only had one VitaLink
TransLan IV we could use, and that we needed to obtain another
one ourselves :-).

Is anyone in posession of an extra one that would be willing to
talk about a rent/borrow/lease arrangement until we can budget
for the purchase of one?

If not, where is the cheapest place to obtain equipment like
this?

Thanks for any information.

-Ed

Ed Ramsey ramsey@npirs.purdue.edu 317/494-6616 FAX/494-0535

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 15:17:47 GMT
From:      tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: Help designing address allocation in a metronet

> 	Another argument for OSPF, which is link state and not
> distance vector.  Milo Medin has documentary evidence of reduced
> routing bandwidth in the NASA internet to prove that link state is
> better in this regard.
> 

Sorry Kent.  I know this is a REAL nit, but you hit
on one of my pet peeves.  The advantage of OSPF over RIP
in the case of link utilization is not that OSPF is
link-state and RIP is distance-vector, but that OSPF
is event-driven and RIP is periodic.  One can perfectly
well design a distance-vector routing protocol (BGP
for instance) that is event-driven and therefore doesn't
over-utilize link bandwidth.  CA*net is running BGP
over 56kbps links, and advertising ALL 2000+ network
numbers, and is not having problem (except for 
spikes when a router configures because the whole
routing table gets dumped).

That being said, I think that link-state does have
advantages over distance-vector (like ease of debugging
because the whole topology map is right there in
every node), but distance-vector also has certain
advantages over link-state, like dealing with hierarchies
because you don't have the mapping real topology
into logical topology problem that results in things
like pseudo-nodes.

Lecture over :-)

PT
NAADP
(National Association for the Advancement of
Distance-vector Protocols)

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 15:47:35 GMT
From:      mcjimrh@NSCULTRIX1.NETWORK.COM (Rodney H. McJimpsey)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe


please unsubscribe me...

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 16:50:13 GMT
From:      efb@slced1.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Need routed params with SLIP (Sun to BSD VAX)

Past few weeks have gotten us some SLIP from host remote on net REMOTE with
host local on net LOCAL.  remotes neighbors can not talk to remote on 
REMOTE net and only remote and local talk reliably .. we get ripquery back
and forth but what this problem seems to most need now is a better hybrid
of hard routes like the route add REMOTE remote 1 and so on.  I have some
of these but fear they are wrong .. remote is an MV-II running BSD/Tahoe
and local is a Sun 4/20 (SLC) on SunOS 4.1.1.  Link is essentially a mildly
hacked cslipbeta.  Best success is when routed on the remote-BSD end first 
starts and holds 6 values in netstat -nr, which notably holds a line
  REMOTE-net (either remote or local, I forget) ...  WHICH does succeed for
a few minutes, I know, rpc perfmeter (rpc.status packets) makes it across 
the link from remote to local, even other in.routed players on local-net
can ping ( briefly ) the remote-host.  Path is over two Telebits running
PEP.  There have been occasional deaths of local-host with slipen() messages
hanging on syslog.  There is currently a do-loop running on remote to kill
and restart its routed -s whenever less than 6 routes are produced by its
netstat -nr.  When I am able to log off remote and the circuit stays up,
then the routes may be lost less often ( had no restarts, dropping routes
messages on remote for over 8 hours ).

A collection of your slipattach lines, route add lines that connects two
different nets by slip using routed would be greatly appreciated.  My guesses
probably have been why I am messed up still.  WE WILL NOT be trying PPP 
this year and SLIP over existing phones and hardware are our only choices,
for now.  PLEASE, save the SLIP is dead, etc for alt.flames.  Once this
works we hope to get packets from REMOTE-net via local, over LOCAL-net and
out thru an ACC 4100.  It only reports net 26 and net LOCAL to ripquery.
It has rip on and rip neighbor entry local-host, and gateway mode on.

Thanks for any help /Ev/

--
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 17:03:47 GMT
From:      jf@ap.co.umist.ac.uk (John Forrest)
To:        comp.protocols.tcp-ip
Subject:   Need cut down telnet

To provide serial connections from the Mac popper program
Eudora, we need to provide a tcp "pad" facility on our Apollos.
Basically a special user account is entered which should run
a pad program, which allows you to open a pad to a specified
port on a named machine. We are currently using telnet to do
this, but really the functionality required is as follows:

Program enters a "prompt mode" which allows the command:

        open machine port

This provides a stream connection to the port, preferably
line-by-line, but maybe this would be optional. The echoing
needs to be off for all this process [telnet lets us down by
switching the echoing on even when we have turned it off], or
at least if it is already off, it stays off. Once entered,
stdin is send to the pad, and data received from the pad sent
to stdout, in a full duplex way (but line by line to save
overhead). When the connection terminates, the prompt mode is
re-entered. The alternative command is:

        quit

Which will exit the program. [Again telnet lets us down here,
because it always exit and we have to put things into a loop,
and sometimes rely on ^C to abort]. If the program receives any
signals, it should just terminate.

Does anyone have a program like this, or at least tell me where
I might pick up mconnect - which seems a closer starting point
than telnet.

Would you please e-mail me - I don't read this group.

John Forrest
Dept of Computation
UMIST

jf@ap.co.umist.ac.uk

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 18:25:49 GMT
From:      terry@hq.af.mil (Terry Bernstein)
To:        comp.sys.3b1,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   3b/2 telnet checksum problem


I have a problem with a 3b/2 system that communicates fine with every
host over our network, except those connected via 3com cs200 terminal
servers.

The 3b/2 is connected to its own baseband ethernet. An IB/1, 3com
ethernet to broadband bridge, connects the ethernet to the broadband
backbone.  The 3b/2 works fine when connected to from any host on the
network, except cs200s.  When connecting from a cs200, it will
mysteriously hang -- sometimes recovering and sometimes timing out.
It usually hangs during the motd, but in other places as well.  In
looking at the sniffer protocol analyzer, I found that the packet it
hangs on has a bad TCP checksum.  This would make the recipient
discard the packet.  The 3b/2 continues to resend the packet (again
with bad TCP checksums) until the connection times out.  The IP
checksum is always correct and the packet looks ok.  It seems that
somehow the packet is being stamped with the wrong tcp checksum.

We have 3 other 3b/2 systems connected in exactly the same manner.
None of these exhibit this behavior.


The only difference I can think of when connecting with a cs200, is that the tcp/
options it negotiates would be different than those of other hosts.

The symptoms seem to rule out everything except intermittent software
(telnetd), or hardware failure -- but what exactly, and how do we find it?



Any ideas??????




-- terry --



--
------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>   Terry Bernstein        <<terry@hq.af.mil<<<
>"Who is John Galt?">	          	       << The Pentagon  <<<
--------------------------------------------------------------------

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 19:42:32 GMT
From:      basien@pemcom.pem-stuttgart.de (Tillmann A. Basien)
To:        comp.protocols.tcp-ip
Subject:   SLIP to TCP/IP Gateway


Hy, netlanders

	I am searching of a gateway between SLIP and TCP/IP on
	thin-ethernet.
	I have a laptop and I want to connect it to my TCP/IP Thin-Ethernet
	Network in the office. My laptop runs SCO XENIX 2.3.2 and I have a
	RS232.
	There are some adaptors for the parallel port, but the vendors have
	only drivers for DOS/NOVELL.
	Does anybody knows of a little box, which can transform between
	this two physical systems V24 and thin-ethernet?

	Thanks for any answer ?

	This was Tillmann, Stuttgart, Germany

-- 
					             basien@PEM-Stuttgart.de
Dipl.-Ing. Tillmann A. Basien           PEM Programmentwicklungsgesellschaft
Vaihinger Str.49, PostBox 810165                      fuer Microcomputer mbH
FRG 7000 Stuttgart 80             voice: +49-711-713045  fax: +49-711-713047

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 20:38:56 GMT
From:      mkd@cbnewsj.cb.att.com (mark.k.darby)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NIC performance benchmarking


Is there any coordinated effort to develop a benchmark program for network
interface card performance?  I thought that some time ago some group was
going to attempt to create such a thing, but I may be mistaken.

Typically performance comparisons consist of side-by-side testing of
hardware in a given networking environment, thus overall performance
is controlled as much (if not more) by the accompanying driver/software
architecture as the underlying hardware. 

If anybody has any thoughts regarding this subject, or knows of an effort
being pursued along these lines, send me email or post to the net.

Thanks in advance,
Mark K. Darby
mkd@mtung.att.com

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 22:22:59 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Help designing address allocation in a metronet


Kent,

...
	 	The router only has to worry about variable subnet masks for
	 the subnetted net that it participates in.  For distant nets it uses
	 the netmask that it derives from the net class.
	 
	 	Within the variably subnetted net, the router must have the
	 mask for each route.  This is most easily gotten from the routing
	 protocol and most easily stored in the routing table.

This isn't quite true.  There is no requirement that I know of that subnets
have to be connected.  In fact, inside an OSPF routing domain, things can
be configured to work quite well in this way (we actually take advantage
of this for a couple of unique situations).  Since the router doesn't
know that all subnets are connected , it shouldn't make assumptions about
the class of routes.  In fact, OSPF is designed without any hardwiring
of Class A, B, or C routes in it at all; it's just mask and match.  Router
vendors should not make distinctions between net and subnet routes in their
routing table data structures.  There is no need to do it this way.  Routing
on best match is the really preferred way to go.  It's more flexible and
doesn't need be any slower...
	 
...
	 	They will all have to support OSPF or some other protocol with
	 variable length subnet support or else don't vary the subnet mask
	 length.  (Try gated.)

If you don't support variable length masks, I wouldn't consider you a 
compliant OSPF router.  The RENO code can support variable length masks,
and I think Jeff Honig will take advantage of this when porting the UMD OSPF
code to gated...   People need to understand that variable length subnets 
are a real solution to user's problems, and they ought to be firmly
supported.  Don't let your vendor hedge on this!
	 
...
	 	Another argument for OSPF, which is link state and not
	 distance vector.  Milo Medin has documentary evidence of reduced
	 routing bandwidth in the NASA internet to prove that link state is
	 better in this regard.

In the normal case, you are only flooding deltas, not the full routing
table.  Jeff Burgan (also from NASA) gave a very nice summary of operational
experience with OSPF at the last IETF, not just in NSI but also BARRNET
and OARNet, and it's clear that OSPF is a big win here.  Additionally,
John Moy has calculated that in steady state, OSPF could support passing around
~2000 external net routes on a 9.6 Kbps link using only about 5% of the link
bandwidth.  If routers are being attacked and destroyed and routing is having
to converge to new paths, then this figure will go up, but it's piles better
than the utilization of the old style DV protocols in use in various places
today.


	 	The way most people do this sort of thing is to have one
	 network for the WAN and each site has its own independent network
	 space.  Is Class C big enough for RAINnet itself?  Set the subnet mask
	 all the way down to two nodes per subnet.  That's two bits for the
	 host part, 0 and 3 are reserved, 1 and 2 are the endpoints of the
	 link.  Make every subnet in the RAINnet net the same length.  Every
	 host or router not directly on RAINnet simply routes to the netmasked
	 route.  That should work and it won't waste subnet space.  If the mask
	 size is constant you don't need OSPF.  If you are passing around all
	 RIP routes, try judicious use of default routes.  Prefer dynamic
	 default via RIP.  If that isn't good enough then try OSPF or some
	 other link state algorithm to reduce traffic levels.
	 
KA9Q supports variable length masks, so I don't think this is that big 
of a problem.  Who knows, it may even support OSPF one day.  

						Thanks,
						    Milo

" OSPF: Ask for it by name.  Accept no substitutes. "

PS Usual disclaimers apply...

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 91 23:46:03 GMT
From:      kec@tcsc3b2.tcsc.com (Kevin E. Carter)
To:        comp.protocols.tcp-ip
Subject:   At a sticking point - all clean - no ping

We have installed Microport SysVR4 with its version of TCP/IP and have
gotten to a point where all our software loads fine, looks fine, but
I cannot get the two machines to talk to each other.

I have:
	1. Installed nsu, rpc, inet, and wd packages

	2. Tested the Western Digital EtherCard Plus Elite16 Combo boards
	   2.1  Board Diagnostics
 	   2.2  WD packet transfer test on the "SuperDisk"
	   2.3  All packet transfers went through a StarLAN 10 Hub - UTP
           2.4  Link Integrity checks are clean --clears wiring--distance 6m

	3. Checked out our AT&T StarLAN 10 Hub (10BASET) by connecting to
	   an existing StarGROUP 3.4 network
        
	4. Set Up /etc/hosts:

		192.5.88.3	joe
		192.5.88.4	bloe

	5. Set Up /etc/networks
			
		...
		#
		# Local Networks
		#
		tcsc		192.5.88

	6. Set Up /etc/strcf

		...
		cenet	ip	/dev/wd	emd	0	#i386/wd8003

	7. Set Up /etc/ethers

		00:00:c0:cb:3d:23	joe	# machine 1
		00:00:c0:a3:7e:08	bloe	# machine 2

	8. Checked node names with uname -a

	9. Checked out sdevice, kernel versions, etc.

       10. Ran ifconfig emd0 from joe
		emd0: flags=23<UP,BROADCAST,NOTRAILERS>
		 inet 192.5.88.3 netmask ffffff00 broadcast 192.5.88.255

		bloe responds similarly with the proper IP address
		
       11. Ran netstat from joe
		tcp	0	0	joe.2766	*.*	LISTEN

	   from bloe:
		tcp	0	0	bloe.2766	*.*	LISTEN

       12. Ran ping:
		ping joe from joe -- joe is alive
		ping localhost from joe -- localhost is alive
		ping anyhost from joe -- anyhost is alive
		ping 192.5.88.3 from joe -- 192.5.88.3 is alive
		ping bloe from joe -- no answer from bloe
		ping 192.5.88.4 from joe -- no answer from 192.5.88.4

		bloe did the same going for joe

When the software comes up, the board is recognized and the id's match
the entries I made in the /etc/ethers file.  I don't think this matters
anyway since I am not running RARP.  As I said, slink, listen, rpcbind,
everybody thinks things are just dandy.  I don't know where to go next.

We have transmit and receive lights on the boards as well as an activity
light on the hub.  When I ping, the hub does not blink and the card's
transmit light does not blink.  Either that, or it is too fast for me
to see.

More particulars
	Tangent 486/25 PC with 102 MB Hard Disk, 8 MB RAM
	all file systems are ufs, except of course for /stand and
	a partition we set aside called /sysv for s5 filesystem.
	Installs were made from a 60MB cartridge tape.
	Boards:
		Western Digital EtherCard Plus Elite16 Combo
		IRQ	2
		I/O	240
		RAM	16K
		BASE	D0000
		-- both are set up the same, no conflicts are reported
		   by the diagnostics or the idbuild.
		WD8003 Ethernet Driver
		(AT386) 4.0 2.2

ANY help would be appreciated -- to quote a famous movie general:
	"Hell, I'd piss on a sparkplug if I thought it would help."

In the interest of keeping traffic out of the group, please E-Mail 
responses direct to me, unless of course you feel compelled to share
with everyone.  I mean heck, why listen to me? You are going to do 
what you want anyway.  

Thank you for your support...
---
===============================================================================
Kevin E. Carter       The Computer Solution Co., Inc.       Voice: 804-794-3491
-------------------------------------------------------------------------------
INTERNET:	kec@tcsc3b2.tcsc.com
USENET:		...!tcsc3b2!kec
UUCP:		tcsc3b2!kec	(804)794-1514
ATTMAIL:	attmail!tcsc3b2!kec
-------------------------------------------------------------------------------

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 00:34:09 GMT
From:      tony@uhcmtg.phys.hawaii.edu (Antonio Querubin)
To:        comp.protocols.tcp-ip
Subject:   SLIP for AIX PS/2


Has anyone ever ported a SLIP, CSLIP, or PPP package to AIX PS/2 yet?  If
so, where can I get it?

Thanks!

Antonio Querubin
tony@uhcmtg.phys.hawaii.edu

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 01:35:26 GMT
From:      jclark@sdcc6.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: Book: Internetworking with TCP/IP

In article <A744BF72D19FA04604@ccit.arizona.edu> JOHNGALT@CCIT.ARIZONA.EDU ("Dr Galt, I presume?") writes:
>>Just published:
+  I hate books!  Just when you buy one, they come out with a new edition!
+  Why can't we get change files to books?  Or trade-in allowances.

Not that I wish to complain to loudly, I've bought several of Dr.
Comer's books, but it would have been nice to have paperback
suppliments for such things as the machine dependent XINU sources or
Networking stuff. Or better a disk from the publisher or a card for
a disk from the publisher. How many of you have written to
publishers to get things you know to exist and gotten a 'real' time
response? 
-- 

John Clark
jclark@ucsd.edu

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 01:43:04 GMT
From:      jclark@sdcc6.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Sizes

In article <9103151236.AA05472@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
+If you're looking at raw ethernet packet lengths (as opposed to IP
+datagram lengths), you'll see lots of 60 byte packets on the net
+because ethernet has a minimum packet length of 60 bytes. Any packets
+that are shorter are padded out to 60. IP can tell how many bytes it

Sometime ago I had a ethernet analyzer on a line with both TCP/IP
and DECNET traffic. It seems to me that there were some DECNET
packets shorter than the minimum. It could have been a halucination
or does DEC violate the standard.
-- 

John Clark
jclark@ucsd.edu

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 01:46:58 GMT
From:      jclark@sdcc6.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: V3.2 vs V4 UDP and NFS

In article <9103160909.AA01947@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
+Fragment means the packet is fragmented at the IP layer. There's
+information in the IP header that says "this packet has been
+fragmented" as well as where it fits in the reassembled packet.

With UDP and NFS based on it, is there a check sum on the
reassembled packet. It seems that there is an assumption that the
ethernet hardware CRC etc. is enough, but is that true.
-- 

John Clark
jclark@ucsd.edu

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 02:08:02 GMT
From:      MM0F@NS.CC.LEHIGH.EDU (Mary Elizabeth Rudis)
To:        comp.protocols.tcp-ip
Subject:   Mac Berkeley Telnet

I was hoping that someone could send the the complete source for
the latest Berkeley implementation of Telnet for the Macintosh.
I do not have FTP access and therefore am unable to get it myself.
I've got StuffIt and BinHex plus a bunch more comm. utils, so I can
pretty much receive it in any format.

If anyone has information on how to obtain it any other way, please
let me know.

MM0F@LEHIGH.BITNET

BTW: Does anyone have some decent MacTCP code they could send me?

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 04:35:38 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Re: WANTED: map3270 entries for a bunch of terminals

In-Reply-To:  your letter rec'd 16-MAR-1991 11:29:30.52


I am also interested in the above request, could anybody mail it to me
too, please? Thanks in advance.

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

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 12:52:06 GMT
From:      changmk@hpsgm2.sgp.hp.com (Mun Kein Chang)
To:        comp.protocols.tcp-ip
Subject:   GATED and BIND

I'm trying to understand what GATED and BIND is and how it
works. Would really appreaciate any pointers to articles
or RFCs. Thanks.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 17:50:44 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   V3.2 vs V4 UDP and NFS


   Date: 23 Mar 91 01:46:58 GMT
   From: decwrl!ucsd.edu!sdcc6!jclark  (John Clark)
   Organization: University of California, San Diego
   References: <16241@uudell.dell.com>, <9103160909.AA01947@asylum.sf.ca.us>
   Sender: tcp-ip-relay@nic.ddn.mil

   With UDP and NFS based on it, is there a check sum on the
   reassembled packet. It seems that there is an assumption that the
   ethernet hardware CRC etc. is enough, but is that true.

IP carries a mandatory checksum over its headers. UDP carries an
optional checksum over its headers and data. The UDP checksum is
verified after the packet is reassembled by IP and passed on to UDP.
It can be set to 0 to indicate no sum was done.

Certain NFS implementations, like Sun's, do not generate UDP
checksums. Ethernet's CRC check is enough to validate the data *while
it's on the ethernet wire*. It doesn't protect the packets while
they're switched through routers, or copied into the network
interface, or transmitted over a different type of network link, for
instance a serial line.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 18:00:44 GMT
From:      alex@sapphire.idbsu.edu (Alex Feldman)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   tn3270 for HP-UX

Does anyone know where there is a copy of this floating around?
There is not one on iris613.gsfc.nasa.gov, as far as I could
tell.

Specifically, I would like a pd or otherwise free version of tn3270
to run on an HP 9000/400t.  An ftp site would be great, or if 
someone would tarmail me a copy, that would be fine, too.



-- 
	--alex			alex@opal.idbsu.edu

Boise State University doesn't have any opinions.  Therefore, these are 
not the opinions of Boise State University.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 19:03:14 GMT
From:      marcelm@joymrmn.uucp (Marcel Mongeon (Admin))
To:        comp.protocols.tcp-ip
Subject:   NETBIOS over TCP/IP

I have Xenix-Net running over the Excelan NetWare product.  The
documentation indicates that it is running NetBios over TCP/IP
in accordance with RFC's 1002 and 1003.

I also have a DOS based machine in which I have an ethernet Lan
card running a clarkson packet driver and NCSA Telnet.  

When instead of NCSA Telnet, I try to load up a Netbios product
which talks with the packet driver (Specifically the Coconet product)
I can communicate with other DOS machines configured in the
same fashion.  However, I cannot communicate with the Xenix-Net
machines over NetBios even though the Telnet works fine.

I think my problem is that the Coconet product is not using NetBios over
TCP/IP but is instead just using bare NetBios.  Is this correct?

If it is correct, what implementation of Net Bios do I want for my
DOS machines?  Is there any Public Domain implementation that I
could be using?
-- 
|||  Marcel D. Mongeon          
|||  e-mail:    ... (uunet, maccs)!joymrmn!root  or
|||                                joymrmn!marcelm

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 19:38:18 GMT
From:      mpd@anomaly.SBS.COM (Michael P. Deignan)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP SLIP

jdeitch@jadpc.cts.com (Jim Deitch) writes:

>I have been trying to get a difinitive answer from SCO on this for
>about 5 weeks.  A person at SCO, ericd, told me it was possible to
>have more than one slip.  It was reiterated by paul@bohdan.  He
>supposedly sent a script which let this happen.  The script either
>didn't arrive, or got eaten somewhere.  I fired off a request to
>support@sco.com but have heard nothing but all the machines at sco
>tell me the message was delivered.

Welcome to the club! Only I've been waiting more like *4 MONTHS* for
an answer. What I want to do is:


MACHINE A --> dialup SLIP --\   
                            
MACHINE B --> dialup SLIP ---> SCO XENIX BOX <-- dialup SLIP --> JvNCnet
                            
MACHINE C --> dialup SLIP --/

In other words, I want to allow sub-SLIP sites the capability of
dialup capabilities into an SCO box (sometimes simulatenously) which
will be connected to the Internet via a dialup-SLIP connection.

I asked, to no avail. My question was supposedly referred to the sales
department, but I never heard back.

>Paul, if you are out there, the script didn't arrive. Please send it
>again.
 
I would be interested in seeing this script too.

MD
-- 
--  Michael P. Deignan                      / Since I *OWN* SBS.COM,
--  Domain: mpd@anomaly.sbs.com            /  These Opinions Generally
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /   Represent The Opinion Of
-- Telebit: +1 401 455 0347              /    My Company...

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 19:58:30 GMT
From:      jl@newt.sbi.com (Jean-Louis Ecochard)
To:        comp.protocols.tcp-ip
Subject:   SLIP information

iPardon my ignorance, but I would like to know what is SLIP,
the technical details of it. If I build a transmitting 
device (i.e. modem) can I incorporate SLIP on it.

Thanks.
e-mail to jl@chi.sbi.com
-- 
Jean-Louis Ecochard                 O     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~./_\.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                 (__Y__)                 uunet!sbi!chi!jl

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 21:11:26 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: V3.2 vs V4 UDP and NFS

In article <17725@sdcc6.ucsd.edu>, jclark@sdcc6.ucsd.edu (John Clark) writes:
> 
> With UDP and NFS based on it, is there a check sum on the
> reassembled packet. It seems that there is an assumption that the
> ethernet hardware CRC etc. is enough, but is that true.


Many workstation vendors ship with UDP checksums turned on by default.
This provides an end-to-end checksum of the entire NFS/UDP/IP datagram
after reassembly at the destination of any IP fragmentation.

Some customers have strongly held opinions that the CPU cost of computing
the checksum is worthwhile.  On modern hardware, it's hard to disagree.

A major vendor (not my employer, of course!) is said to still be shipping
with UDP checksums off by default.  It is said that a simple adb command
can turn UDP checksums on in recent releases of their software.


Vernon Schryver,   vjs@sgi.com

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 91 21:51:50 GMT
From:      dbuerger@cup.portal.com (David J Buerger)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NIC performance benchmarking

There is an effort to develop benchmarks, not only for
NICs, but also for other aspects of a LAN.  The group is called
Performance Testing Alliance, and has members from manufacturers,
as well as the trade press.  Initial meetings were held at the
last Interop in San Jose, and Networld in Boston.  The first
results from this cooperative effort are supposed to appear by
Networld in October.  For more information, contact Susan 
Spiner at Set Marketing On in New York City, 212/989-3131.

David Buerger

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 00:58:00 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   LPR/LPD protocols specification

Is there an RFC which deals with the LPR/LPD protocol?  I am specifically
looking for the command structure passed between systems.  

The aim of this is to convert a System V spooler/despooler that I have to
be compatible with the Berkeley environment.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200]
Anon. arch. (nuucp) 00:00-06:00 C[SD]T, req: /u/public/sources/DIRECTORY/README

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 01:33:59 GMT
From:      cpcahil@virtech.uucp (Conor P. Cahill)
To:        comp.unix.sysv386,comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Re: UUCP over TCP/IP

stlouis@unixg.ubc.ca (Phill St. Louis) writes:

>I am trying to get UUCP to function over TCP/IP on InterActive Unix 2.2. 

Here is a posting by Bill Kennedy discussing the above subject.  It should
help you solve your problems.

+ Before I start this, many many thanks to Doug Mc Callum and Dick Dunn
+ at ISC for getting me straightened out on the address that nlsadmin
+ wants to make this work, to Bill Bunton at Tools & Techniques, Austin
+ for persevering as I stumble blundered through it, and to Bob Tracy
+ at CDC San Antonio for getting me started.
+ 
+ If you have no interest in a TLI based uucp over TCP/IP, hit `n' now,
+ but if you ever might, save this article, it will save your hair.
+ 
+ Here's the configuration and the problem.  I have two machines that are
+ networked together using ISC TCP/IP.  One of them has both printers that
+ used to be on a third machine connected by a direct 19.2Kbps uucp link.
+ My old lp scripts sort of went by the board when I no longer had a uucp
+ link to the system that had the printers.  It became obvious to me that I
+ had to figure out how to get uucp to work using TLI across the network.
+ TFM has some information on getting RFS to work, but it's silent with
+ respect to uucp using TLI.  A generous and TLI savvy neighbor, Bob Tracy,
+ was able to get things to almost work, but we kept failing in t_bind, it
+ couldn't allocate the address.  ISC lept to the rescue by explaining how
+ the address had to look for the listener to fundtion but we still (by now,
+ Bill Bunton had agreed to help but was falling into similar potholes)
+ couldn't get the originator's uucico to connect with its destination.  What
+ follows is a step-by-step recipe for something that works.  If there is a
+ more elegant way to do it, please feel free to mark it up and re-post.  If
+ there is any generally available documentation (cookbook please, not theory),
+ please tell us too.
+ 
+ Begin by editing /etc/services and create a port for nls.  We used
+ nls	256/tcp		# TLI port
+ if that doesn't suit you, keep track of the port number because you
+ need it to develop the nls address.  Now choose a name for the nls
+ "net_spec" (see NLSADMIN(1M)), we chose tcp.
+ 
+ Initialize the nls net_spec with nlsadmin -i tcp, it will create a
+ directory, /usr/net/nls/tcp and will create some files in it that it
+ uses to actually start the listener.  Now set up the nls service_code
+ nlsadmin -a 101 -c"/usr/lib/uucp/uucico -r0 -iTLI -u loginid" -y "comment" tcp
+ Here loginid is the name of the system who's going to be logging in, on
+ ssbn it's udunsel and on dunsel it's ussbn, both are no password logins
+ since they are local uucp over the ethernet.  I used "dunsel/ssbn uucico"
+ for the comment, all of this ends up in /usr/net/nls/tcp/dbf, you can make
+ a similar entry for cu, choose another service_code, avoid 105 because
+ that's rfs.
+ 
+ Now you have to work up your network address.  We'd have _never_ figured this
+ out without ISC's help!  This is a hex string that is composed of address
+ family (AF_INET), port number, IP address, and padding zeroes.  Here is the
+ format and an example:
+ \x02000100c0fafa010000000000000000    mapped as
+   aaaappppiiiiiiiizzzzzzzzzzzzzzzz
+   |   |   |       +------------------ sixteen padding zeroes
+   |   |   +-------------------------- IP address 192.250.250.1 co.fa.fa.01
+   |   +------------------------------ port address fm /etc/services (256)
+   +---------------------------------- address family, socket address
+ Obviously your mileage is going to vary, but it shouldn't be hard to figure
+ out from this example.  Hang on to it, you're going to use it more than one
+ place...  You have to tell the listener what address he's going to use
+ nlsadmin -l "\x02000100c0fafa010000000000000000" tcp
+ and that number will appear in /usr/net/nls/tcp/addr to be used when you
+ start nls with nlsadmin -s tcp.  Look at /usr/net/nls/tcp/log to be sure
+ that you've gotten started, "Couldn't allocate address" means he can't
+ get to the address you specified, "Invalid argument" means you don't have
+ the right length.
+ 
+ Now you need to make some entries in /usr/lib/uucp/Systems, Devices, and
+ Dialers.  Remember that ssbn and dunsel don't have passwords on each
+ other, we can drop directly into uucico which is what we specified when
+ we added the 101 service code.
+ 
+ Systems:
+ # ssbn's Systems line for contacting dunsel, 192.250.250.2
+ dunsel Any wlknet Any \x02000100c0fafa020000000000000000
+ # dunsel's Systems line for contacting ssbn, 192.250.250.1
+ ssbn   Any wlknet Any \x02000100c0fafa010000000000000000
+ 
+ Devices:
+ wlknet,eg tcp - - TLI \D nls
+ 
+ Dialers:
+ nls "" "" NLPS:000:001:101\N\c
+ 
+ If you used a service_code other than 101 in the nlsadmin -a, replace the
+ 101 in the Dialers entry with the code you used.  Also note that the Systems
+ lines need the address of the system that they are "calling", choose any
+ convenient Devices name, I used wlknet because that's the network name in my
+ /etc/networks.  Now you're ready to test the connection with Uutry.  It
+ goes by too fast to watch, but it's all recorded in /tmp/systemname.  You
+ might have to go through the usual /usr/lib/uucp/Permissions exercise to
+ make them actually talk to each other, but that's unrelated to nls or TCP/IP
+ (I _think_ :-)
+ 
+ Back to the original problem I had set out to solve, my ssbn resident lp
+ scripts just uux the stuff over to dunsel who is physically connected to
+ the printers.  Here's what I use to get to the dot matrix printer:
+ 
+ user=$2
+ options=$5
+ copies=$4
+ shift; shift; shift; shift; shift
+ files="$*"
+ for file in $files
+ do
+ 	uux -  -a$user "dunsel!lp -o$options -n$copies 2>/dev/null" < $file
+ done
+ 
+ The lp setup on dunsel contains all the stuff that worries about lines
+ per inch, pitch, etc.  That's all passed in options, I don't try to use
+ more than one, so beware of quotes/apostrophes.
+ 
+ You'll get some astonishing transfer rates!  My lamebrained lp approach is
+ what I cobbled together because I don't have lpr/lpd and (you can probably
+ tell :-) probably wouldn't understand them if I did.  Don't forget, I didn't
+ claim that this was elegant, just that it works...
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 02:33:08 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Sizes

In article <17724@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes:
    In article <9103151236.AA05472@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
    +If you're looking at raw ethernet packet lengths (as opposed to IP
    +datagram lengths), you'll see lots of 60 byte packets on the net
    +because ethernet has a minimum packet length of 60 bytes. Any packets
    +that are shorter are padded out to 60. IP can tell how many bytes it
    
    Sometime ago I had a ethernet analyzer on a line with both TCP/IP
    and DECNET traffic. It seems to me that there were some DECNET
    packets shorter than the minimum. It could have been a halucination
    or does DEC violate the standard.

Unlikely.  And it depends upon what you're measuring.  A standard (D-I-X)
ethernet frame consists of:

	6 octets of destination
	6 octets of source
	2 octets of type
	46-1500 octets of data
	4 octets of CRC

The minimum frame size is 64 octets (plus 64 bits of preamble and 9.6 us of
interframe spacing). It is possible you were using a "smart" analyzer that
knows the protocol formats well enough to not display fill characters used to
force the frame to the proper minimum size.
-- 
// marc
// home: marc@dumbcat.sf.ca.us		{decwrl,sun}!pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 06:02:05 GMT
From:      FelineGrace@cup.portal.com (Dana B Bourgeois)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

Just got my hands on RFC 1094 (NFS) and it didn't seem to say anything
about licensing.  Off-hand (not being a lawyer) I didn't see anything
that would stop me from taking the RFC and creating my own brand of NFS
for Computer 'X'.  Is there something that keeps me from writing my own
NFS?  Distributing it or selling it?  If so what and why?

Thanks in advance
Dana Bourgeois @ cup.portal.com
"Be EXCELLENT to each other!"  Bob and Ted's Great Adventure.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 09:15:47 GMT
From:      wbonner@eecs.wsu.edu (Wim Bonner)
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: How do I detect an active TCP/IP (IBM) under OS/2?

In article <8281@umd5.umd.edu> dzoey@terminus.umd.edu (Joe Herman) writes:
>from the socket() (or sock_init()) call.  However, if inet is not
>functioning the call to socket() causes the program to exit.  Since
>the program can still function without TCP/IP, this is not a desired
>behavior.

Is the socket call in a DLL?  If so you may be running into a similar problem
I've had with my network programming in that all of the LANMAN calls are 
actually located in DLLs, and so the first call kills the program.  The solution
that was suggested to me, was to try to demand load the call and if that was 
successful, assume the network was loaded and make the call.  If you cannot 
demand load the call, the DLLs are not available, so don't make any network 
calls.

Unfortunately, I'm not at my own computer right now, so I can't post the 
suggested code.  I'll try to remember to put it up tomorrow when I can get to my
computer.

Wim.
-- 
|  wbonner@yoda.eecs.wsu.edu  |
| 27313853@wsuvm1.csc.wsu.edu |
|  72561.3135@CompuServe.com  |

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 21:10:33 GMT
From:      ljm@FTP.COM (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR/LPD protocols specification

>
>Is there an RFC which deals with the LPR/LPD protocol?...
>

RFC 1179. 

enjoy,
leo j mclaughlin iii
(author RFC 1179)
ljm@ftp.com

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 91 21:51:25 GMT
From:      object@ibmpcug.co.uk (Ken Tough)
To:        comp.protocols.tcp-ip,connect.audit
Subject:   TCP/IP and the XINU OS.

We create applications for systems running a real-time operating
system very closely based on XINU.

We are now interested in "opening" up the systems, by linking to
networks using media such as Ethernet, and also by providing 
X-Windows graphical interfaces (see following article).

For this, it seems TCP/IP is crucial.  We have studied 
"Internetworking with XINU" carefully, and would like to know if
anyone has fully implemented TCP for XINU.  Is there an evolving
body of XINU-based TCP software somewhere?

Does anyone who has implemented TCP have any words of wisdom for
how long it would take to get a fast version up and running for our 
real-time applications?

How big is the executable code?  How much processing power would it
take (approximately, 16 bit 68000).

Thanks for your help, 

Ken Tough                     
===========================================================================
      {~~    (    ))             _         __ m  m      /     OBJECTIVE 
      I\      (___)      ___    <*>      (~ ))  m      /      TECHNOLOGIES
     /I \              (~   ~)   ~       (( _)   m    |  |    Falmouth,
    / I  \            (_     ))                      /        Cornwall,
   /__I___\             (____)                      | |/      United Kingdom
~ ____I____. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/| \       44 326 76896
 <_________|)   _____  ~~~ __  ~~--__  --  ~~ ___/|     | FAX 44 326 77689
-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- 

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 01:54:53 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: Need routed params with SLIP (Sun to BSD VAX)

Perhaps you should look into gated, which is supposed to handle
point to point links better than routed.

	-John Kalucki
	johnk@gordian.com

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 05:02:00 GMT
From:      DAMIAN@SRLVX0.SRL.FORD.COM ("Jerry Damian")
To:        comp.protocols.tcp-ip
Subject:   Can "springboarding" be prevented?

Netlanders,
	Is there a way to prevent a selected user(s) from TELNETing to other hosts once s/he has TELNETed in? I would like to be able limit TCP/IP services in
general to particular users depending upon the subnet from where they came. Things like secure inetd work with incoming connections, but is there anything I canuse to limit outgoing connections based on where the call originated?

				Thanks in advance,
				Jerry Damian
				Ford Motor Co.
                                damian@srlvx0.srl.ford.com

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 08:45:50 GMT
From:      dhuber@aut.autelca.ascom.ch (Daniel Huber)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Printing from AS/400 to UNIX printers

I have a similar question like Betty...

Is there a way to print from an AS/400 (with TCP/IP subsystem) to UNIX
printers ?
The other way would be nice too..  :-)

Daniel


-- 
Daniel Huber AD-KT2.6   VOICE: +41 31 52 96 64 FAX: +41 31 52 97 51
Ascom Autelca AG        Network Engineer, Network,Mail and News Manager
CH-3073 Guemligen       EMAIL:  dhuber@autelca.ascom.ch
Switzerland             UUCP:   uunet!chx400!hslrswi!aut!dhuber

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 10:08:26 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   Mac Berkeley Telnet


Could you let me have a summary of info recieved please? thanks
_______________________________________________________________________________
Snailmail: Gordon Byron,  Arts Computing Advisor,Pathfoot Building, 
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786 73171: Ext 7266  Fax: +78651335
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 14:14:30 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: NETBIOS over TCP/IP


    I think my problem is that the Coconet product is not using NetBios over
    TCP/IP but is instead just using bare NetBios.  Is this correct?

It's using some proprietary transport protocol instead of TCP/IP; there isn't
really any such thing as "bare Netbios".
    
    If it is correct, what implementation of Net Bios do I want for my
    DOS machines?  Is there any Public Domain implementation that I
    could be using?

All the DOS TCP/IP Netbioses are commercial: FTP Software, Wollongong,
Excelan/Novell, Ungermann-Bass, CMC, Interlan.  Any of them should talk
to the SCO product.

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

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 14:14:31 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS


    ...  Is there something that keeps me from writing my own
    NFS?  Distributing it or selling it?  If so what and why?

Only the fact that "NFS" is a registered trademark of Sun Microsystems, Inc.
Name it "Foo (an implementation of Sun's NFS protocol)" or the like and
you're off.

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

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 14:14:32 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: TELNET slow through bridge.

One difficult tradeoff when deciding which packet to drop is which end
of the TCP window to start from.  Most VJ TCPs seem to react badly when
you drop the more recent packets first, so since v2.04 we drop the older
ones.  This can interact badly with some TCP retransmit algorithms, but
they're in the minority.  In any case, reducing the PC's TCP window
to 2048 or 1024 bytes should help.

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

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 14:14:33 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 and RFC 1041


    RFC 1041 states that the 3270-regime command code is 29. We have found it
    to be 24 (x'18'/ctrl-X).  Has anyone had a similar experience or any
    comments/suggestions to offer? Thanx in advance.

RFC 1041 is correct; the problem is that it DOES NOT describe current TN3270
practice.  I would be very surprised if you actually found an implementation
of 1041 outside IBM.  See my posting of a few weeks ago for a description of
current TN3270 practice.  The 0x18 value you see is the Telnet Terminal Type
option, as widely used by both Ascii and 3270 Telnets...

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

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 14:38:13 GMT
From:      ibmman@eng.clemson.edu ((the) IBMMAN)
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: How do I detect an active TCP/IP (IBM) under OS/2?

Even if you can demand load the call, that doesn't mean that the TCP/IP
software is running, although this is usually the case.

Cheers,
Q

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 15:45:17 GMT
From:      barryf@aix01.aix.rpi.edu (Barry B. Floyd)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

FelineGrace@cup.portal.com (Dana B Bourgeois) writes:

>Just got my hands on RFC 1094 (NFS) and it didn't seem to say anything
>about licensing.  Off-hand (not being a lawyer) I didn't see anything
>that would stop me from taking the RFC and creating my own brand of NFS
>for Computer 'X'.  Is there something that keeps me from writing my own
>NFS?  Distributing it or selling it?  If so what and why?
 
>Thanks in advance
>Dana Bourgeois @ cup.portal.com
>"Be EXCELLENT to each other!"  Bob and Ted's Great Adventure.
 
I am no expert on these matters, either. It is my understanding that
"nfs" is based on RPC nad NDR (?) BOTH are public domain. If you can
take RFC 1094, RPC and NDR and mix them together to get a working
"nfs", you got yourself a commercial product or shareware (as you see fit).
 
Obviously your implementation may differ significantly in detail to Sun,
B&W, FTP Software's incarnations. They all should perform the same functions
though, in accordence with RFC 1094.
 
my 2 cents worth...
 
barry

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

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 16:37:53 GMT
From:      jeffmc@dbase.A-T.COM (Jeff McCrimon)
To:        comp.windows.ms,comp.protocols.tcp-ip
Subject:   WinQVT/Net and 3C503 DMA support

Help!  Version 1.3 of WinQVT/Net has the Clarkson Packet
Driver library which includes a driver for the
Etherlink II (3C503) adapter that only supports 
shared memory mode.  Is there an update to this
packet driver for the 3C503 that supports DMA
mode?  The notes for the 3C503 driver states that
the last update was on July 27, 1989, although
the file 3C503.COM is dated 8/29/90.

Any help on this would be greatly appreciated!
Thanx in advance!  You can reply to this board
as I follow it regularly.
   =Jeffrey=

-- 
.signature is under development 

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Mar 91 19:14:26 GMT
From:      mal@terminator.cc.umich.edu (Mark Law)
To:        comp.protocols.tcp-ip
Subject:   PCFTP Idrive configuration

In attemting to configure FTP's PC/TCP product, I came across the following linein the configuration file.

[pctcp idrive]
vax = foo.net.com /users/guest/foo i: user fred 

From this it looks like I should be able to remotely mount a file structure and call it my "I:" drive on my PC.  I've been unable to find this documented any-
where in the 2.05 literature.  
--
Mark A. Law   mal@terminator.cc.umich.edu    (313) 936-4910
Information & Networking Services            University of Michigan Hospitals

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 22:16:45 GMT
From:      rogers@ux1.cso.uiuc.edu (Bill Rogers)
To:        comp.protocols.tcp-ip
Subject:   Problems with packet driver and 3c505 card.

I'm posting this because Mr. Freeman doesn't have an account. Please

We are trying to use the BYU 3c505 version 8 packet driver to run both tcp/ip 
and Novell on one machine. The machine in questionis a 286 clone. The following
is the section of my autoexec.bat that loads the driver and loads/logs on to the
Novell server.

3c505 -d 0x60 5 0x300 0xd000
ipx
net3
set path = h:\;%path%;
cd\
e:
login freeman
c:

Everything seems to work just great. I can start up applications on Novell and
do all kinds of things, exit out of them, etc. I can also run tcp/ip (both KA9Q
and cmu-pcip) and it works. I can telnet, ftp, ping and so on. But when I try
to exit the tcp/ip software, the computer hangs up and will do nothing but
blink its cursor at me.  I have tried  loading the packet driver with the -n
option as well but then tcp/ip doesn't work and I still get hung up when trying
to exit. I have also tried loading the version 8 IPXPKT on top of IPX ( with
and without -n and -d options) and attaching that packet driver in KA9Q as well
with the same problems.

So I would appreciate any suggestions or known cures for what is either a bug
or my stupidity! Thanks in advance, Jay Freeman.

Please reply to me or the Net, Thanks,
Bill
rogers@ux1.cso.uiuc.edu

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Mar 1991 23:01:24 GMT
From:      fortinp@bwdls56.Berkeley.EDU (Pierre Fortin)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Sizes

In article <271@dumbcat.sf.ca.us>, marc@dumbcat.sf.ca.us (Marco S Hyman)
writes:
|>In article <17724@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes:
|>    In article <9103151236.AA05472@asylum.sf.ca.us>
 romkey@asylum.sf.ca.us writes:
|>    +If you're looking at raw ethernet packet lengths (as opposed to IP
|>    +datagram lengths), you'll see lots of 60 byte packets on the net
|>    +because ethernet has a minimum packet length of 60 bytes. Any packets
|>    +that are shorter are padded out to 60. IP can tell how many bytes it
|>    
|>    Sometime ago I had a ethernet analyzer on a line with both TCP/IP
|>    and DECNET traffic. It seems to me that there were some DECNET
|>    packets shorter than the minimum. It could have been a halucination
|>    or does DEC violate the standard.
|>
|>Unlikely.  And it depends upon what you're measuring.  A standard (D-I-X)
|>ethernet frame consists of:
|>
|>	6 octets of destination
|>	6 octets of source
|>	2 octets of type
|>	46-1500 octets of data
|>	4 octets of CRC
|>
|>The minimum frame size is 64 octets (plus 64 bits of preamble and 9.6 us of
|>interframe spacing). It is possible you were using a "smart" analyzer that
|>knows the protocol formats well enough to not display fill characters used to
|>force the frame to the proper minimum size.

Actually, I've seen the same thing in the past (haven't looked at a
trace for some
time now :)   I may be wrong, but I think these short packets are coming from 
bridges on the network; I was once told that these are part of the
spanning-tree 
stuff...  Maybe someone else can add more...

|>-- 
|>// marc
|>// home: marc@dumbcat.sf.ca.us		{decwrl,sun}!pacbell!dumbcat!marc
|>// work: marc@ascend.com		uunet!aria!marc
                             
Cheers,                      
Pierre Fortin       fortinp@bnr.ca         (613)763-2598

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 91 23:16:51 GMT
From:      mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tn3270 for HP-UX

In article <1991Mar23.180044.10723@sapphire.idbsu.edu> alex@sapphire.idbsu.edu (Alex Feldman) writes:
>Does anyone know where there is a copy of this floating around?
>An ftp site would be great, or if someone would tarmail me a copy, that
>would be fine, too.

Try anonymous ftp from ucbarpa.berkeley.edu, in pub/tn3270 or something.
I've built it for HP-UX on an 800, should compile fairly easily on a 400.

mjb.


"I'll wear dark glasses, maybe a toupee,
 I'll get down and boogie, become risque"

                                                         mjb@hoosier.utah.edu

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 00:43:09 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   X.400 Questions

I have two questions regarding X.400:

1) Is there currently any definition of X.400 running over TCP/IP?
Assuming that the various Internet bodies see X.400 as the way to
go (by the way, do they?), then how will they transition from SMTP
style addresses to X.400 addresses?

2) I've noticed that a lot of vendors are using X.400 as a way to
gateway between different proprietary email systems (as opposed to
incorporating X.400 style addresses directly into the user interface
of the email product).  Is my observation correct?  In the case of
using X.400 as a gateway and not incorporating X.400 style addresses
into the user interface, does it then become the duty of the X.400
administrator to setup a correspondence in the gateway between the
X.400 name and each of the corresponding names in the proprietary email
system?  This makes me think that X.400 would be expensive to maintain.

Thanks,
Will Estes        Internet: Will@cup.portal.com
                  UUCP: apple!cup.portal.com!Will

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 06:14:40 GMT
From:      tester@cmcl2.nyu.edu (L Testerville)
To:        comp.protocols.tcp-ip
Subject:   Telnet From Xterm to Host Is Dropped By Host Immediately


 An Xterm tries to telnet over to a 3B2/600 host running SVR3.2.1 and
WIN/TCP 3.0 - as soon as a connection is made, it is then dropped
(apparently) by the host with the following error message:
"Connection closed by foreign host"

 Is there something that needs to be done to hosts, networks, services,
etc. that I am just completely ignorant about.  RTFM?  Which FM?

 This enigma was posted to comp.sys.att so if any of you know what's
happening, a crossposted reply to that group might be appreciated by
those who shared my problem.

  \\Lee
thx1138@nyu.edu

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Mar 91 14:29:34 GMT
From:      mussar@bcars53.uucp (G. Mussar)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers, IP networks, and wide-area networks


In article <9103211614.AA22207@leo.md.interlink.com> cam@md.interlink.com (Chris Markle) writes:
>Folks,
>
>(Please respond directly to me and I will summarize for the net.)
>
>When IP routers are connected to each other via X.25 networks, is the X.25
>network treated as a single IP network/subnetwork, or is each "point-to
>point" link (ie. X.25 virtual circuit) treated as a separate network/sub-
>network? (Or are the "links" not treated as networks at all?)
>
 ...
>Would the X.25 network be assigned a single network number, say 192.1.4, and
>each router would have an X.25-side IP address of 192.1.4.x? Or would each
>"link" (VC) between each router have network numbers assigned to it (eg.
>R-a <-> R-b is 192.1.4, R-a <-> R-c is 192.1.5, and R-b <-> R-c is 192.1.6)?

I have a very small setup and I assign the X.25 network one subnet. Each
router X.25 interface is assigned an IP address from that one subnet. It
works for me, but then again, I might be doing everything non-standard.
--
-------------------------------------------------------------------------------
Gary Mussar  |Internet:  mussar@bnr.ca                |  Phone: (613) 763-4937
BNR Ltd.     |                                        |  FAX:   (613) 763-2626

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 14:34:27 GMT
From:      jra@lawday.DaytonOh.NCR.COM (John R Ackermann)
To:        comp.protocols.tcp-ip,comp.terminals
Subject:   ansi.sys, termcap, and ka9q

We're using the ka9q (both net and nos versions) software to telnet to
an NCR Tower for terminal sessions.

Including ansi.sys in the config.sys file of the pcs and using the
"pcxt" termcap definition in the Tower results in tolerable performance,
but it's a fairly basic set of terminal services... the pc's arrow keys
don't work, for example.

I'd really like to come up with a combination on both ends of the link
that will allow a smoother terminal interface... working arrow keys,
etc., will make users much happier.  Changing to another telnet program
isn't an option... we're running this network over ham radio and need
the other features of the ka9q software.

Can I either run a better termcap/terminfo on the Tower, or a better
ansi emulation on the pc (or both...) to add this functionality?

Thanks in advance.

-- 
John R. Ackermann, Jr.        Law Department, NCR Corporation, Dayton, Ohio
(513) 445-2966		      John.Ackermann@daytonoh.ncr.com
Packet Radio: ag9v@n8acv      tcp/ip: ag9v@ag9v.ampr [44.70.12.34]

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 14:50:16 GMT
From:      oleg@arnor.UUCP
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: How do I detect an active TCP/IP (IBM) under OS/2?

In article <8281@umd5.umd.edu> dzoey@terminus.umd.edu (Joe Herman) writes:
>from the socket() (or sock_init()) call.  However, if inet is not
>functioning the call to socket() causes the program to exit.  Since
>the program can still function without TCP/IP, this is not a desired
>behavior.

INET.EXE allocates a shared segment \SHAREMEM\MAILBOX. You can check
if the segment is allocated before making the first socket call.

Oleg Vishnepolsky

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 14:53:00 GMT
From:      DAMIAN@srlvx0.srl.ford.com ("Jerry Damian")
To:        comp.protocols.tcp-ip
Subject:   Re: Can "springboarding" be prevented?

Netlanders,

   The problem of "springboarding" I posted to this mail group on 3/25/91 can better be described
with the following figure:

                   -----     -----    56kb link
                  | WSB |   | RTB |-------
                  |     |   |     |      /      -----
                   -----     -----      -------| RTA |
                     |         |               |     |
                     |         |                -----
                     |         |                  | 
            isolated | subnet  |           remote | subnet          
            -------------------------      ------------------
                          |                            |
                          |                            |
                        -----                        -----
                       | RTC |                      | WSA |
                       |     |                      |     |
                        -----                        -----
                          |
                    local | subnet
                  ------------------
                     |         |
                   -----     -----
                  | WSC |   | WSD |
                  |     |   |     |
                   -----     -----

   where:
          WS[A-D] = workstations
          RT[A-C] = routers with filters

 Problem: WSA is a workstation on a remote subnet. A user on WSA needs to
 TELNET to WSC on the local subnet in order to use resources there. However,
 once that user has connected to WSC what (if anything) can be used to prevent
 s/he from using WSC as a "springboard" to attempt to break into machines on
 the local subnet i.e. WSD? At the same time a user from WSC must still be
 able to connect to WSD. I need a way to restrict TCP/IP services on WSC based
 on whether the call originated from the remote subnet.   

 Note: Any user on WSA wanting to connect to WSC must first TELNET to WSB
 as a first line of defense. This can be accomplished via filters(IP address
 and port number) on RTB and RTC. Also, once the user from WSA has gotten
 past WSB and RTC and is connected to WSC his/her packets cannot be distinguished
 from a local user on WSC wanting to use resources on WSD.

 What are my options? Simply isolating WSC on its own subnet won't help. Is some kind
 of a kernel modification required? If so, what?

				Thanks in advance,
				Jerry Damian
				Ford Motor Company
				damian@srlvx0.srl.ford.com

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Mar 91 16:19:26 GMT
From:      mussar@bcars53.uucp (G. Mussar)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers, IP networks, and wide-area networks


In article <9103211614.AA22207@leo.md.interlink.com> cam@md.interlink.com (Chris Markle) writes:
>Folks,
>
>(Please respond directly to me and I will summarize for the net.)
>
>When IP routers are connected to each other via X.25 networks, is the X.25
>network treated as a single IP network/subnetwork, or is each "point-to
>point" link (ie. X.25 virtual circuit) treated as a separate network/sub-
>network? (Or are the "links" not treated as networks at all?)
>
 ...
>Would the X.25 network be assigned a single network number, say 192.1.4, and
>each router would have an X.25-side IP address of 192.1.4.x? Or would each
>"link" (VC) between each router have network numbers assigned to it (eg.
>R-a <-> R-b is 192.1.4, R-a <-> R-c is 192.1.5, and R-b <-> R-c is 192.1.6)?

I have a very small setup and I assign the X.25 network one subnet. Each
router X.25 interface is assigned an IP address from that one subnet. It
works for me, but then again, I might be doing everything non-standard.


--
-------------------------------------------------------------------------------
Gary Mussar  |Internet:  mussar@bnr.ca                |  Phone: (613) 763-4937
BNR Ltd.     |                                        |  FAX:   (613) 763-2626

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 17:04:20 GMT
From:      sadler@heurikon.heurikon.com (Jonathan Sadler)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP for PDP 11/23


    I have a PDP 11/23 running RSX-11 that is part of a GENRAD in-circut test
system.  Does anyone know of a TCP/IP implementation for this beastie?

    Please respond via e-mail.  If there is sufficient interest, I'll sumarize
to the group.

Jonathan Sadler
--
   Jonathan Sadler, Heurikon Corp, Madison, WI, jonathan.sadler@heurikon.com
"How information  is to be used is one of the  ways  computers  affect property
 relationships.  Democratic social values of privacy and freedom often conflict
 with our concepts of personal and corporate property." - Judith A. Perrolle

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 17:13:49 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

In article <40519@cup.portal.com> FelineGrace@cup.portal.com (Dana B
Bourgeois) writes:

   Is there something that keeps me from writing my own
   NFS?  Distributing it or selling it?

Nope, nothing at all.  It's been done, in fact.  I believe that Sun has
a trademark on the acronym "NFS", and they like you to pay them some
nominal fee to call your own stuff "NFS," but I'm not completely sure.
In any case, nothing will stop you from building the code and selling it...

--
Amanda Walker						      amanda@visix.com
Visix Software Inc.					...!uunet!visix!amanda
-- 
"An ignorance of history is not just stupid, it's rude."    --Paul Jennett

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 17:38:26 GMT
From:      wangw@ul.ie
To:        comp.protocols.tcp-ip
Subject:   Help: DOS resident programming using 3+open TCP


Hello, netter.
(Please forgive me if it is a duplicate one)
I have a problem when programming a resident server programm using
3+open tcp development package. The exact problem is: when I didn't
let the program resident, it runs o.k. but when I tried to let
it resident, the "select" call returns an error: errno = 100 . The
error is: ENOTSOCK(socket operation on non-socket). I am using
C TOOLS PLUS/6.0 from Blaise Computing to keep a program resident.
The way it does is using bios interrupt 0x08 or 0x28.
The machine I am using is intel 402(486 pc) and DOS 3.3 with
3+open tcp v1.1.

1. Is there anyone who have used 3+open development to program
   a network server program(resident) can give me some advice
   and help to do it?

2. It seems that the "select" call in 3+open can not be called in
   a resident program. Is it a product problem?

3. Any suggestion of using resident program for networking server?
   and is there one who can kindly provide one or two example program?
   
4. Is there any public domain server(FTP) provide pc-tcp application
   program source code?

Could you please reply directly to my e-mail account? If there are
enough interests, I will post a summary. 
Thank you in advance.


Regards

Weijun Wang (wangw@ul.ie)
E&CE Dept.
Univ. of Limerick
Ireland

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 18:15:32 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   LANTRONIX terminal server comments?

I am interested in comments about Lantronix tcp/ip-LAT terminal servers.  We
a looking for some small (physically & # ports) terminal servers and the
good price of lantronix is attractive.  I would especially like to hear about
their reliability from a hardware and software standpoint and the SNMP
capabilities such as extended MIBS for remote configuration.

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

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 18:19:59 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   Hello Christoph Schittel!

Sorry that I have to post this but mail to schittel@geo.uni-koeln.de has
bounced numerous times.

I am interested in getting a copy of the tcpcon software that you mentioned
in your letter to me.  Can we arrange this?

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

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 19:24:47 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers, IP networks, and wide-area networks

In article <9103211614.AA22207@leo.md.interlink.com>
   cam@md.interlink.com (Chris Markle) writes:
>When IP routers are connected to each other via X.25 networks, is the X.25
>network treated as a single IP network/subnetwork, or is each "point-to
>point" link (ie. X.25 virtual circuit) treated as a separate network/sub-
>network? (Or are the "links" not treated as networks at all?)

The IETF/IPLPDN group has just been discussing analogous stuff regarding
Frame Relay, so this is a resonably warm topic.

When IP-over-X.25 was first defined, and implemented for CSNET, network
number 14 was reserved as the IP representation of the global X.25
internet.  So the whole IP world was ONE IP subnet.
(Only the CSNET subscribers ever made it onto the list, and there was
no simple mechanism for other sites to register, or to perform address
translation lookups, so it fizzled.)

When MILNET/ARPAnet implemented X.25 host-to-IMP protocol, the IP
network(s) already existed, and X.25 addressing was a thin overlay.
So MILNET was one IP subnet, and ARPAnet was another IP subnet.

When SUN implemented their commercial IP/X25 encapsulation product, they
chose to view the X.25 interface as a collection of point-to-point
connections. One consequence of this was that the host had a different
IP address for each remote host that it connected to.

ACC's commercial X.25 products follow the "one subnet" model. So do
CMC's.

>For example, assume that I have an X.25 network with three routers connected
>to it, R-a, R-b, and R-c; each router knows about the other two. Each router 
>is attached to a single Ethernet; for simplicity, each Ethernet is a separate 
>IP network - R-a is attached to 192.1.1, R-b to 192.1.2, and R-c to 192.1.3 
>(class C networks all).
>
>Would the X.25 network be assigned a single network number, say 192.1.4, and
>each router would have an X.25-side IP address of 192.1.4.x? Or would each
>"link" (VC) between each router have network numbers assigned to it (eg.
>R-a <-> R-b is 192.1.4, R-a <-> R-c is 192.1.5, and R-b <-> R-c is 192.1.6)?

Both models are "common". They do not interoperate well.

The "one subnet" is easier to manage. The "point-to-point" model allows
certain configurations that are difficult to implement with the "one
subnet" model.

>(If each link gets an IP network/subnetwork address, it seems like in a big 
>X.25 or other wide-area network many addresses will be chewed up just on these
>point-to-point links. Even subnetting results in many subnets addresses being
>consumed. Like Arsenio says, "hmm...")

Actually, Berkeley-based IP routers know that point-to-point links have
one IP address at each end, and are not necessarily "networks". It is
still a pain to handle.

>Chris Markle
>Interlink Computer Sciences

Say Hi to the gang for me !!
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 19:29:01 GMT
From:      jf@ap.co.umist.ac.uk (John Forrest)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Subnetted TCP addresses and Webster MultiGates

We have ordered a Webster Multiport Gateway and are about to
put in a Localtalk network for our Macs. In preperation we have
put up CAP (to ensure it compiled on our Apollo's) and a few
other things. We've got hold of atalkad, and have compiled that
too. I am a bit concerned, though, about the issue of TCP
subnets in the configuration. The program obviously supports
them, but only refers to the use of whole number subnets.

Since our group has a separate network, our group is allocated
a registered TYPE C network address (192.84.82). This we subnet
using three subnet bits, to give a potential of 6 physical
networks of 30 nodes each. [subnetmask ffffffe0]. This serves
us well because we have two physically separate networks as it
is, and want to add one or two for the Localtalk networks.
Essentially we plan to use two of the Multigates four Localtalk
ports for standard use (one is to be dedicated to a laser, and
the other kept spare for the moment). I was hoping to use two
of the subnets for these - or have a single one (I'm not yet
that concerned which). If I can't use subnets, this is going to
be scuppered.

Could someone please let me know if my plan is feasible, or if
I have to work around this. The problem seems to be that of
setting broadcasting addresses, but maybe it is worse. As far
as I can tell, MacTCP is happy with subnets - it definitely
allows you to set them up.

John Forrest
Dept of Computation
UMIST

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 91 23:14:15 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Mystery Packet?

Can anyone help me identify this packet:

0:0:b0:0:60:14 1:0:b0:0:0:0 004e 78: 
015a ff0f 0101 7001 0000 00aa 4000 ffff
ffff ffff 0000 93e0 20d3 0806 0001 0800
0604 0001 0000 93e0 20d3 808c 0108 0104
046c 0017 808c 0e03 3c4f e2a5 5018 1068
4839 0000 0000 0000 0000 ed1b 4a9e

I presume its 802.2 because of the "length field" 004e,
but the SAP and DSAP mean nothing to me. I see what 
looks like an ARP packet embedded in it. Other packets
of this sort have Appletalk embedded.


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

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 00:00:37 GMT
From:      cs@Eng.Sun.COM (Carl Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS


> Just got my hands on RFC 1094 (NFS) and it didn't seem to say anything
> about licensing.  Off-hand (not being a lawyer) I didn't see anything
> that would stop me from taking the RFC and creating my own brand of NFS
> for Computer 'X'.  Is there something that keeps me from writing my own
> NFS?  Distributing it or selling it?  If so what and why?

	Nothing at all prevents you from doing this.  Many people (and vendors)
have already done so.  However, if you do, please do your potential users a
favor and bring the implementation to the annual Connectathon (an engineering
interoperability testing event that includes both NFS and X Window System
testing).  Connectathon details are announced every year in the newsgroup
comp.protocols.nfs.

			Carl

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 04:19:54 GMT
From:      schoff@PSI.COM (Marty Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   A Milestone:  The Commercial Internet Exchange (CIX)


				     

				
			     FOR IMMEDIATE RELEASE
			  

CONTACT:

Julie Shisler		   Martin L. Schoffstall      Rick Adams
Manager, Public Relations  Vice President & Chief     President & CEO
General Atomics		     Technical Officer        UUNET Technologies, Inc.
P.O. Box 85608             Performance Systems        3110 Fairview Park Dr.	
San Diego, CA 92186-9784     International, Inc.      Suite 570
Phone: 619.534.5137	   11800 Sunrise Valley Dr.   Falls Church, VA  22042
Fax:   619.534.5113	   Suite 1100	              Phone:  703.876.5050
Email: shisler@sdsc.edu    Reston, VA  22091	      Fax:    703.876.5059	
	         	   Phone: 1 800.82PSI82       Email:rick@uunet.uu.net
			         +1 703.620.6651
			   Fax:  +1 703.620.4586
			   Email: info@psi.com


General Atomics, Performance Systems International and UUNET Technologies, Inc.
Establish the First Commercial Internet Exchange (CIX)

San Francisco, CA - March 25, 1991 - General Atomics, Performance Systems
International, Inc. (PSI) and UUNET Technologies, Inc. today jointly
announced the establishment of the first Commercial Internet Exchange (CIX).  

The CIX agreement provides for all customers of AlterNet, CERFnet and PSINet
to exchange Internet traffic directly, regardless of which network the customer 
obtains service from, and at no additional cost. These three competing firms
provide nearly 100% of the commercial TCP/IP - OSI internetworking services
in the United States, and are not subject to government mandated "acceptable 
use" restrictions on their traffic.

William L. Schrader, President & CEO of PSI said, "this watershed agreement
has established a set of industry and 'social' standards which assure Internet
customers of improved stability and responsiveness to their needs.  The
entire internetworking community will very likely adopt these standards as
the world-wide Internet is commercialized during the 1990's."  

The CIX will allow firms connected to one network, such as CERFnet, to
communicate with firms connected to AlterNet or PSINet without traversing
the government restricted backbones, such as the NSFNET (National Science
Foundation Network).  Rick Adams, President & CEO of UUNET Technologies, Inc.
said, "customers can now obtain high speed access throughout the
AlterNet/PSINet/CERFnet interconnected T1 network systems without the
risk of violating government imposed restrictions, and at no additional cost."  

The CIX agreement resulted from requests by commercial customers of the
three network providers, and has been well received, especially by
those with multiple sites connected at different locations in the 
United States and overseas.  The interconnection makes use of the 
redundant T1 facilities of the three networking firms and will provide 
service even in the event of complete failure of the NSFNET backbone.

Susan Estrada, Executive Director of CERFnet said, "we have structured this
agreement so that the customers remain our focus, rather than government
rules or subsidies.  The T1 interconnection in San Francisco is a first
example of how commercial firms in this new industry will be cooperating to
support their customer base."  

Martin L. Schoffstall, PSI's Vice President and CTO said, "the CIX will help
to reduce the uncertainty some users expressed concerning government control,
such as a government owned or sanctioned monopoly."  

"The CIX agreement can be extended to other commercial Internet providers," 
Adams said.  "By structuring the CIX with good engineering, and by providing
free data transport across the network interfaces, we believe this approach
can be expanded to include any commercial service which has no restrictions
on traffic use."  

Ms. Cate Muther, Vice President of Marketing, Cisco Systems, a PSINet customer
located in Menlo Park, California, expressed her thoughts of the new CIX
by saying, "Cisco Systems is pleased to be the key provider of routing
technology for all three network providers and this interconnection.
CIX should be an excellent complement to the NSFNET for those commercial
users who wish to make extensive use of an alternative internet in the US."

Steve Crocker, Vice President of Trusted Information Systems, an AlterNet
customer located in Glenwood, Maryland said, "TIS is delighted to see the
interconnection of commercial networks.  This is a major advance for IP
networking and will open the door for many customers and many applications."

The first CIX will be located in the San Francisco Bay Area and will operate
at T1 using Cisco Systems routers and PPP (Point-to-Point Protocol). 
Network Operations Center support for the CIX will be provided 24 hours/day,
7 days/week by the three firms, and is expected to be operational within
60 days.  

CERFnet is a regional data communications network which promotes
collaboration among scientists, engineers, and educators in commercial,
government, and academic sectors.  CERFnet links over 70 of the leading
research and education centers throughout California.  CERFnet was launched
in the Spring of 1989 with a $2.8 million grant from the National Science
Foundation.  CERFnet is managed and operated from the San Diego Supercomputer
Center (SDSC), a national research facility.  CERFnet and SDSC are both
projects of General Atomics, a San Diego-based high technology research and
development company. 

PSI, headquartered in Reston, Virginia, is a value-added internetworking
services provider with a wide spectrum of services for the individual and
corporate user of electronic information, ranging from electronic mail
products to turnkey integration of local area networks into the PSINet wide
area network system and the Internet.

UUNET Technologies, Inc., located in Falls Church, VA, provides a range
of communications services including high speed TCP/IP or OSI based
internetworking, dialup electronic mail and source and documentation
archive access, and is an authorized distributor for several brands of
communications related equipment. 

				      - 30 -	

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 11:17:56 GMT
From:      tongr@bssi.nl (Ton Gorter)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   How do you manage about 150 multi-vendor workstations in a network?

Hello everybody,

We are thinking about the following problem:

What is the best way to manage#! rnews 940
Path: bv4c06!tongr
From: tongr@bssi.nl (Ton Gorter)
Newsgroups: comp.unix.admin,comp.protocols.tcp-ip
Subject: How do you manage about 150 multi-vendor workstations in a network?
Keywords: manage workstations
Message-ID: <673@motor.bssi.nl>
Date: 27 Mar 91 11:17:56 GMT
Organization: Baan Service bv, Barneveld NL
Lines: 19
Xref: bv4c06 comp.unix.admin:684 comp.protocols.tcp-ip:1340

Hello everybody,

We are thinking about the following problem:

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 14:41:04 GMT
From:      mosemann@sardion.unl.edu (Russell Mosemann)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP has bad segment size

In <1991Mar26.213034.8544@hoss.unl.edu> mosemann@sardion.unl.edu (Russell Mosemann) writes:

>   Weeks and weeks ago, people were discussing the problem MacTCP has
>with determining the MSS (maximum segment size).  I read the messages
>but never wrote anything down or saved it because we didn't have that
>problem before.
 [...]
>   I dug into the packets and found that it was requesting a window size
>of *10241*.  Could someone mail the fix for this (I think it was done by
>Steve Dorner)?
[...]

   OK.  I got the fix, but it didn't solve the problem.  Now for a
little more information.  I'm using MacTCP 1.0, MacPOP 1.5.7, Systems
6.0.5 and 6.0.7, and Ethernet'ed and LocalTalk'ed Macs (SE/30, SE, and
Classic).
   MacPOP tries to establish the tcp connection.  I see the 4 or so
packets go to the POP host, but there is no return response.  Our
sniffer reports:

Ethernet:  ( router -> pop host)  type: IP(0x0800)
Internet:    Mac IP -> pop host IP  hl: 6  ver: 4  tos: 0
 len: 48  id: 0x0009  fragoff: 0  flags: 00  ttl: 58  prot: TCP(6)
 xsum: 0x6a75 bsec resv 4:
TCP:  10593 -> POP-2(109)  seq: 5d60a560  ack: ----
 win: 11648  hl: 6  xsum: 0x3a3a  urg: 0  flags: <SYN>  mss: 576

   Only the Ethernet and IP addresses have been changed.  This is
from a Mac Classic going through a FastPath 4 running version 8.x of
KSTAR.
   I can telnet to the port and issue commands by hand with no problem.
The mss doesn't seem to be the problem that I thought it was.  The
window size seems a little strange, but maybe it's OK, too.  The thing I
have never seen in a TCP packet before is the "bsec resv 4:".  Does
anything look wrong in this packet?  Thanks.
--
Russell Mosemann                  Internet:             mosemann@unl.edu
Network Analyst                   Bitnet:               mosemann@unlvax1
Computing Resource Center         UUCP:   ..!uunet!hoss.unl.edu!mosemann
University of Nebraska - Lincoln  Voice:  (402) 472-5930   Fax: 472-5280

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 14:52:22 GMT
From:      mosemann@sardion.unl.edu (Russell Mosemann)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP has bad segment size

In <1991Mar26.213034.8544@hoss.unl.edu> mosemann@sardion.unl.edu (Russell Mosemann) writes:

>   Weeks and weeks ago, people were discussing the problem MacTCP has

   Arg!  I forgot to mention that the pop host is a Sun (we've tried a
Sparc 1 and a Sparc 2) running SunOS 4.1.1.  MacPOP was working a month
or two ago.  One thing that changed in that time was that we moved
from Sun0S 4.0.3 to 4.1 to 4.1.1.
--
Russell Mosemann                  Internet:             mosemann@unl.edu
Network Analyst                   Bitnet:               mosemann@unlvax1
Computing Resource Center         UUCP:   ..!uunet!hoss.unl.edu!mosemann
University of Nebraska - Lincoln  Voice:  (402) 472-5930   Fax: 472-5280

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 15:27:19 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  PCFTP Idrive configuration

mal@terminator.cc.umich.edu (Mark A. Law) writes:	
> In attemting to configure FTP's PC/TCP product, I came across the following 
> line in the configuration file.
 
> [pctcp idrive]
> vax = foo.net.com /users/guest/foo i: user fred 
> 
> From this it looks like I should be able to remotely mount a file structure 
> and call it my "I:" drive on my PC.  I've been unable to find this 
> documented anywhere in the 2.05 literature.  
> 	

The "idrive" configuration line is for InterDrive, our NFS client, which 
works as you surmise. Since more of our customers buy PC/TCP with InterDrive
(as PC/TCP Plus) than buy it alone, the PC/TCP manual includes InterDrive
information where its exclusion might be confusing to PC/TCP Plus users. 
Here, it seems to have worked the other way around!


Frances Kirk Selkirk		 fks@ or info@ftp.com      (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880
(Questions about FTP Software's products may be sent to info@ftp.com.)

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 16:06:57 GMT
From:      poorman@convex.com (Peter W. Poorman)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR/LPD protocols specification

In <1991Mar24.005800.24156@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes:

>Is there an RFC which deals with the LPR/LPD protocol?  I am specifically
>looking for the command structure passed between systems.  

I don't know whether or not there's an RFC, but the book "UNIX Network
Programming" by W. Richard Stevens (Prentice Hall, 1990) has a chapter
covering this protocol.  Includes source code for the client side of
the protocol.

By the way -- I found this book to have one of the best descriptions of
the UNIX inter-process communication and BSD sockets. (Also covers TLI, but
I'm not qualified to comment on that chapter.)  Highly recommended.

--Pete Poorman
  poorman@convex.com

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 16:38:01 GMT
From:      geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Public domain NFS

Quoth jclark@sdcc6.ucsd.edu (John Clark) (in <17810@sdcc6.ucsd.edu>):
#In article <1991Mar26.171349.16002@visix.com> amanda@visix.com (Amanda Walker) writes:
#+Nope, nothing at all.  It's been done, in fact.  I believe that Sun has
#+a trademark on the acronym "NFS", and they like you to pay them some
#+nominal fee to call your own stuff "NFS," but I'm not completely sure.
#
#Uh, $45K and bend the knees please.
#(Or is that for the Sun source and the 'right' to call it NFS).

To use the NFS and ONC trademarks (and that neat little octagonal
ONC/NFS logo), it's $1,000. According to the latest edition of the
"ONC/NFS Technology Guide" the contact people are

	Dennis Freeman or Felix Litman
	Sun Microsystems
	2550 Garcia Avenue
	MS PAL1-416
	Mountain View, CA 94043
	415-336-0955 or 1249

And I've never seen anyone at Connectathon bending the knees....

-- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)   --
------------------------------------------------------------------------------
--     Sun Microsystems PC Distributed Systems ...                          --
--            ... soon to be a part of SunTech (stay tuned for details)     --

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 16:44:39 GMT
From:      ronald@robobar.co.uk (Ronald S H Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP SLIP

mpd@anomaly.SBS.COM (Michael P. Deignan) writes:

> What I want to do is:
> 
> MACHINE A --> dialup SLIP --\   
>                             
> MACHINE B --> dialup SLIP ---> SCO XENIX BOX <-- dialup SLIP --> JvNCnet
>                             
> MACHINE C --> dialup SLIP --/

I strongly urge you to reconsider this.  Xenix/Unix is not designed to
be particularly efficient as a comms box OS, and thus, you will render
that poor ole' xenix box in the middle unuseable for anything.  In terms
of context switches alone, its CPU will be swamped.  Consider instead:

MACHINE A --> dialup PPP/SLIP --\   
                            
MACHINE B --> dialup PPP/SLIP ---> PC running KA9Q <-- dialup SLIP --> JvNCnet
                                          |
MACHINE C --> dialup PPP/SLIP --/         | ethernet
                                          |
				     SCO Xenix Box

(you may wish to put the SLIP out to JvNCnet on the Xenix box to get
 better policy control, etc, but I would try not to.  Running no SLIP
 at all on the Xenix box makes it much more reliable.)

which costs you an extra two ethernet cards and a PC, + (say) an AST 4
port card ($100 approx, + you'll need to buy 4 x16550AN UARTS if you're
expecting to do high speed stuff) However, you will also be able to use
your Xenix box (ie get some value out of that unix license and support
co$ts :-( ) and of course save on the probably more expensive intelligent
serial ports on the Xenix box -- running SLIP on a dumb serial port on
Xenix is a non-starter above 1200 or 2400 or so.

Also, you'll have the adcantage of being able to run PPP
instead of SLIP which is *much* more reliable and has inherent in the
protocol support for authentication and ip address allocation.  Also,
you'll suffer almost none of the nasty surprises like corrupt UDP
packets which plague SLIP.

Remember: every single character that arrives on a Xenix box for SLIP
goes in the kernel, out to user space to the slip daemon, back in again,
causing the poor old 386 to have a heart attack.

This is the reason why people use routers, and a PC (say a cheap 286
motherboard with 512K ram + 1 floppy disc) makes an effective solution.
-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 19:45:38 GMT
From:      jdc@rama.UUCP (James D. Cronin)
To:        comp.dcom.lans,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Public domain ethernet traffic monitors?


Are there any public domain/shareware ethernet monitor
programs for PC's/workstations?  We are looking for some
way to determine ethernet utilization, along with some
way to tell who's using the cable.

Thanks...Jim Cronin
jdc@sc.harris.com
-- 

James D. Cronin                   UUCP:   jdc@sc.harris.com  or
Software Engineer                         ...!uupsi!rama!jdc  
Defacto News Administrator
Harris/Scientific Calculations

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 21:31:29 GMT
From:      ash@hpindda.cup.hp.com (Art Harkin)
To:        comp.protocols.tcp-ip
Subject:   Re: GATED and BIND

/ hpindda:comp.protocols.tcp-ip / changmk@hpsgm2.sgp.hp.com (Mun Kein Chang) /  4:52 am  Mar 23, 1991 /
I'm trying to understand what GATED and BIND is and how it
works. Would really appreaciate any pointers to articles
or RFCs. Thanks.
----------


For BIND see rfc's 1034 & 1035.

For gated the following rfc's are helpful: 1058 RIP, 827 EGP, 911 EGP
under 4.2BSD, 891 DCN (HELLO), and 888 STUB exterior gateway protocol.

Also rfc 1123 helps shed some light on the intepretation of these rfc's.


-art

Art Harkin					ash@hpda.cup.hp.com
Hewlett Packard					Cupertino, CA

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 91 22:21:29 GMT
From:      pachi2@cbnewsk.att.com (sampath.i.prakash)
To:        comp.protocols.tcp-ip
Subject:   packet length distribution

I am looking for the packet length distribution of traffic coming out of 
a bridge/router to the wide area for TCP/IP, DECnet, or
ISO or any other protocol. Data for a commercial environment would be appreciated.

There are quite a few articles on packet length distribution within a Token
Ring or Ethernet. Will the same statistics hold true for the out-of-LAN
traffic ?

Within a LAN, for example, the percentage of smaller packets (64-100 bytes)
is dominating compared to longer packets (500 + bytes); but in terms of
actual Bytes the longer packets dominate.

Any reference or data throwing light on this issue is appreciated.

Thanks in advance

arch3!pachi\@att.com

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 00:08:17 GMT
From:      jr@twisted.dkw.com (J.R. Jesson)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

In article <1161@cthulhuControl.COM>, raisch@Control.COM (Robert Raisch) writes:
|> 
|> There is a PD (almost) NFS client.
|> 
|> MD-DOS/IP from Univ of Maryland.
|> 
|> Package includes:
|> 
|> 	TCP/IP Kernel
|> 	Berkeley Sockets lib
|> 	Telnet/Ftp/etc.
|> 	LPR/RSH/TFTP
|> 	NFS client
|> 
|> 	All sources and manuals
|> 
|> It's an interesting package and although it takes up scads of RAM, 
|> (QEMM'able, thank the gods), it's very stable.
|> 
|> It's available to edu clients for a small price, I think ~= $200.
|> (I'll post contact info if there is interest.)
|> 
|> The development team answers their mail, too.  <smile>
|> -- 
*Please* Dont call this Public Domain! (Dont Even call it Late for 
Dinner ;-) ).  The UMD package isnt quite available to those of us 
unfortunate enough to work in the real world. Sigh.

J.R.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 12:23:19 GMT
From:      J.Hayward@utexas.edu (Jeff Hayward)
To:        comp.protocols.tcp-ip
Subject:   Re:  University of Maryland Network Communications Package now available

Thanks.

Jeff

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 15:16:05 GMT
From:      guenther@iras6.ira.uka.de (Guenther Schreiner)
To:        comp.dcom.lans,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Public domain ethernet traffic monitors?

There is an Ethernet monitor called "The Beholder", running on PCs.
You can fetch it via anon. ftp from dutepp0.et.tudelft.nl

>Features of The Beholder are:
>
>         - continuos monitoring of multiple ethernet segments
>         - reports load, ethernet-types and packet lengths
>         - reports findings using SNMP (via UDP/IP)
>         - supports ping/echo/TFTP
>         - full UDP/IP stack
>         - compatible with SUN NetMgr, MIT SNMP, CMU SNMP
>         - requires standard PC with working packet driver

Regards,
 Guenther

--
 Guenther Schreiner			University of Karlsruhe, West Germany
  c/o Fakultaet fuer Informatik		Phone: (0721) 608-2749
  Am Fasanengarten 5			UUCP:  ...!seismo!unido!uka!guenther
  7500 Karlsruhe 1			CSNET: guenther@ira.uka.de
					EARN:  GUENTHER at DKAUNI0I
--

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 17:15:39 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Sizes

In article <17724@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes:
>In article <9103151236.AA05472@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
>+If you're looking at raw ethernet packet lengths (as opposed to IP
>+datagram lengths), you'll see lots of 60 byte packets on the net
>+because ethernet has a minimum packet length of 60 bytes. Any packets
>+that are shorter are padded out to 60. IP can tell how many bytes it
>
>Sometime ago I had a ethernet analyzer on a line with both TCP/IP
>and DECNET traffic. It seems to me that there were some DECNET
>packets shorter than the minimum. It could have been a halucination
>or does DEC violate the standard.
>-- 
>
>John Clark
>jclark@ucsd.edu

Is it possible that your ethernet analyzer was reporting the length of the
DECNET packet?  DECNET uses a length field immediately after the Ethertype
to define the size of the encapsulated DECNET packet.  The Ethernet packet
is always supposed to be padded out to minimum size (if neccessary).

Art

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 19:42:09 GMT
From:      marcus@cpva.saic.com (Mark Jenkins, (619) 458-2794)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Looking for comments on network analyzers

We have been evaluating network analyzers.  The list has been narrowed to the
Network General Sniffer, Micro Technologies LANager, and the Novell LANalyzer.
Our prime protocol requirements are TCP/IP, DECnet, and Appletalk, with Novell,
NFS,  and OSI to follow at some point in the future.  Physical media types are
limited to various Ethernets right now, although being able to snoop on V.35
WAN links (between routers) would be a bonus.

The Sniffer and the LANager are very similar, because MTI buys the Sniffer
software from Network General and supposedly reworks it slightly.  MTI seems to
be able to price the LANager better than the Sniffer.  The Novell LANalyzer is
nothing like the Sniffer or LANager, but costs substantially less (about 1/2
the price with a discount).

Does anyone have experience with any pair of these to offer a basis for
comparison?  We have demo'd the Sniffer and the LANalyzer, but its hard to tell
without extensive use just how handy some of the features are.  Very often
*some* kind of analyzer is better than no analyzer at all.

The protocol decoding and various media support capabilities (Ethernet, V.35
WAN, LocalTalk) of the Sniffer-type analyzer are great, but are they worth the
extensive extra $$$s, especially the extra $$s per protocol suite over the
Novell LANalyzer cost?  Just how does the LANager differ from the Sniffer - are
they exactly the same or substantially the same?

Please email any comments/critiques/information to me below.  I'll send
summaries (including my own information) to persons requesting them via email.

Thanks very much in advance for any help -

-- 
Mark Jenkins, SAIC         CPVA::Marcus - SPAN    [28119::Marcus]
Marcus@CPVA.SAIC.COM or Marcus%CPVA.SPAN@sds.sdsc.edu (elsewhere)

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 19:48:49 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Sizes

.In article <17724@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes:
.>In article <9103151236.AA05472@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
.>+If you're looking at raw ethernet packet lengths (as opposed to IP
.>+datagram lengths), you'll see lots of 60 byte packets on the net
.>+because ethernet has a minimum packet length of 60 bytes. Any packets
.>+that are shorter are padded out to 60. IP can tell how many bytes it
.>
.>Sometime ago I had a ethernet analyzer on a line with both TCP/IP
.>and DECNET traffic. It seems to me that there were some DECNET
.>packets shorter than the minimum. It could have been a halucination
.>or does DEC violate the standard.
.>-- 
.>
.>John Clark
.>jclark@ucsd.edu
.
.Is it possible that your ethernet analyzer was reporting the length of the
.DECNET packet?  DECNET uses a length field immediately after the Ethertype
.to define the size of the encapsulated DECNET packet.  The Ethernet packet
.is always supposed to be padded out to minimum size (if neccessary).
.
.Art

To clarify, things, the minimum ethernet frame is 64 octets -- which
translates into 6 bytes dest., 6 bytes src, 2 bytes (type/length), 4 btyes
frame check sequence & 56 bytes data+pad.  Preamble and SFD excluded.

And, yes, DEC does violate this minimum length (in loopback packets).
-------------------------------------------------------------------------------
 Willis F. Marti		Internet: willis@cs.tamu.edu
 Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
 	---Not an official document of Texas A&M---

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Mar 1991 22:06:15 GMT
From:      todds@newbridge.com (Todd Sandor)
To:        comp.protocols.tcp-ip
Subject:   UDP Reliability between processes on same host

Please don't flame me, I know UDP is unreliable, but I have
a question concerning using UDP between processes on the
same host.  We are using Sun Sparcstations runing 4.1.1
and using UDP sockets to talk between processes on the
same machine.  I realize UDP is defined as being unreliable,
and that we may possibly experience:
- socket overflows or
- bad data length fields or
- bad checksums

but could we experience out of order packets or duplicate
packets.  For example, one the same host, process A 
and B are up and are bound to each other, process 
A sends 5 datagrams to process B,
will process B get these 5 messages and only these 5 messages
in the order that process A sent them?  I don't have access
to source, so I can`t check this out, hopefully someone can
tell me the answer.  This is the simple case, (this works as I've
tested it), but under extremely HIGH loads, would we run
into problems?


Also, would it make a difference if the host address we used
in bind() call was the "localhost" (address 127.0.0.1 from
/etc/hosts file, its the loopback device).
Theoretically using this as the host would be faster,
I think?, since it wouldn't have go through the routing
code in the kernel.  Can anyone give me any input to this,
is it a good thing to do?  How much faster would it be?

And finally, can anyone give me input into the robustness
of TLI under SunOS 4.1.1.  In the manuals it says that sockets
are sort of being phased out, was wondering if anyone has
any real experience using TLI?

/todds
-- 
Todd Sandor        Voice: (613) 591-3600 ext 1011 P.O. Box 13600
Newbridge Networks FAX: (613) 591-3680      600 March Road
Mail: todds@newbridge.com                   Ottawa, Ontario,Canada K1G 3Z4

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 91 22:24:44 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: Need routed params with SLIP (Sun to BSD VAX)

In article <119@gordius.gordian.com> johnk@gordian.com (John Kalucki) writes:
>Perhaps you should look into gated, which is supposed to handle
>point to point links better than routed.

Does anyone know where a version of gated that has been ported to SysV386
can be found? I checked the stuff on uunet, and it seems to be BSD-only
(at least, I'm missing a bunch of header files and libraries that it looks
for).

Something that would work under ISC 1.0.6 (no, I can't upgrade) would
be perfect (and probably usable under the 2.x systems, too).


-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
I support drug testing. I believe every public official should be given a
shot of sodium pentathol and ask "Which laws have you broken this week?".

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 00:57:18 GMT
From:      BHOLMES@CMS.CC.WAYNE.EDU
To:        comp.protocols.tcp-ip
Subject:   ARP question

Reply-To: bholmes@cms.cc.wayne.edu

I know that ARP isn't really part of TCP/IP but I don't know where else
to ask this question.  I have read RFC826 and am still unclear so here
comes the question:  Is it valid to send an ARP REPLY out using the
broadcast hardware address or must one use the senders hardware address?
Reply to me and I will summarize.  Thanks.

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 03:13:05 GMT
From:      rick@ameristar (Rick Spanbauer)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain NFS

In article <1991Mar26.171349.16002@visix.com> amanda@visix.com (Amanda Walker) writes:
>In article <40519@cup.portal.com> FelineGrace@cup.portal.com (Dana B
>Bourgeois) writes:
>
>   Is there something that keeps me from writing my own
>   NFS?  Distributing it or selling it?
>
>Nope, nothing at all.  It's been done, in fact.  I believe that Sun has
>a trademark on the acronym "NFS", and they like you to pay them some
>nominal fee to call your own stuff "NFS," but I'm not completely sure.
>In any case, nothing will stop you from building the code and selling it...

	Ameristar Technology built both NFS client & a prototype server 
	implementation on the Commodore Amiga; both were developed entirely
	from the spec + Sun RPC sources.  Like all specifications, there are 
	minor nits that one discovers only after doing an implementation 
	though.  To Suns credit, they run a "Connectathon" every year where 
	vendors get together and test for interoperability.
	
>Amanda Walker
>Visix Software Inc.

					Rick Spanbauer
					Ameristar

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 03:17:35 GMT
From:      BHOLMES@CMS.CC.WAYNE.EDU
To:        comp.protocols.tcp-ip
Subject:   ARP question again

My original message came out a little unclear so here is another attempt:
When responding to an ARP request, do you have to address the reply
to the hardware address of the machine that requested it or can you
simply send the reply to the broadcast hardware address?

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 06:49:54 GMT
From:      chas@stax.uchicago.edu (Charles Blair)
To:        comp.protocols.tcp-ip
Subject:   LPD for PC?


I'd like to set up a PC as a print server accepting requests from
other PCs using FTP's implementation of client lpr for the PC. It
occurs to me that if an lpd implementation that runs under MS-DOS were
set up as the PC's sole task, perhaps that might work.  Does such a
thing exist? 

(I realize I can set up the PC as an ftp server and have users ftp
files to it and put their files to prn, but I'd like to be able to do
what I've described as well, realizing also that in the end I might
need to buy a PC Unix for the server.)

--
Internet: chas@uchicago.edu

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 11:26:43 GMT
From:      lanmaint@nssdcb.gsfc.nasa.gov (Dave Yoest)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on network analyzers

In article <5336.27f1d691@cpva.saic.com>, marcus@cpva.saic.com (Mark Jenkins, (619) 458-2794) writes...
>We have been evaluating network analyzers. 
 
> (* TEXT DELETED *)
> 
>Does anyone have experience with any pair of these to offer a basis for
>comparison?   
> (* TEXT DELETED *)
 
>-- 
>Mark Jenkins, SAIC         CPVA::Marcus - SPAN    [28119::Marcus]
>Marcus@CPVA.SAIC.COM or Marcus%CPVA.SPAN@sds.sdsc.edu (elsewhere)


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


Not to cloud the issue since you have already narrowed the field, but 
did you look at the Hewlett Packard 4972 LAN protocol analyzer.
I like it better than both the SNIFFER and LANALYZER (my opinion).
If you add the plotter option then you can also use the 4972 to
create some really impressive multicolor graphs/charts for 
presentations on paper or overhead projector transparencies.
It also doesn't "drop" packets on very busy ethernets.

Dave Yoest
LAN section Supervisor 
Allied Aerospace/Bendix Field Engineering
NASACOM/Telecommunications Branch 
Code 543.8
NASA/Goddard Space Flight Center
Greenbelt, Md 20771 USA

DYOEST@ZAPHOD.GSFC.NASA.GOV
DYOEST@128.183.43.16 

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 12:07:19 GMT
From:      uhhyung@mani.kaist.ac.kr (Uhhyung Choi)
To:        comp.protocols.tcp-ip
Subject:   SLIP on SunOS 4.1.1

Hi, netlanders?
Does anybody have experiences of running SLIP on SunOS4.1.1?
I've got one for SunOS4.1 but it doesn't work.
A little piece of   information would be appreciated.
Thanks.

-Uhh
-- 

Uhhyung Choi
Sophomore, Department of Computer Science 
Korea Advanced Institute of Science and Technology
Taejon, 305-701, Republic of Korea
Email: uhhyung@mani.kaist.ac.kr
Phone: +82-42-820-4168

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 13:40:45 GMT
From:      BHOLMES@CMS.CC.WAYNE.EDU
To:        comp.protocols.tcp-ip
Subject:   ARP question summary

From the few responses I received so far it seems that the consensus
is that one can reply using the broadcast address but this generally
is not good practice due to excessive work this puts on the local
workstations.  I'm having a proble right now with a router and a
distribution enclosure.  The enclosure ARPs for the router's(gateway's)
ethernet address and the router replies using the broadcast address instead of
directly to the enclosures ethernet address.  The enclosure isn't
dealing with this very well although workstations seem to accept
this practice just fine.  By "can do this" does this mean the general
consensus is that this is legal?  Where can I contact the protocol
police regarding this?  I'm not to sure which vendor to talk to about this.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 14:29:47 GMT
From:      snorthc@relay.nswc.navy.mil (Stephen Northcutt)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on network analyzers

Mark Jenkins, SAIC  writes:
>We have been evaluating network analyzers.  The list has been narrowed to the
>Network General Sniffer, Micro Technologies LANager, and the Novell LANalyzer.
>Our prime protocol requirements are TCP/IP, DECnet, and Appletalk, with
 Novell,
>NFS,  and OSI to follow at some point in the future. 

We have two of the three you listed, HPs and several others you didn't.
They all work.  For what its worth I kinda like FTP SW's LANWatch product,
because it is so convienient, many times, I happen to be on the
same subnet as the problem, so all I have to do is turn on my PC.
The price is also a factor in LANWatches favor.

In conjuction with a piece of simtel-ware called robo-key, we have
been able to use lan watch to collect data on far flung subnets,
then use ftp sw's rcp/rsh to beam the data up to a unix system for
awk processing; works pretty durn well.
===================================================================
Stephen Northcutt (snorthc@relay.nswc.navy.mil)     News Admin
Work: (703) 663-7745                                High Speed Nets 
Home: (703) 371-4184                                Local GOSIP guru 
Paper Mail: Code E41, NSWC, Dahlgren VA 22448       Parallel Research

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 15:11:30 GMT
From:      lap@dvncnms.Devoncnms.Unisys.COM (Lisa A. Phifer)
To:        comp.protocols.tcp-ip
Subject:   Experimental Registration Arc


Can anyone tell me the current status of using
experimental arcs to register objects defined by 
the Internet community? I have heard this approch 
is no longer favored -- can anyone confirm this,
and explain why or why not?

Thank you,
Lisa Phifer
Unisys Corporation
POB 1874
Southeastern, PA 19398
lap@dev.unisys.com

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 16:04:47 GMT
From:      jkg@UX.ACS.UMN.EDU
To:        comp.protocols.tcp-ip
Subject:   Please remove me from your list

tcpip-l@ux.acs.umn.edu

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 17:08:31 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP has bad segment size


    Ethernet:  ( router -> pop host)  type: IP(0x0800)
    Internet:    Mac IP -> pop host IP  hl: 6  ver: 4  tos: 0
     len: 48  id: 0x0009  fragoff: 0  flags: 00  ttl: 58  prot: TCP(6)
     xsum: 0x6a75 bsec resv 4:
    TCP:  10593 -> POP-2(109)  seq: 5d60a560  ack: ----
     win: 11648  hl: 6  xsum: 0x3a3a  urg: 0  flags: <SYN>  mss: 576

    ...  The thing I have never seen in a TCP packet before is the
    "bsec resv 4:".

LANWatch is telling you that your IP header contains the "Basic Security"
IP option, with a "reserved" classification value.  This might well be
the problem - many hosts can't grok IP packets with options.

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

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 17:27:32 GMT
From:      JSIMPSON@MIAMIU.BITNET (Joe Simpson)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP has bad segment size

This is a known problem .  MacTCP version 1.0.1 fixed it.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 91 18:02:14 GMT
From:      adams@ADAMS.PC.CS.CMU.EDU (Duane Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on network analyzers

Brian,
Thanks for the input.
Duane

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 91 05:12:51 GMT
From:      carl@umd5.umd.edu (Carl Symborski)
To:        comp.protocols.tcp-ip
Subject:   IP over Frame Relay Network

To all,

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

Thanks,

Carl Symborski     -      carl@umd5.umd.edu

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 91 07:14:55 GMT
From:      GONTER@awiwuw11.wu-wien.ac.at (Gerhard Gonter)
To:        comp.protocols.tcp-ip
Subject:   setting ttl under u*ix?

Hello netlanders,
  is there an easy way to set the ip ttl on a unix machine?

I'm using a tektronix 4132 which produces ip packets with a ttl of 15.
This allows me to reach the machine in the next block, but not much further.

thank you for any help, please send your answers to me directly.

regards, Gerhard Gonter                        <GONTER@AWIWUW11.BITNET>
Tel: +43/222/31336/4578                 <gonter@awiwuw11.wu-wien.ac.at>

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 91 08:18:10 GMT
From:      ljm@FTP.COM (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP question summary

>
>From the few responses I received so far it seems that the consensus
>is that one can reply using the broadcast address but this generally
>is not good practice due to excessive work this puts on the local
>workstations....  By "can do this" does this mean the general
>consensus is that this is legal?  Where can I contact the protocol
>police regarding this?  I'm not to sure which vendor to talk to about this.
>

Ancient versions of WIN/TCP for DOS sent ARP replies as broadcasts.
In some network configurations with some hosts bad things happened.
Unfortunately, I don't remember much of the details; I just fixed it
as soon as I noticed the behavior.

As far as 'legal' is concerned, use the only definition that matters
to the tcp-ip world.  If you are doing this for your own environment,
and nothing breaks, then go ahead.  If there is any chance of the software
being deseminated into the world at large, don't use broadcast ARP
replies as they may break other software.

enjoy,
leo j mclaughlin iii
ljm@ftp.com

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 91 15:51:28 GMT
From:      THIER@ORCAD2.dnet.ge.com
To:        comp.protocols.tcp-ip
Subject:   Socket Status Determination

Some time back, I posted a query regarding determination of socket status,
once alerted to socket state changes via SIGIO and/or SELECT. Based on
the replies, I've implemented a SIGIO handler that works, somewhat. My 
handler implements the following logic: (sockets are set non-blocking). 

      SIGIO Occurs.

      Execute SELECT for all known data sockets. (I keep a list).

      For all data sockets indicating activity:

         Execute a RECV.

         If -1 returned, raise exception (this is Ada code, by the way).

         If 0 bytes received, do nothing. (I assume some sort of
              socket opening/closing activity is occurring; I'm not
              aware of any other conclusions I can draw with regard
              to data sockets).

         If > 0 bytes received, deliver data to message-management
         task.

             The message management task keeps track of message 
             boundaries. An embedded message header provides it with 
             a start-of-message marker, message length and whether
             the sender wants to keep the connection open for further 
             traffic or not. If the connection is not to be retained and 
             the message has been received in full, the data socket is 
             closed and taken off the list. I don't currently execute
             SHUTDOWNs on either end of the transfer.

         Endif;

      End Data Socket Processing.

      Execute SELECT for all connection (LISTENing) sockets. (Another list).

      For all connection sockets indicating activity:

         Execute ACCEPT.

         If -1 returned and errno = EWOULDBLOCK, do nothing (again, here I
            assume that something other than a connection request is
            taking place).

         Elseif -1 returned and errno = something else, raise exception.

         Else, assume valid connection requested and accepted. Add new
            data socket descriptor to list.

         Endif;

      End Connection Socket Processing.

   End SIGIO handler.
         

   Now to my problem. I'm running a test case where I create one connection
socket, backlog set to 5. A sender program loops, creating a socket, 
connecting to the receiver, sending one message (570 bytes), and closing. 
This mostly works, but over time, some data sockets, with data sitting in 
their input queues, are going unrecognized by my software. They just sit
there in CLOSE_WAIT (transmitting socket in FIN_WAIT_2), with the correct
octet count in their queues. I continue to get SIGIOs, processing other
connections and transfers. The one obvious possibility is that my data
socket list is being mismanaged, and thus I'm simply not setting up the mask
correctly prior to the SELECT call. I'm checking into this. My question is
this: Have I missed something in my basic logic? Are there other
specific conditions I've failed to test for? Most importantly, are there
any condtions under which a data socket, with data sitting in its input
queue, will NOT indicate activity on a SELECT call (assuming its mask bit
is properly set)? Thanks in advance.

p.s. I'd also appreciate any enlightenment on shutdown strategies. Right
now I just do closes. 

John E. Thier
GE Defense Systems Division
Pittsfield MA.
thier@orcad2.dnet.ge.com

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 91 17:46:57 GMT
From:      sclayton@wpi.WPI.EDU (Shawn A Clayton)
To:        comp.protocols.tcp-ip
Subject:   Problems with TCP, read(), and write()


I am having problems with TCP, write(), and read(). I want to send and
receive 32 byte structures.  The sockets used are of the type
SOCK_STREAM, and I write() 32 byte chunks into one end (after connect()ing)
and attempt to read() 32 byte chunks from the other end (after listen()ing
and accept()ing).  I write and read many of these 32 byte structures in
succession.  My problem is that if I do no put a sizeable delay in the
send or receive loop, I end up receiving only part of a 32 byte chunk
after a number of chunks have been received.  There is no problem if I put
in a large (the larger the better) delay before each write() or read().
I do not use the )_NDELAY or O_NONBLOCK options.  Sometimes it will work
with a given delay, and other times it does not.  I seems to fail less
the longer the delay is, and more the less the delay.  It also fails more
if the total number of chunks I attempt to send is increased.  Below about
fourty of these chunks there is no problem.  Can anyone help me?  What am
I doing wrong?  I would appreciate any comments or suggestions on what
may be screwing this up.  Please email me - 

	Thanks - Shawn
	sclayton@ee.wpi.edu
-----------------------------------------------------------------------
No, I don't have a signature line!

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 91 05:35:55 GMT
From:      mpd@anomaly.SBS.COM (Michael P. Deignan)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP SLIP

In comp.protocols.tcp-ip you write:

>I strongly urge you to reconsider this.  Xenix/Unix is not designed to
>be particularly efficient as a comms box OS, and thus, you will render
>that poor ole' xenix box in the middle unuseable for anything.  In terms
>of context switches alone, its CPU will be swamped.  Consider instead:

{suggestion list deleted...}

Sounds like good suggestions. Good thing I'm not planning on "expansion"
until later on down the line. Right now, I'm only working on implementing

	SCO XENIX --> dialup SLIP --> JvNCnet

Of course, It would be preferable to just run an Ethernet connection to
JvNCnet, unfortunately my measly paycheck won't allow the costs associated
with that type of connection.

MD
-- 
--  Michael P. Deignan                      / Since I *OWN* SBS.COM,
--  Domain: mpd@anomaly.sbs.com            /  These Opinions Generally
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /   Represent The Opinions Of
-- Telebit: +1 401 455 0347              /    My Company...
-- 
--  Michael P. Deignan                      / Since I *OWN* SBS.COM,
--  Domain: mpd@anomaly.sbs.com            /  These Opinions Generally
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /   Represent The Opinions Of
-- Telebit: +1 401 455 0347              /    My Company...

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 91 06:53:19 GMT
From:      uhhyung@mani.kaist.ac.kr (Uhhyung Choi)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP on SunOS 4.1.1 ( Summurized )

The followings are messages sent to me 
in reply to my post in comp.protocols.tcp-ip. ( Reverse time order.)
Summurizing all the messages,

Before Posting:
I'm trying to install slip on Sun4/370 running SunOS 4.1.1
First I tried with existing SLIP packages for SunOS 4.0.x only to fail.
I ftped the beta version of slip for SunOS 4.1 from uunet.uu.net.
It failed again, so I posted to the net.
I've got answers from many kind people,
thank you all, David, Mark, Karl, and another David.

After Posting:
I followed Karl's advice, but I couldn't find SunOS PatchID 100149-02,
So I tried with 100149-01 which I ftped from ftp.cs.toronto.edu.
After patching with 100149-01, I tried to install with slip-4.1-beta,
only to fail again.

NOW:
After I received mark's reply that there is a circulating problem,
I'm so depressed.
Could anybody cheer me up?

------------------------------------------------------------
From: celit!whoops.fps.com!dave@UCSD.EDU
Date: Fri, 29 Mar 91 18:50:08 PST
To: uhhyung@mani.kaist.ac.kr
Subject: Re: SLIP on SunOS 4.1.1

I'm currently running SLIP on Sparcstation SLC's with Telebit T2500
modems.  I'm using the slip 4.0 package and the tip with slip.  Tip
with SLIP needed some work to get going.  If you'd like I can send you
diffs.  Garbage packets tend to make the system panic.

Cheers,
-- 
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry

------------------------------------------------------------
From: fedor@uu.psi.com (Mark S. Fedor)
To: mani.kaist.ac.kr!uhhyung@ucbvax.Berkeley.EDU
Subject: Re:  SLIP on SunOS 4.1.1


	Yes,

	Where did you get your SLIP from.  There is a bug
	circulating about with the sunOS 4.1 slip software
	package.

	Mark Fedor
	PSI


------------------------------------------------------------
From: karl.kleinpaste@osc.edu
Date: Fri, 29 Mar 91 09:37:19 EST
To: uhhyung@mani.kaist.ac.kr (Uhhyung Choi)
Subject: SLIP on SunOS 4.1.1

Pick up Rayan Zachariassen's SLIP driver originally developed for
SunOS 4.0.x.  It also works fine under SunOS 4.1{,.1}, but you will
need a bugfix from Sun, PatchID 100149-02, to prevent spurious kernel
panics due to a mangled mbuf chain.

--karl

------------------------------------------------------------
From: David J. Bianco <bianco@xanth.cs.odu.edu>
Date: Fri, 29 Mar 91 08:42:02 -0500
To: Uhhyung Choi <uhhyung@mani.kaist.ac.kr>
Subject: Re: SLIP on SunOS 4.1.1

Yes, I got an answer. The problem was a typo in the source. On the line
where it says something like "ioctl(I_PUSH, "slipe");" it should be "slipen"
instead.  One problem though, is that cslip still has a bug. It causes my
SPARCstations to crash after about 10-15 minutes of slip and NOT REBOOT!  I
rebuilt the kernal without compression and it seems to work rather well...

        David

--

Uhhyung Choi
Sophomore, Department of Computer Science 
Korea Advanced Institute of Science and Technology
Taejon, 305-701, Republic of Korea
Email: uhhyung@mani.kaist.ac.kr
Phone: +82-42-820-4168

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 91 10:19:36 GMT
From:      frode@nic.forut.no (Frode Flaegstad)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for 88K/AT&T SYSVr3.2

Have searched for a tn3270 for Motorola 88K with AT&T SYSVr3.2, unsuccessfully.
Anyone who have ported tn3270 to this platform/OS?
-- 
Frode Flaegstad			| Internet  : frode@forit.forut.no
Foundation of Applied Research	| MHS/X.400 : frode.flagstad@itek.forut.no
University of Tromsoe		| MHS/X.400 : C=no;A=;P=uninett;O=forut;
P.O.2806 Elverhoey, N/9001 Tromsoe, Norway  | OU=itek;s=flagstad;g=frode

END OF DOCUMENT