The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Feb 92 02:36:42 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Problem with ARP, Sun, FDDI, Ethernet

In article <gcp4k1s@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>By definition, the MTU is the maximum transmission size allowed by the
>media.  Yes, there is "MTU-discovery", but that is so you can pick a number
>bigger than 576 when transmitting to a remote IP network.  It has nothing
>to do with bridging.

Well, not exactly "nothing".  If someone has chosen to connect an
FDDI net to an Ethernet using a bridge (I refuse to comment on the
wisdom of such a choice) then the bridge is going to have to fragment
IP datagrams that are sent using the FDDI MTU (since the source
host won't know that there is an Ethernet in the way).

If the bridge does this fragmentation, it had also better honor
the IP Don't Fragment flag.  This is what PMTU Discovery [RFC1191]
requires of any device that does fragmentation.  From the point of
PMTU discovery, anything on the other side of a fragmenting bridge
is "remote".

-Jeff

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Feb 1992 08:18:13 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

ggm@brolga.cc.uq.oz.au (George Michaelson) writes:

>I agree they "own" it and can do as they like, but in this instance, the 
>absense of suitable delegations  means people outside cannot "browse"
>the DNS to find connected hosts.

I'm not sure what you're getting at here George - I think you're missing
something, it makes no difference whatever whether ac.uk is delegated,
it just means that you have to look in the uk zone rather than the ac.uk zone
to find things - which becomes very obvious once you discover that ac.uk
has no nameservers.

I do this all the time (in fact, I "steal" a copy of the uk zone so
I have answers to *.uk questions much quicker than waiting for the UK
servers to respond - which will become more tedious to do once the ac.uk
actually gets delegated, and other sub-domains of .uk I guess).

kre

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Feb 1992 17:31:14 GMT
From:      mcdonald@aries.scs.uiuc.edu (Doug McDonald)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   Re: How do I connect a thin-net loop to a thick-net backbone ?


In article <1992Jan30.222143.13143@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes:
>In a pinch, a thin co-ax segment may be spliced into a thick wire
>back-bone but it is not a good idea.  It is possible to find N ->
>BNC adaptors.  The problem is that the network is no better than
>the worst segment, so the most cynical restrictions on the thin
>co-ax have to be applied to the entire network.
>
That last part is just not true. The only big difference between thin and thick
cable is signal loss. If you mix them, you indeed get some sort of
average performance. You absolutely don't have to apply "the most cynical
restrictions on the thin co-ax have to be applied to the entire network".

Doug McDonald

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Feb 1992 20:27:51 GMT
From:      gmbuchan@vicstoy.UUCP (Greg Buchanan)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for MVS

Does anyone know of or could recommend an alternative to the IBM TCP/IP for
MVS program product. Am looking for alternatives which could provide additional
functionality (including net mgmt, NFS client, etc.)



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Sat, 01 Feb 92 22:12:36 GMT
From:      wtm@uhura.neoucom.EDU (Bill Mayhew)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   Re: How do I connect a thin-net loop to a thick-net backbone ?

Unless you know your facts about transmission lines, it is good
practice to presume the worst case.


Bill


(Doug McDonald) writes:
>
>In article <1992Jan30.222143.13143@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes:
>>In a pinch, a thin co-ax segment may be spliced into a thick wire
>>back-bone but it is not a good idea.  It is possible to find N ->
>>BNC adaptors.  The problem is that the network is no better than
>>the worst segment, so the most cynical restrictions on the thin
>>co-ax have to be applied to the entire network.
>>
>That last part is just not true. The only big difference between thin and thick
>cable is signal loss. If you mix them, you indeed get some sort of
>average performance. You absolutely don't have to apply "the most cynical
>restrictions on the thin co-ax have to be applied to the entire network".
>
>Doug McDonald













-- 
Bill Mayhew      NEOUCOM Computer Services Department
Rootstown, OH  44272-9995  USA    phone: 216-325-2511
wtm@uhura.neoucom.edu   ....!uunet!aablue!neoucom!wtm
via internet: (140.220.001.001)

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 92 18:21:28 GMT
From:      perand@admin.kth.se (Per Andersson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: IBMs 3172 Ethernet to Channel box

In article <1992Jan29.043229.6770@vlsi.louisville.edu> rwmira01@vlsi.louisville.edu (Robert W. Miracle) writes:
>
>BTW:  The ethernet address (MAC) of our 3172 indicates that there is a 3COM
>card in it.... Hmmmmm!

It is a 486 PS/2 with a 3com, EISA I think, ethernet card and a IBM channel
adapter. Haven't gotten around too look at performance yet, sorry.

/Per
-- 
Per Andersson (perand@admin.kth.se, perand@stacken.kth.se)
Now working at NobelTech AB, still reading news at the
Royal Institute of Technology.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Feb 1992 18:52:15 GMT
From:      radha_s@boulonnais.cs.odu.edu (Ramesh Radhakrishnan)
To:        comp.protocols.tcp-ip
Subject:   interesting question!! multiple files, mounting

HI, I need help.

In my research project I am logging some information about process which
connect through a tcp socket. The info that I am logging are u.u_uid
u.u_procp->p_pid, u.u_comm etc.

Now I also need to log information about the location (complete pathname)
of the files used in the process.

For example if I type a command <emacs somefile>. Emacs might be in
either /usr/new/emacs or /usr/bin/emacs and somefile might be in
/usr/home/ramesh/somefile or else where.

What I need to do is log these info for the process and all the open files
for that process.

I hope the answer to this question will enlighten me about how exec overlays
the text part of a parent process with the code for the child and how it 
locates this file. Also it should clarify my doupts about mounted files etc.

Please email answers to radha_s@cs.odu.edu

sincerely

-- 
--Ramesh--

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ramesh Radhakrishnan                       $ Phone: Res:(804)451-8012

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Feb 1992 00:24:49 GMT
From:      explorer@iastate.edu (Michael Graff)
To:        comp.protocols.tcp-ip
Subject:   PPP and XON/XOFF flow control


Greetings!

I'm looking for a public PPP implementation of:

	PPP for a DECstation 2100, 3100, or 5000.
	PPP for a PC.

Both need to respect XON/XOFF flow control because the physical link is a
rather brain-dead system.  :)

Any hints on how to modify KA9Q on the PC to use XON/XOFF would be nice,
too...


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 00:48:43 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun


  paul@atlas.abccomp.oz.au (Paul Brooks) wrote:

>                                                            it sees that it
> is for a non-existent port, and sends both an ICMP Port Unreachable, and
> a TCP RESET segment. When the Sun sees the ICMP Port Unreachable, it resets
> all the other connections between these two hosts, dropping the new
> connection as well as the old!
 
>	Am I doing something wrong, sending an ICMP Port Unreachable?
 
> Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl

Welcome to the world of BSD networking... when BSD code sees an ICMP
host unreachable, it is unable to deliver this just to the old socket.
It simply declares ALL users of/connections to the host returning the
ICMP message as DEAD (after all, the host is dead, isn't it :-()

Even if the original connection was UDP, but the convenience of connect
was used instead of sendto, the same problem occurs.

If you suppress the ICMP message and just Reset,  you should be OK.

Ted Rypma
HP Panacom Division

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Feb 1992 02:22:08 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET (it works, and apologies to all)

Huge red faces, multiple apologies network wide. It works under uk.
I can now find exactly what I'm needing.

Blissfully happy... I shall leave this topic alone now. Thanks to KRE
for putting me straight.

	-George
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 10:49:10 PDT
From:      dsroberts@beckman.com
To:        comp.protocols.tcp-ip
Subject:   HP TCP/IP setup questions

Our HP group has received HP's TCP/IP software so they can connect to the rest
of our TCP/IP network.  I'm familiar with the tcp/ip setup for VMS, MVS, Aegis
and Unix, but HP is a real black hole.  Our HP group has gotten no
documentation for this and looking at their setup parameters there appears to
be no place to define the FQDN, it doesn't allow a proper IP number
(134.217.247.31 has to be entered as 134.217 247.31) and there is no place to
tell it what the DNS host is.  Does anyone know of documentation available on
the net for this?  Is there anyone familiar with HP TCP/IP that can help me, or
point me in the right direction?  Is there another newsgroup more appropriate
for questions about setting up HP TCP/IP?

Thanks.
-- 
---------------------------------------------------------------------------
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Commercial Unix - An oxymoron
---------------------------------------------------------------------------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 11:56:43 GMT
From:      icj@otto.bf.rmit.oz.au (Ian Johnson CMIM)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP routing problem


Hi all,
	We have are having a slight problem at my place of work.  We
cannot decide how to setup the following routing configuration.  So I
have decided to seek the wisdom of the net for guidance :-)  

Network diagram:

       140.168.1.0            140.168.2.0
      -------------          -------------
           |                       |
           a       SLIP/PPP        c
         [ A ]-X---------------Y-[ B ]
           b                       d
           |                       |
      -------------          -------------
       140.168.3.0            140.168.4.0


A = Well Fleet router  IP nums: a=140.168.1.1 b=140.168.3.1
B = Well Fleet router  IP nums: c=140.168.2.1 d=140.168.4.1

Network information:

Class B IP number 140.168.0.0
Subnetted with 8 bit subnet mask.
Hosts on all nets support RIP (using routed) and  be used for all the different SLIP links? Or will this just confuse
routing protocols?  If we do use a new subnet is it possible to use IP
numbers above 223.0.0.0 range?  I believe that these are unallocated numbers.

2) Setup interface X to have two IP numbers the same as the two ethernet
interfacs ie 140.168.1.1 & 140.168.3.1  and then setup same hardwired routes.
I've done this sort of thing using an Xylogics Annex II connected to host
using SLIP, but that was a single connection. (ie 1 ethernet interface &
1 serial interface)  Can this be done using routers (Well Fleets in particular)?

Are there any other configurations?

I would appreciate ANY thoughts on the above problem, even if they suggest
different routers etc.  Thoughts and hints on setting up the host gateway
files would also be warmly accepted.  We are using mainly Sun gear (SunOS4.1.1)and one Pyramid (OSx5.1d).

Many thanks.

Ian Johnston                            email: icj@otto.bf.rmit.oz.au
UNIX System Admin                       phone: +61-3-6076448
                                        fax  : +61-3-6076198

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 12:30:54 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

In article <ggm.696897879@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:

   In any case, with nsfnet-relay.ac.uk being a bottleneck, the ACTUAL
   delay for a mail exchange is variable from 15 minutes to 3 days.

This is true, but not relevant. There are other JANET mail relays.
Some JANET sites even talk SMTP....

   >You have to appreciate that the JIPS is in its infancy.  

   I beg to submit the gestation time was somewhat elephantine.  

Even though you're not aware of the facts or the (many) conditions
that applied to the establishment of JIPS, you're entitled to your
opinion. I think most people would agree that getting an national IP
backbone established in less than 6 months is pretty good going,
especially when you consider the notorious inefficiency of UK
telecomms and the few outlets for IP routers in the UK.

   >The pilot project only became a service last November, and we're 
   >still building up the service.  

   I admit to being fascinated by this UK obsession with "pilot" projects.
   Either you're going to do IP or not. What does the pilot tell you that
   you don't find out operationally anyway? If the pilot was going to show
   a terminal fault in the model, I submit somebody else out there would
   have found out by now. 

You are misinterpreting what the pilot project was all about. It was
not to determine the viability of IP: the Internet is an existence
proof of that. It was concerned with nuts and bolts issues like which
combinations of X.25 switches and routers worked best; how to make IP
and Coloured Book Protocols co-exist; and how to introduce IP and
maintain some semblance of "backwards compatibilty" with JANET without
isolating or confusing the user community. At the same time, the sites
participating in the pilot could build up experience with Internet
routing protocols, DNS and so on.

The facts of the matter are that the JANET community demanded (and
demands) an IP service. The people controlling the money agreed. They
did however place some constraints on how IP was to be provided. These
concerned "fragmentation of the user community" - they wanted to
ensure that JANET did not end up with an IP camp and a CB camp who did
not (or could not) talk to each other. This is not unreasonable, but it
does pose some interesting problems: for instance mapping between NRS
and DNS names; or how an IP-only host sends mail to a CB-only host (or
vice versa).

You seem to be suggesting that JIPS is a half-hearted effort that
doesn't know what it's doing or how it interfacts with the rest of the
IP world. Nothing could be further from the truth.

		Jim

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 13:46:00 GMT
From:      duncan@transition.mhs-relay.ac.uk (Duncan Rogerson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

In article <ggm.696897879@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
>I admit to being fascinated by this UK obsession with "pilot" projects.
>Either you're going to do IP or not. What does the pilot tell you that

... and the results of the pilot tell us whether we should or not,
and the experiences we have over the pilot help us to do things right
when we launch a service.  This isn't a new network we're creating
from scratch, it's an added service to JANET, one which needs to be
thought out so it can be successfully integrated.

>DNS will mean I can find out who is "live" without hassling the small
>crew doing the work. 

Yeah, it will.  But I still don't understand why you so desperately
_need_ to know this.  If you need access to somewhere, you'll either have
been given an account and connection details, or you'll have seen
a service advertised on news or something.  If you like to poke around
and find out who's connected, fine, but this sort of requirement is
unlikely to come high on anybody's list.  People that are connected
can be found, once they've had their zone delegated.  That's more
important.

Obviously the JIPS isn't being implemented the way you think it should.
But it's the way it's been decided to do it, and I think it's working
pretty well.

Dunc
... again, this is all purely me, not on behalf of ULCC or anyone else.

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Feb 1992 15:20:21 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over Packet Radio


Does anyone out there have experience on this topic?  We have developed a  
distributed appplication that runs on UNIX hosts on an Ethernet LAN.  The  
component processes of the application interact via UDP datagrams.  So far so 
good - this bit works fine.  Now we're considering an extension that would allow 
some of the application's component processes to reside on "remote" (within a 
few miles) UNIX hosts, linked via packet radio.  One host would act as an IP 
router between the Ethernet subnet and the packet radio subnet (the real   
"ether" net  :-} ).  Preliminary investigation suggests 2 approaches:

1.Use the KA9Q implementation of TCP/IP.  As we understand it, KA9Q sends
  IP packets out on the RF link as AX.25 "UI" frames (essentially datagrams)  
  and doesn't bother with AX.25 virtual circuits.  Packet retransmission is
  left up to TCP.

  IMPACT:  Our application must assume the burden of retransmission, or be
  changed to use TCP connections to the hosts on the packet radio net.

2.Use SLIP to pass IP packets thru AX.25 virtual circuits.  Does this idea 
  even make sense?  

  IMPACT: The application doesn't need to use TCP, but presumably it would 
  have to bring up virtual circuit connections instead (?)

So, what are the pros and cons of these approaches?  Any tips?
E-mail replies to me and I'll post a summary to this group.


Eric Evans			   evans@titan.tsd.arlut.utexas.edu
Applied Research Laboratory
University of Texas




-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1992 17:19:10 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <2340002@hppad.waterloo.hp.com> rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
>  paul@atlas.abccomp.oz.au (Paul Brooks) wrote:
>>	Am I doing something wrong, sending an ICMP Port Unreachable?

Yes.  ICMP Port Unreachable is intended only for protocols that don't have
their own mechanism to indicate this.  Since TCP does have such a mechanism
(the RST segment), ICMP is unnecessary and inappropriate.

>Welcome to the world of BSD networking... when BSD code sees an ICMP
>host unreachable, it is unable to deliver this just to the old socket.

He said "Port Unreachable", not "Host Unreachable".

>It simply declares ALL users of/connections to the host returning the
>ICMP message as DEAD (after all, the host is dead, isn't it :-()

Not if it sent a "Port Unreachable".  I believe you're right for Host
Unreachable and Network Unreachable, but I seriously doubt that it is so
braindamaged that it kills all connections when it gets a Port Unreachable.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 18:50:29 GMT
From:      miles@cogsci.ed.ac.uk (Miles Bader)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

jim@cs.strath.ac.uk (Jim Reid) writes:
> In article <ggm.696897879@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
>    In any case, with nsfnet-relay.ac.uk being a bottleneck, the ACTUAL
>    delay for a mail exchange is variable from 15 minutes to 3 days.
 
> This is true, but not relevant. There are other JANET mail relays.
> Some JANET sites even talk SMTP....

I don't understand why it's not relevant; unless people sending mail to me
from an internet site explicitly route mail (which they shouldn't have too),
it goes through nsfnet-relay (ditto for my reply).  And of course until very
recently, sites weren't *allowed* to use smtp for external mail!

> or how an IP-only host sends mail to a CB-only host (or
> vice versa).

Well cb-only sites can send mail to/from the rest of the internet just fine,
which is obviously ip-only!  What problems are there with just letting
everyone switch to ip and using the current gateway structure to take care of
the interface with cb hosts?  There's the problem of load, but perhaps this
could be relieved to some extent by using multiple mx-hosts, etc...

-Miles
--
--
Miles Bader  --  HCRC, University of Edinburgh  --  Miles.Bader@ed.ac.uk
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
97% of everything is grunge

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 92 23:04:16 GMT
From:      tep@tots.Logicon.COM (Tom Perrine)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and SunOS 3.5


There has been some discussion on this and other mailing lists and
newsgroups about Sun and the proper broadcast address.  I know that
1's host address is the correct broadcast, and that Sun persists in
shipping SunOS with 0's broadcast.

I have inherited a small SunOS 3.5 network (with the default 0's
broadcast).  I added a second ethernet card to one of the machines
(called tots) and used that to connect to a Class B (subnetted as
Class Cs) using 1's broadcast.  One of the machines on that other net
is called hamachi.

            |
            | 137.51.4.4
	-----------
	|         |
	| hamachi |
	|_________|
	    | 137.51.1.4
	    |
	    |
	    | 137.51.1.2
	-----------
	|         |
	| tots    |
	|_________|
	    |  192.9.210.2
	    |
	    =----- other machines

I have not yet had a chance to convert the broadcast addresses, but I
noticed that the two routed's (tots and hamachi) seem to have a
difficult time communicating.  Also, not matter what default routes I
install on the 192.9 net, the machines on that subnet cannot see or bee
seen by the machines by hamachi.  (I am using ping with numeric
addresses.)  The addresses seem to be resolved properly, either by ARP
or by bing in /etc/ethers, but no replies are ever seen.  TOTS and
HAMACHI can talk to each other all day long...

I think that the problem is that SunOS 3.5 (tots) cannot handle
different broadcast addresses on the two interfaces properly.

Of course, I *will* be changing that bogus 192.9 address to the proper
137.51.2 subnet (and hopefully upgrading to SunOS 4.1.1) ASAP, but
the P is some time in the future.

Can anyone confirm my suspicions about a bug in SunOS 3.5 and
broadcast addresses?

Thanks,
Tom E. Perrine (tep)     | tep@tots.Logicon.COM  |Voice: +1 619 597 7221
Logicon - T&TSD          | sun!suntan!tots!tep   |  or : +1 619 455 1330
4010 Sorrento Valley Blvd|                       |  FAX: +1 619 552 0729
San Diego CA 92121       |Galt's Gulch - If you build it, they will come...

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Feb 1992 23:34:59 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

jim@cs.strath.ac.uk (Jim Reid) writes:
>The whole culture and mindset of IP is somewhat new to the UK. It is
>better to light a candle than curse the darkness. It's ironic that
>George had a hand in perpetuating that darkness when he worked in the
>UK. [Maybe all that Australian sunshine has dimmed the memories of his
>earlier work on Coloured Book protocols for UNIX? :-) Some of us have
>not forgotten so readily :-).....]

Forgotten? The scars are hardly healing. I saw an hh* word passing through
news and the goosebumps were palpable. About 1 introduction in 100 causes
said stranger to say 

	"oh yes, <xxx> from JANET said I should say "yorkbox" to you"

In part, I'm hoping JIPS will bury my shame forever.

Futher comments will be to the mail address as appropriate. 

	-George

--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Feb 92 23:35:04 GMT
From:      kdb@intercon.com (Kurt D Baumann)
To:        comp.protocols.tcpip,comp.dcom.lans
Subject:   Re: POP Clients -- Windows and NDIS compatible?

In article <1992Jan31.220653.8749@lawday.DaytonOH.NCR.COM>, 
jra@lawday.DaytonOH.NCR.COM (John R. Ackermann x2966) writes:
> Our requirements are a <good> Windows interface and the ability to run
> in conjunction with NDIS drivers (we haven't been able to make WinQVT
> work with NDIS).

Take a look at NetManage's product.  They are located in Cupertino, CA.  
Phone number is 408.973.7171.


Kurt Baumann                  Creators of fine TCP/IP Products
InterCon Systems            For the Macintosh

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 02:43:21 GMT
From:      a9000005@tscc2.macarthur.uws.edu.au (Brian Watson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IBM TCP/IP V2 for DOS

Hi,
   The announcement letter for IBM TCP/IP V2 mentions packet driver support.
Does this mean that this product is based on the packet driver spec. ie.
Same as Clarkson Packet Drivers?  If so, does it come with a packet driver
that works?
 

--
Brian Watson                            | Disclaimer: Any opinions
Teaching and Services Computing Centre  |  expressed are my own and do not
University of Western Sydney, Macarthur |  reflect those of my employer
Internet: b.watson@uws.edu.au           |  or anyone else.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 06:47:06 GMT
From:      raj@hpindda.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions


    >/ hpindda:comp.protocols.tcp-ip / dsroberts@beckman.com /  9:49 am  Feb  3, 1992 /
    >Our HP group has received HP's TCP/IP software so they can connect to the rest
    >...
    >be no place to define the FQDN, it doesn't allow a proper IP number
    >(134.217.247.31 has to be entered as 134.217 247.31) and there is no place to
    >tell it what the DNS host is.  Does anyone know of documentation available on
    >...
    >for questions about setting up HP TCP/IP?
    >

Well, you didn't say explicitly, but I would surmise from some of your
issues, that you are talking about an HP3000?

The IP number part is to explicitly show the split between network and
host portions - in fact, I would have thought you'd have mentioned
having to specify the class type as well, but that might have changed.

As for DNS - there is no DNS on the HP 3000's. Certainly not with the
current releases. If your remote hosts do not speak Probe, then you
will have to configure-in names into the Network Directory (the analog
to an /etc/hosts file...). Of course, if someone would like to correct
me... 

In general, I would strongly suggest ordering some of the manuals for
that stuff - it can be someone different from other systems. Your
local HP rep should have the part numbers and all. Otherwise, more
expert advice might be found in comp.sys.hp...

rick jones 
___   _  ___
|__) /_\  |    Richard Anders Jones   | HP-UX   Networking   Performance
| \_/   \_/    Hewlett-Packard  Co.   | But   MPE   Sticks   to   you...
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 07:32:02 GMT
From:      sinkkila@venus.csc.fi (Timo Sinkkila)
To:        comp.protocols.tcp-ip
Subject:   Looking for slip for SunOS 4.1.1


Hi there,

I am looking for slip package for sun 3/60 running SunOS 4.1.1.
I installed slip-4.1-beta, but it didn't work very well,
the system crashed every time when the the line dropped.

Thanks,

Timo
---------------------------------------------------------------
sinkkila@csc.fi		Center for Scientific Computing
SINKKILA@FINFUN.BITNET 	PL 40   SF-02101 Espoo FINLAND
Phone: +358 0 4571       Telefax: + 358 0 4572302

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 08:33:38 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [here sme time ago...]



 >> or how an IP-only host sends mail to a CB-only host (or
 >> vice versa).
 >
 >Well cb-only sites can send mail to/from the rest of the internet just fine,
 >which is obviously ip-only!  What problems are there with just letting
 >everyone switch to ip and using the current gateway structure to take care of
 >the interface with cb hosts?  There's the problem of load, but perhaps this
 >could be relieved to some extent by using multiple mx-hosts, etc...
 
Miles, & george m.

 d'ye know the ecomomics of this?
do you know how many CB only mailer/archive sites there are?
do you know how many IP hosts? how many you actually want to reach?
do you trace mail headers to see _where_ delays are?
have you compared mail delay to ftp delay, run traceroute,
done any IP throughput delay studies, etc
etc etc...
shoestring&jips did all of this (for 0 cost to JNT)

the emerging model is that most sites (for many reasons) want a single
(probably replicated or triplicated hot stanmdby) "host" for external
service contact (site = university, or very big department, or
company, e.g. ibm.com ,sun.com etc etc) for
e-mail, ftp, archie services etc

for this then read about 100 important name/address pairs for the
ac.uk. community; the rest are bilateral arrangements for direct
collaboration...

if you try contacting other machines without being told a
name/address or having an account, it is likely you are misbehaving,
or else causing undue/unwanted traffic...

if you try putting up a sendmail/other configuration for a department
with 3 workstations in a college with a computing service with more
than 20 staff, you have probably just wasted a _lot_ of money

the economy of scale of networks is a fairly well understood
business...

cheers

jon

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 15:33:41 PDT
From:      dsroberts@beckman.com
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions

Hey, I'm just a DEC person who has experience with TCP/IP trying to help out
our HP folks with no experience of that sort, so please forgive my HP
ignorance.

In article <JASON.92Feb4153935@jazz.cnd.hp.com>, jason@jazz.cnd.hp.com (Jason Zions) writes:
> In article <1992Feb3.104910.794@beckman.com> dsroberts@beckman.com writes:
> 
>    Does anyone know of documentation available on the net for this?  Is
>    there anyone familiar with HP TCP/IP that can help me, or point me in the
>    right direction?  Is there another newsgroup more appropriate for
>    questions about setting up HP TCP/IP?
> 
> Questions on HP gear are generally answered fastest on comp.sys.hp. 

Don't get that newsgroup.  I'll add it to our news so we'll start getting it. 
Thanks for the pointer.

>It would
> help if you identified the specific model of HP system you're having trouble
> with, as well as the particular release of the OS in question.
> 
HP 3000 MPE/V Os version?  I'm not the HP person, thanks.  I'll ask them
tomorrow.

> Also, all HP systems come with documentation, generally considered better
> than average; I assume you've already tried to figure it out from the HP
> manuals, but I might suggest another pass through them.

We have the CDROM's, we have a bunch of manuals.  The HP person says "we don't
have the manuals for the TCP/IP product."  So, no luck there.

As far as better than average, I'll say that your docs are definitely better
than the MVS docs I've seen.  Now if your docs were anywhere near as good as
VMS docs, I might like them.  Certainly better than MS-DOS and Unix.  So I
guess their better than average based on my small sample.
> --
> This is not an official statement of The Hewlett-Packard Company. No war-
> ranty is expressed or implied. The information included herein is not to be
> construed as a committment on HP's part. Save a tree - kill an ISO working
> group today. Disclaimers are an ABA conspiracy.
> 
> Jason Zions			The Hewlett-Packard Company
> Colorado Networks Division	3404 E. Harmony Road
> Mail Stop 102			Ft. Collins, CO  80525  USA
> jason@cnd.hp.com		(303) 229-3800
-- 
---------------------------------------------------------------------------
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Commercial Unix - An oxymoron
---------------------------------------------------------------------------

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Feb 1992 09:46:47 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <2340002@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
> 
>   paul@atlas.abccomp.oz.au (Paul Brooks) [thats me!] wrote:
> 
> >                                                            it sees that it
> > is for a non-existent port, and sends both an ICMP Port Unreachable, and
> > a TCP RESET segment. When the Sun sees the ICMP Port Unreachable, it resets
> > all the other connections between these two hosts, dropping the new
> > connection as well as the old!
 
> >	Am I doing something wrong, sending an ICMP Port Unreachable?
 
> > Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl
> 
> Welcome to the world of BSD networking... when BSD code sees an ICMP
> host unreachable, it is unable to deliver this just to the old socket.
> It simply declares ALL users of/connections to the host returning the
> ICMP message as DEAD (after all, the host is dead, isn't it :-()

You mean BSD doesn't bother looking at the sub-function to see what sort
of 'XXX unreachable' (port, host or protocol) the ICMP message is??????
BTW, it seems to happen when talking to SysV hosts as well. In fact,
thats where I first got bitten by this, but I know of a few more bugs in
that TCP/IP (Lachman derivatives from Intel & AT&T for SysV 3.2 /386) so
figured it was the result of bugs in that end. One of those hosts sends
about 1/3 of its PING (ICMP:Echo) packets with the IP version number set
to 0 - so my IP layer drops them, as per RFC 1122. In the interests of
being "liberal in what I receive", should I bother checking it at all,
and non-conform with Host Requirements?.

Thanks for the comment - the first "bite" at my problem since I posted
a week ago!

> If you suppress the ICMP message and just Reset,  you should be OK.

I guessed this, but was trying to write a _complete_ implementation!

> 
> Ted Rypma
> HP Panacom Division


Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 10:33:16 GMT
From:      lejouad@genaro.inria.fr (Wided Lejouad)
To:        comp.protocols.tcp-ip
Subject:   RPC & TCP/IP


  I am a research student preparing a Ph.D. thesis in Artificial
Intelligence. My work consists in:

- Designing a distributed architecture for an expert system shell,
  which include an object-oriented language, an inference engine, an
  inference rules and a state tree corresponding to the reasoning
  trace. 
- Providing a consistency between the system state and the graphic
  interface. 

  I am trying to solve a problem related to the communication between
the autonomous processes of the system in question. Two protocols have
been studied: TCP/IP using sockets and RPC. I must justify my choice
and give sufficient arguments to use one of these two protocols.

  I have implemented an example of two processes in C: a client and a
server, such as the client sends an integer to the server and the
server returns the integer to the [first...tenth] power. This example
runs in SUN/UNIX environment and is based on TCP/IP. My problem is
related to the implementation of the same example using RPC protocol
which require a particular form of type declarations with XDR
routines. I do not understand how to declare types , where de we
develop the main services, which approach must be taken into account
to be sure that we follow the good way ...? 

  It's important to mention some points concerning this work:
- The Expert System Shell (ESS) components need synchronous
  communication. 
- The ESS is developed in Le-Lisp.
- The principal characteristics, I try to ensure, are:
  * rapidity,
  * flexibility,
  * security,
  * weak development time.

  So, if anyone can just point me in the right direction, as to
clarify the Remote Procedure Call, the difference between the two
mentioned protocols, which one is more adapted to the ESS, ... that
would be great.

  Please email me the answer, and if some people are interested, I can
post it in the same group.

THANKS.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        Wided LEJOUAD (i.e. trust among friends & hospitality) 
        SECOIA Project 
    INRIA-Sophia Antipolis  
  Email: lejouad@sophia.inria.fr 
       Tel: (+33) 93 65 77 43 
       Fax: (+33) 93 65 76 43   
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 15:39:35
From:      jason@jazz.cnd.hp.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions

In article <1992Feb3.104910.794@beckman.com> dsroberts@beckman.com writes:

   Does anyone know of documentation available on the net for this?  Is
   there anyone familiar with HP TCP/IP that can help me, or point me in the
   right direction?  Is there another newsgroup more appropriate for
   questions about setting up HP TCP/IP?

Questions on HP gear are generally answered fastest on comp.sys.hp. It would
help if you identified the specific model of HP system you're having trouble
with, as well as the particular release of the OS in question.

Also, all HP systems come with documentation, generally considered better
than average; I assume you've already tried to figure it out from the HP
manuals, but I might suggest another pass through them.
--
This is not an official statement of The Hewlett-Packard Company. No war-
ranty is expressed or implied. The information included herein is not to be
construed as a committment on HP's part. Save a tree - kill an ISO working
group today. Disclaimers are an ABA conspiracy.

Jason Zions			The Hewlett-Packard Company
Colorado Networks Division	3404 E. Harmony Road
Mail Stop 102			Ft. Collins, CO  80525  USA
jason@cnd.hp.com		(303) 229-3800

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 13:10:46 GMT
From:      devil@diablery.10A.com (Gil Tene)
To:        comp.protocols.tcp-ip
Subject:   vendor supported TCP/IP source.

Hello TCP/IP land,

I am intersted in locating a vendor that supplies supported TCP/IP 
source code that is adpted for use with telnet, tn3270, ftp, snmp, 
ucp, etc.

I'd like to use this source code to add TCP/IP features for an
existing network controller.

Anyone out there know of such a vendor?

AdvThanks,

-- Gil.
-- 
--------------------------------------------------------------------
-- Gil Tene			"Some days it just doesn't pay     -
-- devil@imp.HellNet.org	   to go to sleep in the morning." -
-- devil@diablery.10A.com 					   -
--------------------------------------------------------------------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 14:27:16 GMT
From:      weissh@nextadm.cc.vt.edu (Hugh Weiss)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBM TCP/IP V2 for DOS

In article <a9000005.697171401@tscc2> a9000005@tscc2.macarthur.uws.edu.au (Brian Watson) writes:

>   The announcement letter for IBM TCP/IP V2 mentions packet driver support.
>Does this mean that this product is based on the packet driver spec. ie.
>Same as Clarkson Packet Drivers?  If so, does it come with a packet driver
>that works?

Yes, the product is based on the same packet driver spec as the Clarkson
(now Crymwr) Packet Driver Collection.  This product can use a packet
driver to access the Ethernet.  The product also supports several Ethernet
adapters directly and if you use one of these directly supported adapters,
you won't need a packet driver.  See the announcement letter for a list
of these directly supported adapters.

Although I don't have the product I do use the academic version of it
(MD-DOS/IP).  I doubt that IBM TCP/IP V2 includes the packet drivers in
its distribution.  BUT you can get them via FTP from Clarkson University.

Hostname sun.soe.clarkson.edu (128.153.12.3)
Directory pub/packet-drivers

Good luck, hope this helps clear things up.

-Hugh Weiss
-Virginia Tech Computing Center - Distributed Computing Group
-weissh@nextadm.cc.vt.edu   OR   weissh@vtcc1.cc.vt.edu

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 14:56:18 GMT
From:      fvance@airgun.wg.waii.com (Frank Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for MVS

In article <1992Feb1.202751.5750@vicstoy.UUCP>,
	gmbuchan@vicstoy.UUCP (Greg Buchanan) writes:
> Does anyone know of or could recommend an alternative to the IBM TCP/IP for
> MVS program product. Am looking for alternatives which could provide
> additional functionality (including net mgmt, NFS client, etc.)

Try SNS/TCPaccess from Interlink.  Don't have their address here at the moment,
but the phone number is (301)-317-6600.  I'm sure someone there can find the
right person to call.

-- 
Frank Vance  +1.713.963.2426		Western Geophysical
FrankVance@airgun.wg.waii.com		10001 Richmond Avenue
Fax: +1.713.963.2758			Houston, TX 77042   USA

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 15:07:14 GMT
From:      sra@idx.com
To:        comp.protocols.tcp-ip
Subject:   Setting up an IP server task?

I've been charged with setting up an IP server task (launched by inetd).
Needless to say, documentation is scarce.  It is my understanding that
processes started by inetd have their communications already set up on
socket 0.  Is that true?  Is the connect() already performed and I just
start doing read/write as necessary?  I assume I just do a close when I'm
about to exit.

tnx for advice, steve

ps - if some kind soul could E-mail a "small simple" example, I'd be
grateful.

  /------------------------------------------------------------------------\
  >   Steve Alpert (W1GGN)  IDX Corporation    Marlborough, Massachusetts  <
  \--------------------------- sra @ idx.com ------------------------------/

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 4 Feb 1992 13:25:39 IST
From:      Shlomit Rot <P88033@BARILVM.BITNET>
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   OCR software

I'm looking for info on OCR software/hardware for UNIX platforms.
(Wich product on which machine. Mostly interested in AIX-3.2 and SUN's)
      Thanks in advance
         Shlomit Roth
       P88033@BARILVM.BITNET

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Feb 1992 18:48:22 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.protocols.tcp-ip
Subject:   PING source wanted

Subject says it all. Where can I find it via anonymous FTP? Email's okay; I
don't want to tie up bandwidth.

Thanks in advance.

Walt
-- 
  :: Walter R. Trachim              walt@unhsst.unh.edu                     ::
  :: University of New Hampshire -- Telecommunications and Network Services ::
  :: Durham, NH 03824               Voice:(603)862-4742  Fax:(603)862-2030  :: 
   "When you're up to your ass in alligators, it's hard to remember that your
    initial objective was to drain the swamp."  --U.S. Marine Corps Proverb 

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 18:50:26 GMT
From:      fvance@airgun.wg.waii.com (Frank Vance)
To:        comp.protocols.tcp-ip
Subject:   Existing RFC1256 (Router Discovery) imlementations

Recognizing that rfc1256 is only a proposed standard at this time:

1.  Are there any existing commercial routers which have this today?
    Cisco, Wellfleet, ACC, NSC????

2.  Does gated support it, or will it in the future?

3.  Is there any publically available source to support this on hosts?
    I envision something which would basically replace routed....

Thanks,
-- 
Frank Vance  +1.713.963.2426		Western Geophysical
FrankVance@airgun.wg.waii.com		10001 Richmond Avenue
Fax: +1.713.963.2758			Houston, TX 77042   USA

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Feb 1992 19:32:14 GMT
From:      jch@mitchell.cit.cornell.edu (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Existing RFC1256 (Router Discovery) imlementations

> Recognizing that rfc1256 is only a proposed standard at this time:
> 
> 2.  Does gated support it, or will it in the future?

Not yet, but I plan to add support for both client and server side of
this when I get a chance.  I don't know if I will base it on Sun's
version or rewrite it from scratch.

If someone wants to volunteer to do this, please contact me as
gated@gated.cornell.edu.

> 3.  Is there any publically available source to support this on hosts?
>     I envision something which would basically replace routed....

Sun made their source available, but I forgot where I FTP'd it from.

Jeff

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 92 19:48:30 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET


  From listening to the JNT folks justifying their inaction it sure
sounds as if networking in the UK is mostly driven by personal
connections and politics.  It has always been a great mystery to many
of us on this side of the pond why the British are so fond of
structure and form and organisation over results and an open process.

  I haven't heard anyone from JNT ask the original poster if he'd
be willing to help with the conversion/testing.  It seems like a 
logical thing to do if the goal is to get IP working.  

  Moreover, I really wonder about the unsubstantiated claims of
complexity.  Commercial IP hardware is commercial off-the-shelf (COTS)
and is very much plug and play.  Yet they seem to be having no end of
problems.  PSI or UUNET ought to offer to integrate it all for them --
such would probably be cheaper also if they are having so many
problems.

just reaction from a disinterested observer...

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Feb 92 22:34:53 GMT
From:      gih900@cruskit.aarnet.edu.au (Geoff Huston)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [here sme time ago...]

In article <2309@ucl-cs.uucp>, J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
> if you try contacting other machines without being told a
> name/address or having an account, it is likely you are misbehaving,
> or else causing undue/unwanted traffic...

Have I read this right? Is this statement really advocating that the
appropriate way of disseminating the addresses of people and resources
on the network is by word of mouth?

(Any followups to the newsgroup please - with a readership of this
message numbering in the thousands its probable I haven't personally
told you my mail address - so you should even try. :-)   )


-- 
Geoff Huston,
The Colonies

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Feb 92 23:51:51 GMT
From:      mah@DIALix.oz.au (Marcus Hayes)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   Re: How do I connect a thin-net loop to a thick-net backbone ?

In <1992Feb1.173114.28513@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:


>In article <1992Jan30.222143.13143@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes:
>>In a pinch, a thin co-ax segment may be spliced into a thick wire
>>back-bone but it is not a good idea.  It is possible to find N ->
>>BNC adaptors.  The problem is that the network is no better than
>>the worst segment, so the most cynical restrictions on the thin
>>co-ax have to be applied to the entire network.
>>
>That last part is just not true. The only big difference between thin and thick
>cable is signal loss. If you mix them, you indeed get some sort of
>average performance. You absolutely don't have to apply "the most cynical
>restrictions on the thin co-ax have to be applied to the entire network".
 
>Doug McDonald

Anyone suggested connecting the segments together with a repeater?


-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 08:44:31 CST
From:      u1906ad@unx.ucc.okstate.edu (11906)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Remote Printing Over Telnet


Quite some time ago, there was some code posted which makes
it possible to use telnet to drive printers.  In other words,
a system using lpd could send its print job over the Ethernet
via telnet to a terminal server port.  At the time, I was not
interested in this code so I didn't save it.  If anybody
knows about such an application or where it might be ftp'd,
please let me know.  Many thanks.


Martin McCormick
Amateur Radio WB5AGZ
Oklahoma State University
Computer Center
Data Communication sGroup
Stillwater, OK

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 03:05:24 GMT
From:      dennis@longs.LANCE.ColoState.Edu (Dennis Miyoshi)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Telnet and Rlogin fails on 386 UNIX

I am having a problem with tcp/ip on a AT&T 386 UNIX SYSV system.
We have installed an NP600A board to handle the ether communications.
Initially we installed the NP600A driver and Enhanced 386 WIN TCP/IP
software as a nameserver and everything check out fine.  We were
able to attach the system to a network and utilize all of the TCP/IP
features.

However, now, we have reconfigured the 386 UNIX box and reinstalled
the OS and Drivers and TCP/IP.  The NP600A driver and TCP/IP are
installed exactly as before.  The good news is that "telnet me" (me
being the local host on this machine) works.  The bad news is that
"telnet rhost", "telnet address", "telnet etc" timeout and say that
connection can not be established.  We have check the domain and
addresses for the hosts and all seem to be in order.

If anyone has any clue as to why this is happenning, please let me
know.

Thanks for the help.

Dennis Miyoshi, PE
Systems Engineer
USDA-SCS


--
===============================================================================
ARPA Internet:  dennis@longs.lance.colostate.edu
UUCP         :  ...ncar!boulder!ccncsu!longs.lance.colostate.edu!dennis
========================= ( ROBUST == A Broken Robot ) ========================

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 04:10:23 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Two ethernets better than one?

We have three NFS servers, a Sun 4/280, and two Sun 4/670s, all on the
same ethernet subnet.  About half the workstations are also on this subnet,
but the other half are connected to another subnet on a second ethernet
card in the 4/280.  Would it be a good idea to put a second ethernet card
in both the 4/670s and put them on both segments too?  Would this cause
any problems?  How will IP traffic between the three servers work?  Is
there a way to confine it to one subnet?  I assume that all servers should
run routed, but only one advertize RIP?  Has anyone else done this?

-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Feb 1992 04:55:22 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <koquceINNt8f@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> In article <2340002@hppad.waterloo.hp.com> rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
> >  paul@atlas.abccomp.oz.au (Paul Brooks) wrote:
> >>	Am I doing something wrong, sending an ICMP Port Unreachable?

[Summary: I (Paul Brooks) open a TCP connection. Later I kill my
machine, reboot and start another connection. Ather end re-tries old
connection, my end sees a packet for (now) unknown TCP port, and sends
ICMP:Port Unavailable instead of/as well as TCP RESET segment. Other end
immediately closes ALL new connections bewteen the machines]

> Yes.  ICMP Port Unreachable is intended only for protocols that don't have
> their own mechanism to indicate this.  Since TCP does have such a mechanism
> (the RST segment), ICMP is unnecessary and inappropriate.

How old is SunOS 4.11 code? From RFC 1122, 3.2.2.1:
"   A Destination Unreachable message that is received MUST be
    reported to the transport layer.  The transport layer SHOULD
    use the information appropriately; for example, see Sections
    4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that
    has its own mechanism for notifying the sender that a port
    is unreachable (e.g., TCP, which sends RST segments) MUST
    nevertheless accept an ICMP Port Unreachable for the same
    purpose. "
> 
> >Welcome to the world of BSD networking... when BSD code sees an ICMP
> >host unreachable, it is unable to deliver this just to the old socket.
> 
> He said "Port Unreachable", not "Host Unreachable".
> 
> >It simply declares ALL users of/connections to the host returning the
> >ICMP message as DEAD (after all, the host is dead, isn't it :-()
> 
> Not if it sent a "Port Unreachable".  I believe you're right for Host
> Unreachable and Network Unreachable, but I seriously doubt that it is so
> braindamaged that it kills all connections when it gets a Port Unreachable.
> -- 
> Barry Margolin, Thinking Machines Corp.
> 
> barmar@think.com
> {uunet,harvard}!think!barmar


Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 10:05:23 GMT
From:      hulsebos@ehviea.ine.philips.nl (rob hulsebos)
To:        comp.protocols.tcp-ip
Subject:   Bug in ip_frag2() ?

Anyone ever heard of a bug in the ip_frag2() routine, which 
sometimes creates mbufs with a negative length?  It creates
problems for our networking driver which, due to the negative
length, erases certain arrays in the same driver causing the
system to crash.

Any help/info/tips is appreciated,

---

Rob Hulsebos (hulsebos@ine.philips.nl)
Philips Industrial Electronics
Pobox 218, 5600 MD Eindhoven, Holland
Tel. +31-40-786114

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 13:20:45 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

> >Welcome to the world of BSD networking... when BSD code sees an ICMP
> >host unreachable, it is unable to deliver this just to the old socket.
> 
> He said "Port Unreachable", not "Host Unreachable".
> 
> Unreachable and Network Unreachable, but I seriously doubt that it is so
> braindamaged that it kills all connections when it gets a Port Unreachable.

Yes it does... check it out.

Ted Rypma
HP Panacom

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 13:33:19 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions

dsroberts@beckman.com wrote:

> Our HP group has received HP's TCP/IP software ...

HP sells more different kinds of computers than I care to remember, but
essentially only three operating systems: MPE (2 flavours), HP-UX (Un*x)
and MSDOS/OS2. (Care to enlighten us with which OS you running "HP's TCP/IP"?)

>                                 it doesn't allow a proper IP number
> (134.217.247.31 has to be entered as 134.217 247.31)
   ^^^^^^^^^^^^^^      ==              ^^^^^^^^^^^^^^
How would you like to enter the IP address?

>                   Is there anyone familiar with HP TCP/IP that can help me, or

If you were more specific someone out there may be able to help.

>                                   Is there another newsgroup more appropriate
> for questions about setting up HP TCP/IP?

There is a "comp.sys.hp" and many people who know HP software and hardware are
listening.

> Thanks.
>  Don Roberts                   Internet:  don@beckman.com

Your welcome, but next time, try to be a little less inflammatory when you
ask for help.

Ted Rypma
HP Panacom Division
(Speaking, of course, for himself)

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Feb 1992 14:17:39 GMT
From:      brookste@infonode.ingr.com (Tracy E. Brooks)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   Re: How do I connect a thin-net loop to a thick-net backbone ?

In article <1992Feb4.235151.19113@DIALix.oz.au>, mah@DIALix.oz.au (Marcus Hayes) writes:
> In <1992Feb1.173114.28513@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
> 
> 
> >In article <1992Jan30.222143.13143@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes:
> >>In a pinch, a thin co-ax segment may be spliced into a thick wire
> >>back-bone but it is not a good idea.  It is possible to find N ->
> >>BNC adaptors.  The problem is that the network is no better than
> >>the worst segment, so the most cynical restrictions on the thin
> >>co-ax have to be applied to the entire network.
> >>
> >That last part is just not true. The only big difference between thin and thick
> >cable is signal loss. If you mix them, you indeed get some sort of
> >average performance. You absolutely don't have to apply "the most cynical
> >restrictions on the thin co-ax have to be applied to the entire network".
 
> >Doug McDonald
> 
> Anyone suggested connecting the segments together with a repeater?
> 
My company sells what we call a Multiport Ethernet Repeater, it provides
six BNC connections for Thin Ethernet segments and two drop cable connections
for either Thin or standard Ethernet.  I'm sure other companies make such
animals also.

Don't ask for quotes, sales is not my arena.

Standard disclaimers apply.

    ______________________________________________________________________
       Tracy Brooks --------------------- Intergraph Corporation               
                          Knoxville, Tennessee
       uunet!infonode!brookste --or-- brookste@infonode.ingr.com   
    ----------------------------------------------------------------------



-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 14:56:49 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Is Layering Harmful? (Jan 92 IEEE Network)


A postscript version of the original report that was submitted
on some anomalous RPC performance problems and some more general
observations (including figures 1-7, not present in journal) is 
available for anonymous ftp from 

cs.ucl.ac.uk (128.16.5.31)
in
docs/rpcperf.network.tar.Z

(compressed Unix tar file, so use binary mode ftp)
[its about 92k long]

please let us know if there any problems accessing this.

jon crowcroft

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 15:08:36 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET


 >  From listening to the JNT folks justifying their inaction it sure
 >sounds as if networking in the UK is mostly driven by personal
 >connections and politics.  It has always been a great mystery to many
 >of us on this side of the pond why the British are so fond of
 >structure and form and organisation over results and an open process.

this is very far from what actually happens
1. the JNT are not inactive
2. the JIPS service to about 1/2 the universities was in direct
response to general user request.
3. the UK networks are slightly more coherent than some other national
networks (try ftp-ing from a random french university)
4. the slowness in going to IP was (in part) because resources were
tied up in going to OSI (e.g. X.400 & X.500 widely used in US are UK
JNT sponsered...)

 >  I haven't heard anyone from JNT ask the original poster if he'd
 >be willing to help with the conversion/testing.  It seems like a 
 >logical thing to do if the goal is to get IP working.  

it is working...

 >  Moreover, I really wonder about the unsubstantiated claims of
 >complexity.  Commercial IP hardware is commercial off-the-shelf (COTS)

yes, but interworking between existing color book and ISO, and stopgap
IP is not so simple - again, that is part of the slowness...

the actual IP backbone was put up one day last november by a couple of
people...
 
 >just reaction from a disinterested observer...

always interested in observations...

actually, as per a private message to geo. michaelson, i think the
optimal conversion date would have been 1987, and it was _harder_ to
do coz it was left 5 years longer ...

 jon

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 17:05:03 GMT
From:      sat@thomson.UUCP (Scott Thomson)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Need help with AIX PS/2 and TCP/IP

I am working with a local technical college in trying to get an AIX machine
running using their existing network.  This is my first attempt at installing
TCP/IP on anything but I am familiar with networks in general.
Some of the specifics are:

  - IBM PS/2, model 80, 70MB disk, 10MB RAM, IBM Token Ring Adapter
  - AIX PS/2, Version 1.2
  - TCP/IP software from IBM
  - AIX DOS Server Release 1.2.1 (basically PC Interface)
  - A PC lab with 30 - PS/2, model 30s, dual floppy, no hard disk,
    IBM Token Ring Adapter

The 30 PS/2s in the lab are have connection to an AS/400 and an IBM mainframe
(3090 I think), as well as a file server running Lan Manager.  (Yes this is
a very BLUE school. :-)   There is a menu system running on the PS/2s for
the students to select which host machine to connect with.

The AIX system is running OK, but only has the console for access.  We are
trying to get the PS/2s in the lab to run as terminals on AIX via the network.
I realize that the PS/2s will need to be booted each time we attach to the AIX
box in order to get the TCP/IP drivers loaded (and the Lan Manager drivers out
of the way).

This did work ONCE a while back!  But then we only had 2MB RAM on the AIX
system and it was thrashing itself to death (literally at times).  Now we have
plenty of memory (sure runs nice now!) but I cannot get the TCP/IP network
to function.

I have re-build the kernel from scratch for the token ring and TCP/IP drivers.
That made no difference.

During boot time, the 'timed' process starts but generates the following:
	tdsendto: ff0101c0: Network is down
This message appears three times during the boot process if timed is a master
and only one message if timed is a slave.

After booting, 'ps -e' always shows a <defunct> process.  Something to do
with the network?

There are no other TCP/IP machines anywhere on the ring (that I know of, but
it is a school-wide ring).

Running 'ping' to itself shows a good connection.

If I disconnect the Token ring cable from the rest of the ring, AIX recognises
that the ring is broken and generates a message on the console.

If I try to start the AIX Access Under DOS terminal emulator (vt-100), it looks
for any hosts but does not find any.

I have the AIX host's address set to 192.1.1.1 and the PS/2s to 192.1.1.101,
192.1.1.102, etc.

I have read through (several times) the installation instructions, as well as
re-checking the configuration files and don't know what's wrong.  Any help
in solving this or suggestions of what to look for would be GREATLY
appreciated.

I also have a question...
Using the 'devices' command, I created a network terminal (ttyn0) and an
asynchronous psuedo-terminal (ttyp0) and enabled both.  What is the difference
between the two and which one do I want for the network access from DOS?

If you need more info, please e-mail what else you need.

Thank you,
Scott Thomson
-- 
					Thomson Software Services, Inc.
Scott Thomson				         P.O. Box 869
					    Neenah, WI  54957-0869
sat@thomson.uucp			        (414) 722-5700

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1992 17:08:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <1992Feb5.045522.2363@usage.csd.unsw.OZ.AU> pwb@newt.phys.unsw.oz.au (Paul W. Brooks) writes:
>How old is SunOS 4.11 code? From RFC 1122, 3.2.2.1:

I think it's a mixture of 4.2bsd and 4.3bsd.

>"   A Destination Unreachable message that is received MUST be
>    reported to the transport layer.  The transport layer SHOULD
>    use the information appropriately; for example, see Sections
>    4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that
>    has its own mechanism for notifying the sender that a port
>    is unreachable (e.g., TCP, which sends RST segments) MUST
>    nevertheless accept an ICMP Port Unreachable for the same
>    purpose. "

Remember the internetworking credo: Be liberal in what you accept, and
conservative in what you send.  While the RFC says that a TCP
implementation must accept ICMP Port Unreachable, it's clear that there are
implementations that don't.

In my previous message I said sending the ICMP Port Unreachable for a TCP
segment is "unnecessary and inappropriate."  Given the above RFC, I'd like
to revise that to "unnecessary and ill-advised."  Do you have some
particular reason you feel it is important for your TCP implementation to
send ICMP Port Unreachable in addition to the TCP RST?
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 17:53:39 GMT
From:      suresh@uts.amdahl.com (Suresh Padmanabhan)
To:        comp.protocols.tcp-ip
Subject:   Timer in CLOSING state ??



This is my first posting to a newsgroup, so bear with me on this
one, folks.

The scenario is as follows :

A simultaneous CLOSE is initiated by both ends of a TCP connection
and FIN's are exchanged. The server (which has the problem) goes
into CLOSING state and awaits an ACK for the FIN, from the remote
end. Intermittently, this ACK never arrives. Consequently, the
connection hangs in CLOSING state for ever and prevents the server
from being restarted (since the internet control block is not freed
and is still bound to the destination port).
 

The question is :

- Is implementation of a timer mechanism in CLOSING state, advisable ??


suresh
Amdahl Corporation 
-- 

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Feb 1992 19:36:04 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: Bug in ip_frag2() ?

In <1084@ehviea.ine.philips.nl> hulsebos@ehviea.ine.philips.nl (rob hulsebos) writes:

+>Anyone ever heard of a bug in the ip_frag2() routine, which 
+>sometimes creates mbufs with a negative length?  It creates
+>problems for our networking driver which, due to the negative
+>length, erases certain arrays in the same driver causing the
+>system to crash.

	ip_frag2() is full of bugs.  The problem is very poor coding
and the only viable solution to it is to figure out what the routine
is doing and re-code it....or take out the call to it altogether.
	There is also the potential for ip_frag2() to spin forever on
certain mbuf clains.


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 20:10:07 GMT
From:      ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun BOS Software)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS broadcast address

In article <1992Jan25.093952.24835@rtf.bt.co.uk> duplain@rtf.bt.co.uk (Andy Duplain) writes:
>
>	The SunOS 4.1.1 ifconfig
>	program  defaults  the  broadcast  address to xxx.xxx.0.0, and this
>	is  documented  as  correct  in  the man page, but Comer (vol 1 2nd
>	edition page 64) states: 
>	"According to the standard, any hostid consisting of all 1s is
>	reserved for broadcast++"
>	Are Sun still making the mistake described by Comer ?

Because of the severe broadcast storms that can occur when you mix
systems running old versions of BSD TCP/IP with systems using the 1's
broadcast address convention, and because some Sun users have no idea
what a "broadcast address" is,  Sun chose to continue to _default_ to
the 0's broadcast address convention for a long transition period.  

Now that there are hardly any systems running the old broken BSD
version of TCP/IP, the transition period is finally ending.  The
next release of SunOS, which will be called Solaris 2.0, will
_default_ to the 1's broadcast address convention.  

>	What should the broadcast address be...?

Whatever you think it should be after considering the needs of all the
systems on your network.  If you're sure you don't have any old broken
systems that can contribute to broadcast storms, want to be consistent
with the latest RFCs, and don't have a problem with setting a value
explicitly rather than just blindly accepting a "default", you should
use the 1's convention.  


In article <hanson.696544051@pogo> hanson@pogo.fnal.gov (Steve Hanson) writes:
> ...
>I find it particularly interesting that (at least in 4.1.1) if you do this
>with ifconfig (setting broadcast to 1's) ifconfig complains and says this
>is an invalid broadcast address.  Then apparently it goes ahead and
>sets it anyway.  You'd think Sun would at least make it easier to 
>do the right things and not have the OS complain when you do.

`ifconfig` already does do the right thing without complaining.  The
reported complaint only comes out if you try to set the same broadcast
address on all network interfaces, including the loopback interface, by
saying `ifconfig -a ...`.
---
chuck kollars <ckollars@East.Sun.COM>		(located in Boston)
Systems and Network Administration Group (SNAG)

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 20:11:54 GMT
From:      jdc@mojave.ece.arizona.edu (Jo Dale Carothers)
To:        comp.unix.i386,comp.protocols.tcp-ip
Subject:   SLIP for SCO UNIX

I need SLIP software that will run on 386 or 486 based PC's that
are running SCO UNIX.  Does this software exist?  If so, where can
I find it.

Thanks,
Jo Dale Carothers

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Feb 92 20:21:38 GMT
From:      cmilono@netcom.COM (Carlo Milono)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: Telnet and Rlogin fails on 386 UNIX

In article <1992Feb05.030524.63149@yuma.acns.colostate.edu> dennis@longs.LANCE.ColoState.Edu (Dennis Miyoshi) writes:
>I am having a problem with tcp/ip on a AT&T 386 UNIX SYSV system.
  [stuff deleted]
>However, now, we have reconfigured the 386 UNIX box and reinstalled
>the OS and Drivers and TCP/IP.  The NP600A driver and TCP/IP are
>installed exactly as before.  The good news is that "telnet me" (me
>being the local host on this machine) works.  The bad news is that
>"telnet rhost", "telnet address", "telnet etc" timeout and say that
>connection can not be established.  We have check the domain and
>addresses for the hosts and all seem to be in order.
     [more stuff deleted]

Can you ping this station from another?  It sounds like you have reconfigured
the device into the 'loopback' driver, which for some very arcane reason is
the default :)  Go through the menus and check the hardware, and I believe
you will see that the driver is indeed 'loopback' rather than NP600A.  This
default is found in other Wollongong SYSV implementations, and I have a system
that has both a Token-Ring *and* an Ethernet port for TCP/IP and NFS, and I
had the same trouble when I added the TR driver...everything went back to
'loopback'.
-- 
+--------------------------------------------------------------------------+
|            Carlo Milono:  cmilono@netcom.com                             |
|      "The Sun ain't Yellow: it's Chicken!" - Bob Dylan                   |
+--------------------------------------------------------------------------+


-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Feb 1992 20:24:20 GMT
From:      pbh@arcturus.honeywell.com (Paul B. Henninger,MN51-1320,785-4238,420-7478,pbh@drafting)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP services listing

can someone provide me with a more complete listing of TCP/IP
services than can be found in Sun's /etc/services?  i am running
etherfind on a Sun running 4.1.1 and seeing a great deal of
traffic to ports that are undefined in /etc/services - i would
like to know what this traffic is.

please reply directly to me - i am not a regular reader of this
group.

-----------------------------------------------------------
paul henninger
pbh@cfsmo.honeywell.com
honeywell, commercial flight systems
8840 evergreen blvd   mpls, mn 55433


-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Feb 92 20:26:37 GMT
From:      ptrubey@netcom.COM (Phil Trubey)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Remote access protocol for NetWare?

Novell used to have the ability for PC users to dial into a Novell network
and then their remote PC would be a NetWare node on the network.  Has
Novell stopped offering this?  Their latest catalog had the NetWare Access
server, which is a different animal altogether (although to the user it
appears to do the same thing better).

The reason I ask is that I was wondering is there was an IPX equivalent
of Apple's AppleTalk Remote Access protocol.

Along the same lines, I know that  NetWare now supports TCP/IP.  But is
that only for NetWare server to server communications?  Can NetWare
clients communicate with the server via a TCP/IP transport?

-- 

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

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 20:29:37 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   BSD sockets question

Hello all,


I seem to have a problem sending ICMP datagrams on my Sparc IIs running
Sun OS 4.1.1.  Everytime a client tries to send the packet, the write
failes and I get a "Message too long" error.  I've tried "write" and "send"
(after doing connects of course) and using "sendto" and I always get
the same error.  I am essentially using the code for internet Ping from
section 11.2 of Stevens book except I am not interpreting the header info.
The same code that works for TCP and UDP doesn't work for ICMP.  Any ideas
would be greatly appreciated?
Shikhar

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 20:37:16 GMT
From:      nickh@wotk.UUCP (Nick Hennenfent)
To:        comp.sys.dec,comp.protocols.tcp-ip
Subject:   need licensed DEC LAT info

I need details of how to get licensed DEC LAT for a product
we are building.

Does anyone have a name, address, phone number at DEC?

What are the advantages/disadvantages of using licensed LAT
versus a reversed engineered version from somewhere else?

What other companies provide versions of DEC LAT?
Any recommendations?

Is DEC putting any pressure on companies that use/develop
the reverse engineered versions of LAT?

Thanks for the information.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 21:18:25 GMT
From:      pbd@runyon.cim.cdc.com (Paul Dokas)
To:        comp.protocols.tcp-ip
Subject:   two way RPC??

Please forgive me if this is wrong group, I can't find a more appropriate one...

  What I want to do is have a client and server that talk to each other
through RPC, but I need call-backs.  For example, the client would register
a call-back procedure with the server.  Some time later, the server would
recieve some input that would cause it to tell the client to run the call-back
procedure.  As far as I can tell, this can't be done with standard RPC.

BTW the server is an X application (Motif actually), so I'm already fairly
deep into RPC;  I don't call svc_run(), I use XtAddInput(), etc.

Any ideas?
-- 
+--------------------------+----------------------------+-------------------+
| Paul Dokas               |     Put your favorite      |                   |
| pbd@runyon.cim.cdc.com   |      disclaimer here.      |       Fnord       |
| pbd@power1.cim.cdc.com   |                            |                   |
+--------------------------+----------------------------+-------------------+
| "The heart has its reasons, whereof reason knows nothing." -Blaise Pascal |
+---------------------------------------------------------------------------+

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Feb 1992 21:29:15 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.protocols.tcp-ip
Subject:   Re: PING source wanted

I just wanted to pass on my thanks to all those who responded to my request
for the PING source. I now have it in my possession and am working with it
to resolve a mysterious problem... :-) Other characters, like named.ca and
routed are involved as well, but that's a story for another day.

Again, thank you all.


-- 
  :: Walter R. Trachim              walt@unhsst.unh.edu                     ::
  :: University of New Hampshire -- Telecommunications and Network Services ::
  :: Durham, NH 03824               Voice:(603)862-4742  Fax:(603)862-2030  :: 
   "When you're up to your ass in alligators, it's hard to remember that your
    initial objective was to drain the swamp."  --U.S. Marine Corps Proverb 

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 00:53:16 GMT
From:      scott@labtam.labtam.oz.au (Scott Colwell)
To:        comp.protocols.tcp-ip
Subject:   Is it true that RS/6000s don't adhere to rfc1042 ?

I have heard conflicting stories about IBMs conformance to
rfc1042 for tcp-ip over 802.5 token ring.  One person suggested
to me that there were some incompatibilities between IBMs implementation
and some other parties. This seems odd to me but I have been unable
to verify it.

Do IBM do tcp-ip over token ring as per the rfc or is it different
is some way ?

-- 
Scott Colwell
Labtam Australia Pty. Ltd.	net:	scott@labtam.labtam.oz.au
Melbourne, Australia 		phone:	+61-3-587-1444

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 01:03:33 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Timer in CLOSING state ??

In article <0fzb02jX69L200@amdahl.uts.amdahl.com> suresh@uts.amdahl.com (Suresh Padmanabhan) writes:
>
>- Is implementation of a timer mechanism in CLOSING state, advisable ??
>

In this situation you have sent data (a FIN) for which you have not
received an ACK.  The retransmission timer should still be operating,
and should cause you to retransmit your FIN some number of times, and
then to abort the connection, just as you would if user data went un-ACKed.
A separate timer is unnecessary.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Feb 1992 01:17:15 GMT
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Picking IP numbers (non-Internet)?

Hello, netland:

I'm in a situation where I have to pick IP#'s for a small number
of PC's (<20) which will not be on the Internet (say, for the next
5 years at the earliest) and am wondering if there is some sort
of a standard set of IP#'s reserved for unregistered sites off
the internet, or should I just pick them at random?

OTOH, should I send an application to the NIC for IP#'s even though
these won't be on the Internet, just in case they will be at some
future time?

Any thoughts would be appreciated. Thanx.


-- 
John Hawkinson
jhawk@panix.com

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Feb 92 01:21:06 GMT
From:      mcdowell@exloghou.exlog.com (Steve McDowell)
To:        comp.protocols.tcp-ip
Subject:   Mailing list for IRSG?

Is there a mailing list to follow the goings-on of the 
Internet Research Steering Group? 

Please followup by email.
Thanks.

-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<   

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 08:49:45 PDT
From:      dsroberts@beckman.com
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions

In article <2340004@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
> Your welcome, but next time, try to be a little less inflammatory when you
> ask for help.

Well, I certainly never intended to be inflammatory, and am not sure to what
you refer.  Anyway, by now you've probably seen my followup with specifics. 
Anyway, I guess I'll ask further questions in comp.sys.hp.  Thanks for the
reply.
> 
> Ted Rypma
> HP Panacom Division
> (Speaking, of course, for himself)
-- 
---------------------------------------------------------------------------
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Commercial Unix - An oxymoron
---------------------------------------------------------------------------

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 04:18:18 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions

> > (134.217.247.31 has to be entered as 134.217 247.31)
 ^^^^^^^^^^^^^^      ==              ^^^^^^^^^^^^^^
> How would you like to enter the IP address?

Yowp.. I now see the missing "."   I should go to bed before I go blind.

This looks brain-dead.

Ted Rypma
HP Panacom Division
(Speaking, of course, for himself)
----------

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 07:32:50 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: getperrname() question

Frank@mindlink.bc.ca (Frank I. Reiter) writes:
+---------------
| int getpeername(s, name, namelen)
| int s;
| struct sockaddr *name;
| int *namelen;
| 
| where *namelen is the amount of space pointed to by name.  What is this
| parameter for if name is a pointer to a structure, and hence a constant size?
| /usr/include/sys/socket.h defines sockaddr thusly:
| 
| struct sockaddr {
|     u_short         sa_family;  /* address family */
|     char            sa_data[14];    /* up to 14 bytes of direct address */
| };
| 
| What am I missing here?
+---------------

The system I use most often says *this* in getpeername(2):

	...The namelen parameter should be initialized to indicate the
	amount of space pointed to by name.  On return it contains the
	actual size of the name returned (in bytes). The name is truncated
	if the buffer provided is too small.

That is, getpeername() also overwrites (or may overwrite) the variable "namelen"
(since it was given a POINTER == ADDRESS) with the *exact* value of the
length. In AF_INET, "sockaddr_in" is padded out to be 16 bytes, but it's
certainly *possible* that some day some address family will return a
variable answer.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 09:58:36 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [here sme time ago...]



 >> if you try contacting other machines without being told a
 >> name/address or having an account, it is likely you are misbehaving,
 >> or else causing undue/unwanted traffic...
 
 >Have I read this right? Is this statement really advocating that the
 >appropriate way of disseminating the addresses of people and resources
 >on the network is by word of mouth?


how about by
e-mail, reading a paper, seeing it advertised in a document you've
ftp-d, archie/prospero, unwittingly via NFS/AFS, etc etc

of course i'm not advocating word of mouth - i was saying that george
doesnt need to trawl the DNS to find machine names of people in
edinburgh to run 'talk' to - he could e-mail them first...

if everyone ran a zone transfer prior to running an intersite random
talk, we'd be in serious trouble:-)

he knows this, and he knows that becuase JANET & JIPS are reasonably
organised, he only needs to know the standard organisation mail names
like ed.ac.uk and that most places use
Inital.Lastname aliases for email boxes...

sorry i implied something rather daft...

 jon

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 18:02:22 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP services listing

In article <dem.697406037@nhmpw2>, dem@nhmpw2 (David E. Martin) writes:
|>In article <1992Feb5.202420.12910@src.honeywell.com>
|>pbh@arcturus.honeywell.com
|>writes:
|>>can someone provide me with a more complete listing of TCP/IP
|>>services than can be found in Sun's /etc/services? 
|> 
|>Get RFC 1060 via anonymous ftp from nic.nnsc.net.  This gives the number 
|>assignments for all services registered with ISI.  A new number assignment 
|>document is coming out in a month or so with updated listings. 

I'd recommend getting the most recent statistics on actual
port usage as observed on the NSFNET.  FTP to NIS.NSF.NET
and get, for example, the file NSF92-01.PORTS in the NSFSTATS
directory.  This lists many, many ports, not all of which are
"officially registered" ports.

Aaron

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 11:47:05 GMT
From:      dfk@cwi.nl (Daniel Karrenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Picking IP numbers (non-Internet)?

jhawk@panix.com (John Hawkinson) writes:

>I'm in a situation where I have to pick IP#'s for a small number
>of PC's (<20) which will not be on the Internet (say, for the next
>5 years at the earliest) ...
 
>OTOH, should I send an application to the NIC for IP#'s even though
>these won't be on the Internet, just in case they will be at some
>future time?

I have seen a small number of PCs grow into a few 10s of workstations and
then into a more substantial network. I have seen the administrators of
such networks work after hours to reconfigure each and every host 
when they had to connec to someone else and/or the Internet.

Get an official IP number and save yourself or those coming after you 
lots of potential hassle!

Just my personal wisom, your mileage may vary.

Daniel
-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcsun!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 1992 20:25:22 -0500
From:      wb8foz@mthvax.cs.miami.edu (David Lesher)
To:        comp.protocols.tcp-ip
Subject:   Re: Picking IP numbers (non-Internet)?

..use Internet #'s just_in_case?
. yes...

Except I just haerd Dr. Cerf and others, including Rick Adams,
talk at Com-Net. Midst doubling in volume every 7 months, they're
worried about running out of the 32 bit address range! Not that
there are x many IP sites, but the assignments are not that
efficient.


-- 
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu 
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 14:17:40 GMT
From:      keith@spider.co.uk (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET

In article <1371@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>
>  Moreover, I really wonder about the unsubstantiated claims of
>complexity.  Commercial IP hardware is commercial off-the-shelf (COTS)
>and is very much plug and play.  Yet they seem to be having no end of
>problems.  PSI or UUNET ought to offer to integrate it all for them --
>such would probably be cheaper also if they are having so many
>problems.

First of all, I do not represent the JANET powers-that-be in any
capacity, nor am I am out to defend the CB protocols in any way.
However, I think you have missed the point here.

The problem is not the integration of the IP kit in itself. It is
integrating the IP kit with the large installed base of CB kit, in a
clean way. With all due respect to PSI and UUNET, I doubt they know
s*d-all about CB protocols.

Also, talk of replacing all the CB kit, or getting in external
contractors, greatly over-estimates the amount of money available in
this country for Academic/Scientific/Research activities. The people
who have made JIPS happen have done it because they are commited to
getting it off the ground, and in spite of the limited resources and
centrally-funded support they have been given. (I think the number
of people whose *job* it is to run JIPS can be counted on your fingers.)

All complaints about how slow JIPS is moving to the Secretary of
State for Education, not the hard workers who seem to me to be
making a very thorough job of getting this right.

Keith Mitchell

Spider Systems Ltd.             keith@spider.co.uk	(Until 12/2/92)
Stanwell Street                 zspz01@uk.ac.ed.castle
Edinburgh, Scotland             knm@cix.clink.co.uk
Phone: +44 31-554 9424          keith@unipalm.co.uk	(From 2/3/92)
Fax:   +44 31-554 0649          ...!uunet!mcsun!uknet!{spider,unipalm}!keith

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 92 17:11:01 +1300
From:      cctr127@csc.canterbury.ac.nz (Jason Haar, Network Consultant, CSC)
To:        comp.protocols.tcp-ip
Subject:   X.500 for Domain Name Service?


I don't know if this has been talked about before, but has anyone thought of
incorporating a X500-style hook into DNS?

It seems to me that DNS would be perfect for the job. Something like two new
DNS entries - say DS (Directory Site) to search a given string against all x500
servers, and DE (Directory Entry) to actually query the returned x500 server
for a user. 

I realise that the above sentence may "offend" those who know better, but if
anyone can fill me in on the current state of play...

Cheers

Jason

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 15:33:32 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   Re: Timer in CLOSING state ??

suresh@uts.amdahl.com (Suresh Padmanabhan) writes:

>The scenario is as follows :
 
>A simultaneous CLOSE is initiated by both ends of a TCP connection
>and FIN's are exchanged. The server (which has the problem) goes
>into CLOSING state and awaits an ACK for the FIN, from the remote
>end. Intermittently, this ACK never arrives. Consequently, the
>connection hangs in CLOSING state for ever and prevents the server
>from being restarted (since the internet control block is not freed
>and is still bound to the destination port).
> 
 
>The question is :
 
>- Is implementation of a timer mechanism in CLOSING state, advisable ??

A special timer is not necessary for this case. The FIN should be retransmitted
the same as any other data if it is not acked. If, after retransmitting the 
FIN R2 times, then you locally abort the connection and clean up.

Kurt Matthys
Unisys Corp.

I know you believe you understand what you think I said, but I am not sure you
realize that what you heard is not what I meant.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Feb 1992 16:53:55 GMT
From:      mahmood@freedom.msfc.nasa.gov (Rafique Mahmood)
To:        comp.protocols.tcp-ip
Subject:   TCP benchmark question: anomalous packet size & CPU utilization

I have a set of TCP client (send) and server (receive) programs and a 
set of UDP client (send) and server (receive) program which measures 
the elapse time, user time, system time and the transmit/receive rates. 
I increase the packet size from 100 bytes packet to larger packet sizes.
I calculate the %CPU utilization for each packet size by using three 
different times: 
		100*(user+system time)/elapse time

I ran the benchmarks on Silicon Graphics 4D/120, Sun 4/260,
sparc station 2 workstation, and Decstation 5000.

I got some interesting results, and I have some questions if anyone
can help me.

I used four different vendors machine to benchmark. I have four sets
of result for each machine: TCP send, TCP receive, UDP send, and UDP
receive rates.

******************************************************************
DECSTATION 5000
******************************************************************
TCP RECEIVE RATE

Machines: server - receiver - Decstation 5000
	  client - sender   - sparcstation 2, also tried sun 4/260

QUESTION: for some perticular packet size rate droped significantly , WHY?

Below is the result:
		Packet size	Rate
		--------------------
		100		333333
		200**		 20725
		300		428571
		400		470588
		500		526315
		--		---
		700**		 19650
		
		730		663636
		800**		155339
		--		---
		1000		606060
		1100		594594
		1200**		 12035
		1300		very low rate, did not record it
		1400**		 45901	
		1460		695238
		1500		428571
		2944		594747

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

TCP SEND RESULT:

	Rate looks correct, rate varies from 400000 bytes/sec to 
	733944 bytes/sec. for packet size 100 byte to 4000 byte.

	From 100 byte packet to 1000 bytes packet CPU utilization
        is between 90% to 100% but at 1100 bytes packet CPU utilization
	drops at 32% and less.

   QUESTION: Why at 1100 byte size packet sudden drop in CPU
		utilization?

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

UDP SEND RATE:

	Rate looks ok with CPU utilization between 90 to 100%.
	At 1100 byte packet some packet gets lost within the
	machine before it goes out to ethernet. Once program
	start sending packet more than 1000 bytes packet then sends
	20000 packets and netstat shows it transmits 17000 to
	19000 packets.

  QUESTION: Why and where within the machine packet get lost?

		What can I do to transmit all the packets. 
		Please call me if anyone has any idea.

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

UDP RECEIVE RATE:

	At 100 bytes packet:

	Sparc station sends 20000 packets to Decstation.
	In Decstation netstat shows it received 20000 packets
	but program receives only 1829 packets.
	
	At 200 bytes packet:

	Sparc station sends 20000 packets to Decstation.
	In Decstation netstat shows it received 20000 packets
	but program receives only 200 packets.

 QUESTION: Where and why all these packet get lost?

******************************************************************
SGI 4D/120
******************************************************************
TCP RECEIVE RATE

Machines: server - receiver - SGI
	  client - sender   - sparcstation 2, also tried sun 4/260

QUESTION: for some perticular packet size rate droped significantly , WHY?

Below is the result:
		Packet size	Rate
		--------------------
		100		333333
		200**		 20725
		300		428571
		400		470588
		500		526315
		--		---
		--		---
		--
		--		---
		1000		606060
		1100		594594
		1200**		 12000
		1300		very low rate, did not record it
		1400**		 45901	
		1472		588800
		1500**		very low
		2944		594747

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

TCP SEND RESULT:

	Result looks correct, rate varies from 400000 bytes/sec to 
	733944 bytes/sec. for packet size 100 byte to 4000 byte.

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

UDP SEND RATE:

	OK with constant 96% utilization.
******************************************************************

UDP RECEIVE RATE:

QUESTION:	Rate looks ok but as the packet size varies the CPU 
		utilization fluctuates greatly.
		I need to know why does it fluctuate? On Sparcstation 2
		it is constant. If anyone has any idea please let me know
		immidiately.


********************************************************************
Sun 4/260
******************************************************************

TCP RECEIVE RATE

Machines: server - receiver - Sun 4/260
	  client - sender   - sparcstation 2 

	Result looks correct, rate varies from 400000 bytes/sec to 
	733944 bytes/sec. for packet size 100 byte to 4000 byte.

	But CPU utilization fluctuates greatly. Same test I ran on
	Sparc station 2 where CPU utilization is constant.
	On other vendor's machine either it increased or decreased 
	as packet size varied but why it is fluctuating on this machine?

  QUESTION: If anyone has any idea please call me. I need to know 
	    this immidiately.

******************************************************************
TCP SEND RATE

Machines: server - receiver - sparc station 2
	  client - sender   - Sun 4/260 

	Result looks correct, rate varies from 250000 bytes/sec to 
	634944 bytes/sec. for packet size 100 byte to 4000 byte.

	But CPU utilization fluctuates greatly. Same test I ran on
	Sparc station 2 where CPU utilization is constant. 
	On other vendor's machine either it increased or decreased 
	as packet size varied but why it is fluctuating on this machine?

  QUESTION: If anyone has any idea please call me. I need to know 
	    this immidiately.

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

UDP SEND RATE:

	OK with constant 93% utilization.
******************************************************************

UDP RECEIVE RATE:

QUESTION:	Rate looks ok but as the packet size varies the CPU 
		utilization fluctuates greatly.
		I need to know why does it fluctuate? On Sparcstation 2
		it is constant. If anyone has any idea please let me know
		immidiately.
Thanks.


Decstation and Silicon Graphics gave similer results on TCP receive rate
at almost same packet size (200,700, 1200 etc ). I wonder why?

Sparc station 2 gave the expected resuls on all the tests.  

Rafique J. Mahmood
Phone: 205-544-6475
email: mahmood@freedom.msfc.nasa.gov


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Feb 92 18:39:49 GMT
From:      ratazzie@lonex.rl.af.mil (Paul Ratazzi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Packet Driver for Excelan E-205 Card

Help!  I'm trying to find out if a PD for the Excelan E205 exists, or if
anyone knows whether the E205 is compatible with anything.  One of the 
problems I've run into is that Excelan is now part of Novell, so I don't
know if Novell can provide me with one, or even where/who to call.

Any assistance will be greatly appreciated!

Thanks,
-- 
  E. Paul Ratazzi                           |              ratazzie@rl.af.mil
  Microelectronics Reliability Division     |            COMPMAIL:  e.ratazzi
  Rome Laboratory (USAF/AFSC)               |                  (315) 330-2946
  "Exploring the Invisible Frontier"        |                    DSN 587-2946

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 18:40:11 GMT
From:      dir@lookout.uswest.com (Daniel I. Rosenblatt)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for SCO UNIX

In article <1992Feb5.131157.2530@arizona.edu>, jdc@mojave.ece.arizona.edu (Jo Dale Carothers) writes:
> I need SLIP software that will run on 386 or 486 based PC's that
> are running SCO UNIX.  Does this software exist?  If so, where can
> I find it.

You must have the TCP/IP Runtime package from SCO.
Then, as root, do 'mkdev slip' and answer the questions.
You might also need to do 'mkdev tcp' and/or 'mkdev streams'
The documentation with TCP/IP Runtime will say.

Good Luck.
Dan R

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 19:53:57 GMT
From:      dem@nhmpw2 (David E. Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP services listing

In article <1992Feb5.202420.12910@src.honeywell.com> pbh@arcturus.honeywell.com
writes:
>can someone provide me with a more complete listing of TCP/IP
>services than can be found in Sun's /etc/services? 
 
Get RFC 1060 via anonymous ftp from nic.nnsc.net.  This gives the number 
assignments for all services registered with ISI.  A new number assignment 
document is coming out in a month or so with updated listings. 
 
 
David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-2783
P.O. Box 500; MS 234; Batavia, IL 60510  USA   /  \   E-Mail: DEM@FNAL.FNAL.Gov

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 1992 20:53:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <2340003@hppad.waterloo.hp.com> rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
>> >Welcome to the world of BSD networking... when BSD code sees an ICMP
>> >host unreachable, it is unable to deliver this just to the old socket.
>> 
>> He said "Port Unreachable", not "Host Unreachable".
>> 
>> Unreachable and Network Unreachable, but I seriously doubt that it is so
>> braindamaged that it kills all connections when it gets a Port Unreachable.
>
>Yes it does... check it out.

OK, I did, and it supports my case.

The traceroute command works by repeatedly sending a UDP packet to a random
port, incrementing the time-to-live each time.  It waits for the ICMP Time
Exceeded or Port Unreachable messages to come back; Time Exceeded indicates
that the TTL ran out at a router, and Port Unreachable means it reached the
destination.

In a Sun xterm window, I did a traceroute to the X server.  If Port
Unreachable caused all connections to that host to die, this should have
killed the connection between the Sun and the X server.  But it didn't.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Feb 1992 20:58:05 GMT
From:      billp@ncsa.uiuc.edu (Bill Pottenger)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for SCO UNIX

In article <1992Feb6.184011.5083@cherokee.uswest.com> dir@lookout.uswest.com (Daniel I. Rosenblatt) writes:
>In article <1992Feb5.131157.2530@arizona.edu>, jdc@mojave.ece.arizona.edu (Jo Dale Carothers) writes:
>> I need SLIP software that will run on 386 or 486 based PC's that
>> are running SCO UNIX.  Does this software exist?  If so, where can
>> I find it.
>
>You must have the TCP/IP Runtime package from SCO.
>Then, as root, do 'mkdev slip' and answer the questions.
>You might also need to do 'mkdev tcp' and/or 'mkdev streams'
>The documentation with TCP/IP Runtime will say.
>
>Good Luck.
>Dan R

There is also a PPP/SLIP implementation available from Morningstar.  I've
been told that it works well under SCO unix.  Email to jamey@morningstar.com.
Bill

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 21:40:50 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Is it true that RS/6000s don't adhere to rfc1042 ?

In article <12728@labtam.labtam.oz.au> scott@labtam.labtam.oz.au (Scott Colwell) writes:
>I have heard conflicting stories about IBMs conformance to
>rfc1042 for tcp-ip over 802.5 token ring.  One person suggested
>to me that there were some incompatibilities between IBMs implementation
>and some other parties. This seems odd to me but I have been unable
>to verify it.
>
    I've never had any problems communicating with the IBM PS/2's
    with OS/2-EE and IBM's TCP/IP.  Ditto for the RS/6000 running
    TCP/IP.  Neither do the Cisco routers....as we used one of them
    to connect TCP/IP on E'net to IBM's TCP/IP on T/R.  

    Cisco has different options for TCP/IP on T/R....once we set
    that right, no problems.

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 21:43:18 GMT
From:      jjr@cdffp.uucp ( Joe Rackelmann )
To:        comp.protocols.tcp-ip
Subject:   encrypted telnet

I have heard of an encrypted telnet that would prevent a "Sniffer"-like
program from seeing sensitive info travel across tcp/ip (such as
passwords, payroll/personnel info, etc).
Does anyone know if an encrypted telnet is available? 
Is there source I can get or do I need to contact a vendor?
I would like it in a 386/486 SVR4 or SCO UNIX/Xenix flavor.
Thanks for any info ...
-- 
Time takes time.
Joe Rackelmann     California Department of Forestry and Fire Protection
Phone # (916) 653-9960   jjr@cdffp   csusac!sactoh0!siva!cdffp!jjr

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 92 21:53:50 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In comp.protocols.tcp-ip, article <g3u089g@sgi.sgi.com>,
  vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
< 
< Now, all of this may not apply to STREAMS implementations.  But what sort
< of performance do they get?  (Then too, I don't see how a qfull indication
< from a DLIP link level driver is going to make it back up thru the UDP and
< IP mux's to the right stream head.)
< 
If the mux has a decent strategy for picking the next block to send
downstream (simple round-robin seems sufficient as a first approximation),
then obviously only the part that is sending too many packets will be
affected because its upper-level queue will be full first.

Assuming, that is, that you have enough Streams buffers. Experience says that
in every implementation there's always at least one piece of code which
will ultimately crash your machine because it couldn't allocb() something it
needs.

< Most UNIX systems have only 1 link level queue per device.  If one data
< source saturates that queue, what should happen to other sources?  What can
< you do but discard all traffic while the link level queue (consisting of
< both the hardware and software queues) is full?
< 
If you can't block the user process (maybe because there isn't any, if
you're forwarding packets), the only recourse is indeed to throw away the
packet, and maybe to send a source quench ICMP back if you think that would
make sense. I doubt, however, that things like spray would deign to listen to 
you.

However, it should be possible to make forwarding behave reasonably
(i.e neither throwing away every forwarded packet nor blocking the local
processes indefinitely) under such conditions. It might be difficult to
arrive at a reasonable mapping of IP semantics (quality of service and
priority) to Streams semantics, assuming that your Streams implementation
has any in the first place, but as far as I know, the BSD socket code isn't
too concerned about that either.

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Feb 1992 03:11:43 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Packet Driver for Excelan E-205 Card

In article <1992Feb6.183949.11349@lonex.rl.af.mil> ratazzie@lonex.rl.af.mil (Paul Ratazzi) writes:

   Help!  I'm trying to find out if a PD for the Excelan E205 exists, or if
   anyone knows whether the E205 is compatible with anything.

They have their own packet drivers (not part of the formerly Clarkson, now
Crynwr Packet Driver Collection).  I offered to write one, but they weren't
interested.

No, it's not compatible with anything.

   One of the problems I've run into is that Excelan is now part of
   Novell, so I don't know if Novell can provide me with one, or even
   where/who to call.

Excelan's Ethernet card business got sold to Federal Technology, which
is now called Microdyne.
--
--russ <nelson@sun.soe.clarkson.edu> I'm proud to be a humble Quaker.
Peace is not the absence of war.  Peace is the presence of a system for
resolving conflicts before war becomes necessary.  War never creates peace.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Feb 1992 04:28:34 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for SCO UNIX

In article <1992Feb5.131157.2530@arizona.edu>
	jdc@mojave.ece.arizona.edu (Jo Dale Carothers) writes:
>I need SLIP software that will run on 386 or 486 based PC's that
>are running SCO UNIX.  Does this software exist?  If so, where can
>I find it.

SCO provides a SL/IP with their TCP/IP package, but it isn't
particularly wonderful.  You don't have any sllogin capability;
it is intended for a permanent, direct line -- which is kind of
stooopid because if the machine is nearby you'd probably run
Ethernet and if the machine is distant you either need dialup
capability (not there) or you are already spending kilobucks on
a leased line and a few more sheckels on a router is no biggie.

If you are looking for a dialup SL/IP for SCO UNIX, I'd urge you
to check out the Morning Star PPP package.  (Yes, SL/IP is in there
too.)  They support SCO UNIX.  Note that I have not run the package
myself -- my favorable opinion comes from looking through their
manuals, talking with the engineers there, and knowing somebody
who owns and raves about their Sun implementation.  I don't know
how good their SCO version is, but my sense from email discussions
is that they are putting A+ effort into the product, so it's
probably pretty alright.

Their support folks can be reached at <support@morningstar.com>.  That
possibly isn't the right place for product inquiries -- but they seem
like friendly folks and would route an email request to the appropriate
place if required.

-- 
Chip Rosenthal  512-482-8260  |  Percentage of Americans who think
Unicom Systems Development    |  oatmeal is made of wheat:  48%
<chip@chinacat.Unicom.COM>    |    -Harper's Index

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Feb 1992 07:47:15 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <kp382oINN4k6@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> In article <2340003@hppad.waterloo.hp.com> rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
> >> >Welcome to the world of BSD networking... when BSD code sees an ICMP
> >> >host unreachable, it is unable to deliver this just to the old socket.
> >> 
> >> He said "Port Unreachable", not "Host Unreachable".
> >> 
> >> Unreachable and Network Unreachable, but I seriously doubt that it is so
> >> braindamaged that it kills all connections when it gets a Port Unreachable.
> >
> >Yes it does... check it out.
> 
> OK, I did, and it supports my case.
> 
> The traceroute command works by repeatedly sending a UDP packet to a random
> port, incrementing the time-to-live each time.  It waits for the ICMP Time
> Exceeded or Port Unreachable messages to come back; Time Exceeded indicates
> that the TTL ran out at a router, and Port Unreachable means it reached the
> destination.
> 
> In a Sun xterm window, I did a traceroute to the X server.  If Port
> Unreachable caused all connections to that host to die, this should have
> killed the connection between the Sun and the X server.  But it didn't.
> -- 
> Barry Margolin, Thinking Machines Corp.
> 
> barmar@think.com
> {uunet,harvard}!think!barmar

Unless BSD does something different when it receives an ICMP:Port
Unreachable for a UDP packet than for a TCP packet. I would hope that
receiving an ICMP:Port unreachable response for a dud UDP packet would
not cause it to affect any TCP connections, as the ICMP packet would be
sent up to the relevent transport layer before the TYPE of "unreachable" is
really looked at (this is purely guesswork on my part, for what seems a
sensible way to implement the passage of received ICMP packets to the
relevent piece of code - I've never seen the BSD code). Is there any way
to fudge the receipt of an ICMP packet for a TCP connection? I am fully
aware that the "usual" thing to do is send a RST segment, but my code
seems much cleaner when the checks for various infractions that might
result in me sending an ICMP response occur before the oportunity to
construct the RST segment. At least it seems I'm only being unusual, not
broken!

BTW, what is your opinion on the correct response to receipt of IP
packets with IP version == 0? Should I conform with RFC 1122, and drop
them silently, or be "liberal in what I receive" and accept them? Put
better, what might break if I remove the check for IP version number?



Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 08:24:20 GMT
From:      news@sunfse.ese.lmsc.lockheed.com (news)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP setup questions

I didn't view those questions as inflammatory, maybe your abit sensitive
cause you have to address them more than you'd like to? Industry standards
and conventions evolve out of necessity - if HP doesn't care to follow them
and forces a person to change they way they deal with different platforms
(ie SUN, Apollo, HPXXXX) shouldn't ruffle your feathers. I think all of
us systems types would LOVE to sit down at any vendors UNIX machine and know
the same commands and directories will work the same! Till then - you need to
get thicker skin - cause that was not a flame.

Steve

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Friday, 7 Feb 1992 15:56:19 EST
From:      <MARK@wvnvm.wvnet.edu>
To:        bit.listserv.ibmtcp-l,comp.protocols.tcp-ip
Subject:   LPD/LPR Problem with TCP/IP v1.2



 Has anyone experienced this problem ?



I have not had any luck in using LPR (under OS2 2.0 LA and TCP/IP 1.2)
and specifying the binary option to send a binary file to a PC running
FTP Software's "LPD"
For some reason the LPD software from FTP software does
not recognize the binary option from the OS/2 machine which executed the LPR
command.  This can be verified by enabling the debug option on the LPD machine
Has anyone else had this problem or know of a fix for the problem.

Is this just a protocol problem with FTP and IBM using different protocols
since there is no recognized standard at this time ?
The binary option works if both machines are running the same company's
software (PC using FTP's LPR to PC running FTP's LPD or IBM's LPR to
IBM's LPD)

The solution would be to change the LPD machine and run OS/2 2.0 with
TCP/IP 1.2, but we are trying to make use of some older PC's by using
them as local LPD servers and attaching HP Paintjet/XL's

We are expecting the new version of TCP/IP in anyday now, will this fix
the problem ?

           Thanks !

           Mark Flugrath
           IBM Systems Programmer
           WVNET
           Morgantown, WV
           304-293-5192

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 12:05:40 GMT
From:      cudep@warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET

In article <1371@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>  From listening to the JNT folks justifying their inaction it sure
>sounds as if networking in the UK is mostly driven by personal
>connections and politics.

The appearance of IP has been driven almost entirely by user pressure.
It should have happened a long time ago IMHO, but you don't sound like
you know how it's all finally happened.

>  I haven't heard anyone from JNT ask the original poster if he'd
>be willing to help with the conversion/testing.  It seems like a 
>logical thing to do if the goal is to get IP working.  

It *IS* working.  It *IS* already a service, not a test.

>  Moreover, I really wonder about the unsubstantiated claims of
>complexity.  Commercial IP hardware is commercial off-the-shelf (COTS)
>and is very much plug and play.  Yet they seem to be having no end of
>problems.

Blanket statement.

>  PSI or UUNET ought to offer to integrate it all for them --
>such would probably be cheaper also if they are having so many
>problems.

I doubt it could be done much cheaper.

>just reaction from a disinterested observer...

So disinterested so as not to observe what you're talking about, it seems :-(
-- 
\/ato                                                         if (!take(joke))
Ian Dickinson - NIC handle: ID17                                  em = fork();
vato@csv.warwick.ac.uk  ...!mcsun!uknet!warwick!vato
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 17:30:07 EST
From:      jagx@vax5.cit.cornell.edu
To:        comp.protocols.tcp-ip
Subject:   public domain TCP/IP

Our lab is setting up a VAX 3500 on the network and we require 
TCP/IP.  Does anyone know if there are public domain versions of
TCP/IP available, where we could one, etc...  
  In advance, thanks for your help.
   Patti Grandoni

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 14:24:14 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET

In article <1992Feb6.141740.11809@spider.co.uk> keith@spider.co.uk (Keith Mitchell) writes:

   (I think the number of people whose *job* it is to run JIPS can be
   counted on your fingers.)

Close, but no cigar as they say. The staff employed by JIPS can be
counted on the number of thumbs on one hand. The other folk working on
JIPS are doing it in addition to their regular job - like running the
JANET/Internet mail gateway or looking after the comms. kit on a
campus or administering a bunch of machines.

		Jim

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 20:39:28 MDT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem w/ICMP:Port Unreachable

	Gee, I hope I haven't violated a rule, but in MS-DOS Kermit v3.12
(not out yet) I inserted code to send an ICMP "port unreachable" response
when a UDP pkt arrives and the UDP code says no_such_port. This allows
Traceroute to bang on my machine without disrupting other activities. After
all, I surmize, it's to a UPD port I don't have active so why should it
clobber any other UDP port (or any TCP connection for that matter)? It also
seems to be wise given the qty of lost Sun's out there looking for a victim
to stand up and be recognized (RPC stuff gone astray).
        If I have this all wrong now would be a good time to set me straight.
	Joe D.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 15:52:05 GMT
From:      sr71@cbnewse.cb.att.com (michael.a.frank)
To:        alt.dcom.telecom,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   GOSIP


I'm presently taking a course on ISDN, and our instructer wants us 
to get information on on the Government Open Systems Interconnection
Profile (GOSIP).  I thought the folks reading the the telecom digest
might be of help to me.  I'm looking for general information on
GOSIP,as well as the defining specifics and how ISDN requirements 
have been included.  One last final thing,  Great Britain has a 
form of GOSIP, and any information concerning its differences with
GOSIP would be most helpful.  Thanks in advance.

Mike Frank # AT&T Bell Laboratories # Naperville, IL # ihlpb!tank # 708-979-5040

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Feb 1992 17:03:23 GMT
From:      james@col.hp.com (James Kahkoska)
To:        comp.protocols.tcp-ip
Subject:   KA9Q testimonials?

We are considering using KA9Q but are concerned about it's 
reliability and performance. Are there other people out there that have 
used KA9Q in a commercial product? The perception around here is that
it will be a support nightmare.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 20:24:03 GMT
From:      mats@devildog.att.com (Matt Szela)
To:        comp.protocols.tcp-ip
Subject:   traceroute pgm


Does anyone know (I am sure someone does!!!) how could I get a hold
of the source code (or binaries if src is not available) of the
traceroute program ???

This program was written by Van Jacobson and helps to determine
routes that packets take to some IP destination.

Please send responses to me directly or post it here on this group.

Any help on the subject will be appreciated.

Tx,

Matt 

mats@devildog.att.com

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 92 21:27:23 GMT
From:      goldstein@carafe.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over Packet Radio


In article <1992Feb3.152021.6312@titan.tsd.arlut.utexas.edu>, evans@tsd.arlut.utexas.edu (Eric Evans) writes...
>Does anyone out there have experience on this topic?  We have developed a  
>distributed appplication that runs on UNIX hosts on an Ethernet LAN.  The  
>component processes of the application interact via UDP datagrams.  So far so 
>good - this bit works fine.  Now we're considering an extension that would allow 
>some of the application's component processes to reside on "remote" (within a 
>few miles) UNIX hosts, linked via packet radio.  One host would act as an IP 
>router between the Ethernet subnet and the packet radio subnet (the real   
>"ether" net  :-} ).  Preliminary investigation suggests 2 approaches:
> 
>1.Use the KA9Q implementation of TCP/IP.  As we understand it, KA9Q sends
>  IP packets out on the RF link as AX.25 "UI" frames (essentially datagrams)  
>  and doesn't bother with AX.25 virtual circuits.  Packet retransmission is
>  left up to TCP.

Not exactly.  I use the KA9Q NOS program frequenty, though it's not
necessarily easy to find -- it's distributed in source format and
often requires a bit of hacking to get right, since everybody's always
changing _something_.  There are _lots_ of options and compile-in 
features to choose from.  I get a "stable" binary with features I need
from a local redactor.  Anyway, NOS allows virtual circuit or datagramme
operation.  Mode VC means you run the AX.25 LAPB procedures.  Hardly
anybody does this, and it is no panacaea, but I do it on occasion
for grins & chuckles (so I know the packet loss isn't local to me!).

I think the main reasons why people use datagramme mode more often
is religious:  Most TCP/IP radio types don't distinguish between
Level 2 VCs (often good) and Level 3 VCs (religiously bad, which is
why they're using TCP/IP instead of, say, X.25 PLP).
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Feb 1992 21:36:16 GMT
From:      rkh@cbnewsj.cb.att.com (robert.halloran)
To:        comp.protocols.tcp-ip
Subject:   Info on IP for Big Iron?

What hardware is required to support TCP/IP connections
into an IBM mainframe running MVS?  What software packages
exist, either from IBM or third party vendors?  What
functionality is provided?

Replies by e-mail, please.  Thanks.

        Bob Halloran
        AT&T Universal Card
        Jacksonville FL

        rkh@ucs.att.com
Any similarity between opinions stated here and AT&T's 
  corporate opinion are purely coincidental.

"How can you tell a politician is lying?  His lips move..."
        -- M-m-max Headroom
"Read my lips - no new taxes" -- George H. W. Bush, 1988


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 92 02:33:56 GMT
From:      davis@shasta.mps.ohio-state.edu ("John E. Davis")
To:        comp.protocols.tcp-ip
Subject:   kermit and cutcp

Hi,

  Do mskermit and the cutcp programs know enough to go through a specified
gateway to get to the nameserver?  I don't think so.  Whenever I specify the
host in terms of its numerical hostname I have no problems connecting.
However  if I specify the hostname as, say amy.tch.harvard.edu, both packages
attempt to look it up through the name server but fail to connect.  Of course
I can telnet to the nameserver through the use of its numerical hostname so
the connection can be made-- it requires going through the gateway.  Hence I
conclude that both kermit and cutcp fail to try to reach the nameserver via
the gateway.  Am I correct in this conclusion or have I misconfigured
something improperly somewhere.  Incidently, the ftp program from FTP
software has absolutly no problem resolving a hostname through the same gateway
and the same nameserver as I specified to kermit and cutcp.

Thanks,
--John E. Davis
amy.tch.harvard.edu

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 92 07:13:34 GMT
From:      cdoucet@mais.hydro.qc.ca (cdoucet)
To:        comp.protocols.tcp-ip
Subject:   gost process on TCP/IP

i am running an Oracle database under sco Unix 3.2.2 and using SQL*NET TCP/IP
 
   If a user get trown out(PowerFailure,computer crash) the TCP/IP process stays
 there for ever, i have to go kill it manually..
 
is there anything that look for those process and kill them when they are idle?
 
Thanks in advance
Christian Doucet

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1992 07:23:32 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem w/ICMP:Port Unreachable

In article <1992Feb7.203928.52496@cc.usu.edu> jrd@cc.usu.edu (Joe R. Doupnik) writes:
>	Gee, I hope I haven't violated a rule, but in MS-DOS Kermit v3.12
>(not out yet) I inserted code to send an ICMP "port unreachable" response
>when a UDP pkt arrives and the UDP code says no_such_port.

No, you haven't violated a rule.  This is precisely what ICMP Port
Unreachable is intended to be used for.

The preceding discussion has been about sending Port Unreachable for
nonexistent *TCP* ports.  TCP already has a mechanism to notify the client
of this, so Port Unreachable is superfluous.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Feb 1992 21:55:11 GMT
From:      woks4000@mailszrz.zrz.tu-berlin.de (Wolfgang Ksoll)
To:        comp.protocols.tcp-ip
Subject:   Re: Is it true that RS/6000s don't adhere to rfc1042 ?

In article <12728@labtam.labtam.oz.au> scott@labtam.labtam.oz.au (Scott Colwell) writes:
>I have heard conflicting stories about IBMs conformance to
>rfc1042 for tcp-ip over 802.5 token ring.  One person suggested
>to me that there were some incompatibilities between IBMs implementation
>and some other parties. This seems odd to me but I have been unable
>to verify it.
>
>Do IBM do tcp-ip over token ring as per the rfc or is it different
>is some way ?
>
I do not know the contents of RFC 1042, but if you like the statistical
approach I can tell you in what PC environment my RS/6000 runs in the TCP/IP
world:
- PC/TCP from FTP Inc. on MS-DOS and PC-DOS
- Novell Netware 3.11 with NFS
- TCP/IP on OS/2 from IBM
- TCP/IP in AIX 1.2.1 
- LAN Workplace.
You may believe that they all violate RFC 1042, but they do what they should
in communication with AIX 3.1.5.
Enjoy,


Wolfgang Ksoll           woks4000@mailszrz.zrz.tu-berlin.de
DATA SERVICE Berlin, Ansbacher Strasse 16, W-1000 Berlin 30, Germany
Phone: +49 (030) 219 007 - 32 FAX: - 39


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 92 23:58:53 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q testimonials?

> James Kahkoska writes:
> 
> We are considering using KA9Q but are concerned about it's
> reliability and performance. Are there other people out there that have
> used KA9Q in a commercial product? The perception around here is that
> it will be a support nightmare.

rsoft.bc.ca (the network which hosts mindlink.bc.ca) maintains it's connection
to the internet through an MSDOS based machine running KA9Q.  We've had it
running as long as 6 weeks without a reboot and have never seen a problem with
it.  We push a full news feed and approximately 800 pieces of mail through it
every day.

Frank.
--
___________________________________________________________________
Frank I. Reiter                UUCP:  ...!van-bc!rsoft!frank
Reiter Software Inc.       INTERNET: frank@mindlink.bc.ca (prefered)
Surrey, British Columbia             frank@rsoft.bc.ca

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Feb 1992 04:41:11 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.modems
Subject:   FAQ - TCP/IP PC <-> modem <-> sun using slip / ppp

I've seen several postings regarding parts of the process of connecting
a PC to a unix box involving slip / fast modems / routing etc.

I have a PC,  a copy of PC/TCP 2.05 (+ pkt drivers), a sparcstation and
will soon get a 19.2K modem (+V.42bis).  I would like to be able to dial up our
computer centre (Xyplex terminal server),  log into my sun and then
do something like ?slattach? after which I would have services such as
telnet / rlogin / ftp etc. available to me from my PC.  Is that how it
works ?

Has anyone compiled any instructions on how to install this setup and use it ?
Is PPP a more efficient variant of SLIP or are they apples and oranges ?
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 92 08:59:13 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Proposed RFC 931 revision available as Internet draft

A new Internet draft, draft-bernstein-idserver-00.txt, is available in
the directory nri.reston.va.us:internet-drafts. This draft may be of
interest to the Internet community since it proposes a revision of RFC
931, the Authentication Server (now renamed the Identity Server), the
only wide-area TCP security service for which implementations are freely
available for use at hosts both inside and outside the United States,
and perhaps the only available tool for tracing system crackers across
the Internet.

Use of RFC 931 has grown dramatically in recent months. More than twice
as many packets for port 113 crossed the backbone in January 1992 as in
November 1991. Server implementations are now available for all the most
popular BSD-derived UNIX systems. The wuarchive ftpd, now used at many
Internet archive sites, supports RFC 931. I have a list of more than 200
sites running the server. The rfc931-users mailing list discusses a
broad range of relevant topics; to join, send mail to
rfc931-users-request@kramden.acf.nyu.edu.

I requested in June 1991 that my revision become a Proposed Standard
protocol, eventually to become a recommended Standard protocol if there
is no objection from the community. The SAAG has been discussing this
request since then. Given the speed of their discussion, I think it is
wise for system administrators, security officers, and others interested
in RFC 931 to obtain the Internet draft rather than waiting for the
revision to be published as an RFC.

---Dan

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Feb 1992 10:57:34 GMT
From:      mah@parrot.prv.univie.ac.at (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   Re: gost process on TCP/IP

In article <cdoucet.697533214@tdsb-s>, cdoucet@mais.hydro.qc.ca (cdoucet) writes:
|> i am running an Oracle database under sco Unix 3.2.2 and using SQL*NET TCP/IP
|> 
|>    If a user get trown out(PowerFailure,computer crash) the TCP/IP process stays
|>  there for ever, i have to go kill it manually..
|> 
|> is there anything that look for those process and kill them when they are idle?
|> 

This problem is manifest on several platforms running Oracle. It should
be fixed by Oracle by a configurable keepalive option, I think. That would
solve the problem at least for LANs.

There was a utility called lsof (list open files) posted to the net a while
ago which correlates processes, their open file descriptors and network
connections. It helps in finding the proper pids. It would need massage
for Sco Unix though.

-michael


-- 
Michael Haberler 		mah@ic.co.at,  mah@awiwuw11.bitnet
Internet Consulting
A-1070 Vienna, Austria, Mariahilferstrasse 126
Tel: +43 (1) 961-679 (voice & fax) D-Netz/Cell Tel: +43 (663) 811-056

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Feb 1992 09:53:22 EST
From:      system@convax.iar.nrc.ca (Jim.Jordan)
To:        comp.protocols.tcp-ip
Subject:   Help with LynxOS TCP/IP Setup

Comp.protocols.tcp-ip NewsGroup:			Feb.10/92

	Can anyone offer any advice on configuring TCP/IP for LynxOS ? We are 
currently "on the air" to a local Ethernet network using a Lynx-supplied
Western Digital board and we can access local machines via FTP and TELNET.
Our connection to the outside world and Internet is via a gateway (Cisco box)
to our Computer Center which provides Internet access and a name server.

	The problem seems to be in setting up the configuration files which
would describe the network gateway and nameserver to the network daemon. We
have no experience with set up of these files on Unix and have very little
to work with in terms of documentation and vendor support. LynxOS V2.0 has
some compatibility with UNIX Version V so hopefully this shouldn't be a major
deal.

	I'm not sure if this is the best group to address this question. If not
, where could I direct my posting ?

	Thanks for any help:

							---Jim---

________________________________________________________________________________
Jim Jordan,				Internet: jordan@convax.iar.nrc.ca
Rm.233, Bldg. U-61, FRL			Phone: (613) 998-4809
Institute for Aerospace Research,	Fax:   (613) 952-1704
National Research Council,	
Ottawa, CANADA  K1A 0R6
________________________________________________________________________________

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 09:30:05 GMT
From:      paul@sixcom.it (Paolo Borile)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for AmigaDos ??


Does anybody out there know where I can find a version of TCP/IP
for AmigaDos (R3000 machines) ?
Thanks.


Paul Stephen Borile                     email      : paul@sixcom.it
Villaggio dei Pini                      home office: +39 39 5300-016
22050 Lomagna COMO ITALY                home fax   : +39 39 9909-055
                                        Office     : +39  2 3192-222
Currently w/for :

C.U. S.r.l                                         : +39  2 55180922
Via Sigieri, 10
Milano

--
Paul Stephen Borile                     email      : paul@sixcom.it
Villaggio dei Pini                      home office: +39 39 5300-016
22050 Lomagna COMO ITALY                home fax   : +39 39 9909-055
                                        Office     : +39  2 3192-222

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 12:51:19 GMT
From:      dxe@cassidy (Dan Ellsweig - Network Software)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on IP for Big Iron?

In article <1992Feb7.213616.26710@cbnewsj.cb.att.com> rkh@cbnewsj.cb.att.com (robert.halloran) writes:
>What hardware is required to support TCP/IP connections
>into an IBM mainframe running MVS?  What software packages
>exist, either from IBM or third party vendors?  What
>functionality is provided?
>
>Replies by e-mail, please.  Thanks.
>
>        Bob Halloran
>        AT&T Universal Card
>        Jacksonville FL
>
>        rkh@ucs.att.com
>Any similarity between opinions stated here and AT&T's 
>  corporate opinion are purely coincidental.
>
>"How can you tell a politician is lying?  His lips move..."
>        -- M-m-max Headroom
>"Read my lips - no new taxes" -- George H. W. Bush, 1988

Bob

I have been looking into the various IP offerings from both
Big Blue and other vendors. Here is a quick run-down:

IBM MVS-TCP/IP - 3172 or 3745 ( not available yet ) FEP
Fibronics      - K2000 or K3000 FEP
Interlink      - proprietary FEP
McData         - proprietary FEP


Give me a call or email me and we can talk about the specific
pros and cons of the various IP mainframe offerings. We have
compared them all.....




-- 
*****************************************************************************
Dan Ellsweig    **   Salomon Inc.                     **  dxe@malta.sbi.com
                **   Route 3   East Rutherford, N.J.  **  (201) 896-6162
*****************************************************************************

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 14:49:48 GMT
From:      Thomas.Tornblom@nexus.comm.se (Thomas Tornblom)
To:        comp.protocols.tcp-ip
Subject:   rarpd using SunOS nit.


We're experimenting with booting and running disk-less Sparcstations
through a cisco router. One problem we've come across is a bug in the
boot-proms of the Sparcstations that prevents this (I'm not so sure
Sun regards this as a bug). Anyway, the bug is that the client cheats
and uses the ethernet address of the server that answered the rarp
request as the server to boot from, instad of doing it the proper way
and arp for the address. Clearly this wont work if the server
answering the rarp request is not the server to boot from. In our case
it wont work either as the ethernet address in the rarp reply is not
on the same segment as the client. 

What we would like to test is to cheat back and use the ethernet
broadcast address as source adddress in the rarp reply.
What we need is an implementation of rarpd that uses nit to capture
rarp request packets. We've found a BSD version using bpf, this wont
compile on our suns. I guess it wouldn't be too hard changing this
to use nit, but why re-invent the wheel if someone has done this
already?

Thomas
--
Real life:      Thomas Tornblom           Email:  Thomas.Tornblom@nexus.comm.se
Snail mail:     Communicator Nexus        Phone:  +46 18 171814
                Box 857                   Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 16:47:37 GMT
From:      muppidi@cs.tamu.edu (Sridhar R Muppidi)
To:        comp.protocols.tcp-ip
Subject:   Looking for References on Parallelization of N/W Protocols.


A new project underway at the Texas A&M University involves
implementing a network protocol on a parallel machine (SIMD/MIMD).

Does anyone know of any "hands-on" papers that describe effective
strategies?  I would be very grateful for any kind of references/
information on such kind of work. 

Thanks in advance.

-- Shridhar Muppidi
(muppidi@cs.tamu.edu)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Feb 92 18:52:21 GMT
From:      robelr@ucs.indiana.edu (Allen Robel)
To:        comp.protocols.tcp-ip
Subject:   RFD - Request for discussion of Asynchronous Transfer Mode

                     Request for Discussion:
            New Group to Discuss Issues Surrounding
               Asynchronous Transfer Mode (ATM) 
               
              Followup discussion in news.groups


Hi,

   This is a request to discuss the naming, charter, and location
in the USENET hierarchy, of a group who's focus would be centered
around ATM technology.  Because ATM has the potential to impact
many areas, I am posting this to all of the groups that I feel
would be interested.  These groups include:

comp.multimedia
comp.dcom.lans
comp.protocols.tcp-ip
comp.protocols.appletalk
comp.protocols.iso
comp.protocols.nfs
comp.realtime

If you know of any other groups please let me know.  Since there
are many workstation issues to bat around, maybe those groups
should be included as well?  Also, since ATM started out as a
potential transport for wide area networks, any groups that 
discuss WANs should be notified as well.

MOTIVATION:

Over the course of the past few months, I've seen many signs
that hint at ATM becoming a viable LAN technology in the 
near future (1 to 2 years).  At least one vendor has released
an ATM hub and ATM interface cards for Sun's SparcStations and
DEC's DECStations.  Recently, a consortium of vendors formed
the ATM Forum to develop common implementation specifications
for ATM networks.  These vendors included Adaptive Corp., cisco
Systems, Northern Telecom, and US Sprint.  40 more vendors have
joined the forum, including DEC, Hughs LAN Systems, MCI 
Communications Sun Microsystems, and Ungermann-Bass.  Since
the industry is gearing up for ATM, I feel that users, network
administrators, and network planners should, likewise, begin 
discussing this new technology's potential, its strength's
and limitations, its effect on an organization's structure
(implied by ATM's ability to multiplex voice, video and data),
workstation hardware and OS requirements, protocol requirements,
and anything else that's relevant.  

Maybe the range of topics is too wide?  Or, maybe the synergy of 
lumping everything into one group will be helpful?

So, let's discuss in news.groups for a month or so and see if
we can craft a more formal charter (if there's enough interest).

thanks,

Allen Robel                         robelr@mythos.ucs.indiana.edu 
University Computing Services       ROBELR@IUJADE.BITNET 
Network Research & Planning         voice: (812)855-7171
Indiana University                  FAX:   (812)855-8299

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 19:53:47 GMT
From:      gseales@carroll1.cc.edu (Gregory A Seales)
To:        comp.protocols.tcp-ip
Subject:   User privliges in FTP



	Is there a way to change the default setting, for the user privilages,
 in FTP from, I think it is 644 octal, to something else?  If so, How?

Could any replies for this be directed to:
	
	Paul Wickman
	email: pwickman@carroll1.cc.edu


He doesn't have access to news right now.

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 19:58:49 GMT
From:      mre@pyrps5.eng.pyramid.com (Mike Eisler)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

In article <kp382oINN4k6@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <2340003@hppad.waterloo.hp.com> rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
>>> He said "Port Unreachable", not "Host Unreachable".
>>> 
>>> Unreachable and Network Unreachable, but I seriously doubt that it is so
>>> braindamaged that it kills all connections when it gets a Port Unreachable.
>>
>>Yes it does... check it out.
>
>OK, I did, and it supports my case.
>
>The traceroute command works by repeatedly sending a UDP packet to a random
>port, incrementing the time-to-live each time.  It waits for the ICMP Time
>Exceeded or Port Unreachable messages to come back; Time Exceeded indicates
>that the TTL ran out at a router, and Port Unreachable means it reached the
>destination.
>
>In a Sun xterm window, I did a traceroute to the X server.  If Port
>Unreachable caused all connections to that host to die, this should have
>killed the connection between the Sun and the X server.  But it didn't.

Read the RFC(s?) on ICMP. The icmp unreachable port message contains
the IP packet header of the packet that trigger the ICMP message. This
header of course includes the protocol number (i.e. IPPROTO_UDP,
IPPROTO_TCP, etc.) Thus when a host gets such a message in response to
a packet sent to a bad port, the host has enough information to direct
the ICMP error to the correct protocol, and indeed, if the implementation
worked correctly (most don't), the correct socket bound to the port number
which originated the bad packet.

Most implementations that I've seen treat port unreachable messages the
same as host unreachable messages, and send the error condition to all
UDP sockets on the system that are connected to same host that
generated the ICMP msg. That is if the originating bad packet was of
the UDP flavor.

To reproduce this behaviour, write a program that takes a destination
address and port number from the command line, creates a UDP socket,
connects (using connect()) to the destination, sends (using write())
the packet, sleeps for 30 seconds, and attempts a read (using read()).
Invoke the program twice, with the first invocation going to a good
host/good port, and the second going to the same host but a bad port.
The latter program will as expected get an error on the read,
ECONNREFUSED. The former will (unexpectedly) get ECONNREFUSED as well.

	-Mike Eisler
	mre@pyramid.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 92 21:18:44 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS broadcast address

In article <hanson.696544051@pogo> hanson@pogo.fnal.gov (Steve Hanson) writes:
>>                 You'd think Sun would at least make it easier to 
>>do the right things and not have the OS complain when you do.

In article <10748@eastapps.East.Sun.COM> ckollars@east.sun.com (Chuck Kollars - Sun BOS Software) writes:
>`ifconfig` already does do the right thing without complaining.

I wish I could get ifconfig to set the right values without having to
hardcode the network number into /etc/rc.local .
My machines currently have the following lines in their rc.local:

	#ifconfig -a netmask + broadcast +
	ifconfig le0 netmask 255.255.240.0 broadcast 131.143.31.255

I would have liked a kernel flag (right next to ip_forwarding) to select
which type of broadcasts. Maybe there already is one ? 
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Feb 1992 22:23:27 GMT
From:      omar@osf.org (Mark Marino)
To:        comp.protocols.tcp-ip
Subject:   Where is the new "Acceptable Use" policy document?

Has the new Acceptable Use document been released yet?  I was told that NSFnet
would be releasing it very soon.

Mark


-- 
| No Matter Where You Go, There You Are.                                      |
|                                                                             |
| Mark Marino              | omar@osf.org             | uunet!osf!omar        |
| Open Software Foundation | 11 Cambridge Center      | Cambridge, MA 02142   |

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Feb 1992 23:31:42 GMT
From:      kjpires@iat.com (Kurt J. Pires)
To:        comp.protocols.tcp-ip
Subject:   Does CSLIP (w/o PPP) work between a NetBlazer and an Annex III?

Does anybody know whether an Annex III and a NetBlazer can communicate
with each other using CSLIP?  Has anyone tried?

A secondary question that might help get me an answer to the above question:
Since the Annex III doesn't have PPP, can the NetBlazer's implementation
of Van Jacobson TCP Header Compression (CSLIP) work without PPP?
The manual seems to indicate that the two are completely independently
settable options, but I can't tell without a NetBlazer in hand.

Thanks,
Kurt

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 02:50:20 GMT
From:      panos@tigger.Colorado.EDU (Panos Tsirigotis)
To:        comp.protocols.tcp-ip
Subject:   Re: getperrname() question

In article <gnlch24@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>+---------------
>| int getpeername(s, name, namelen)
>| int s;
>| struct sockaddr *name;
>| int *namelen;
>| 
>| where *namelen is the amount of space pointed to by name.  What is this
>| parameter for if name is a pointer to a structure, and hence a constant size?
>| /usr/include/sys/socket.h defines sockaddr thusly:
>| 
>| struct sockaddr {
>|     u_short         sa_family;  /* address family */
>|     char            sa_data[14];    /* up to 14 bytes of direct address */
>| };
>| 
>| What am I missing here?
>+---------------
>
>The system I use most often says *this* in getpeername(2):
>
>	...The namelen parameter should be initialized to indicate the
>	amount of space pointed to by name.  On return it contains the
>	actual size of the name returned (in bytes). The name is truncated
>	if the buffer provided is too small.
>
>That is, getpeername() also overwrites (or may overwrite) the variable "namelen"
>(since it was given a POINTER == ADDRESS) with the *exact* value of the
>length. In AF_INET, "sockaddr_in" is padded out to be 16 bytes, but it's
>certainly *possible* that some day some address family will return a
>variable answer.
>
>-Rob
>

As far as the original question goes:

The data field length in struct sockaddr is irrelevant. Only the first 
two bytes of struct sockaddr are important, because they determine the 
address family and the rest of the address is interpreted relative to the
family.
There is no requirement that the address be 16 bytes long which is
why in the bind(2) and connect(2) system calls you have to specify
the length of the address.

About what Rob said (very correctly):
An address family where the length of the address is variable
has existed for a long time: AF_UNIX. The address is a pathname 
up to 108 bytes long (which is an ugly implementation detail coming
from the mbuf implementation in the kernel).

Sometimes I think this is a limitation of C: you can't declare a
variable length structure, so people resort to schemes like this:

struct foo
{
	int type ;
	char data[1] ;
} ;

and then malloc a struct foo with as much space as they need.
Maybe the above declaration should look like:

struct foo
{
	int type ;
	char data[*] ;
} ;

But this is a different topic...

Panos

-- 
Panos Tsirigotis, CS grad                        
Pmail: Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309-0430
Email: panos@cs.colorado.edu

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 09:58:41
From:      jrb@vtc::idx.com (Jim Bresee)
To:        comp.protocols.tcp-ip
Subject:   IBM 3090 and TCP/IP

Hi Folks,

We have a need to talk to an IBM 3090. We are running on a VAX using multinet
TCP/IP.  We are told by the IBM folks that you can't talk from CICS (what they
program in) to the TCP/IP driver.

Does anyone have any experience in communicating from TCP/IP on the 3090 to CICS
on the 3090?  Is it possible?

Thanks for any info you can give me!

Jim Bresee

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 05:54:22 GMT
From:      efb@slced1.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Austin Internet Connection and Best Ways

Have a business contact moving to the Austin, TX area and needing
an internet connect for .COM domain.  Any tips on fast ways to 
get connected would be appreciated.  Thank you, /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  +

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 07:36:54 GMT
From:      my@berlioz.nsc.com (Michael Yip)
To:        comp.protocols.iso,comp.multimedia,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Re: Multi-Media Mail Programs

In article <74187@nigel.ee.udel.edu> scoggin@udel.edu () writes:
>Does anyone know of any enhanced mail programs which permit the transfer of
>image and/or sound in X.400 format?  I would prefer something compatible with
>the Sun SPARC / X-Windows environment.

Well, I don't know of any existing multimedia mail program.  But I do
know that Michael Wagnitz, the author of Xmail, is planning to incorporate
images and voice into xmail.  You can reach him thru email at
michael@berlioz.nsc.com.  I think that he is going to put some stubs from
Bellcore for graphics and sound.  The current version works on the Sun
workstations.

-- Mike
-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 14:13:09 MDT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: VT "Escape" Sequences

In article <613@amo.WichitaKS.NCR.COM>, mregeste@amo.WichitaKS.NCR.COM (Mark Regester) writes:
> I am looking for information on the "escape" characters for the
> VT series of terminals.  I have an old list of VT100 commands,
> but I need information on newer terminals, VT102 & VT220.
> 
> I am looking for this information because I think the LAN WorkPlace
> for DOS program, TNVT220, is not working properly.  I am using a
> program called qterm that works with Procomm+ 2.01, and Procomm+
> Network 1.0, but does not work with TNVT220.  The qterm program 
> sends <ESC>[c.  If qterm does not get a response it likes, it then 
> sends <ESC>Z.  Procomm+ responds with <ESC>[?6c.  TNVT220 responds 
> with <ESC>[?62;2;6;8;9c.  Is this extended sequence from TNVT220 
> valid?  Is there a newer version of qterm around?  I have version 
> 3.0 dated 6/30/87.
> 
> Thanks.
> -- 
> Mark Regester Information Systems & Services, NCR Peripheral Products Division
>  NCR:654-8340 <Mark.Regester@WichitaKS.NCR.COM>
> (316)636-8340 <uunet!ncrcom!ncrwic!mark.regester>
>  FAX:636-8889
---------------
	I can help a little here. The response ESC [ ? 6 c  means VT102.
The VT220 response is legal and approved. The "62" part means VT220 mode,
and the other terms are various attributes the emulator supports. The latter
may be very important for some applications. Be aware that the response can 
also be CSI etc rather than ESC [ etc for VT200 and up terminals.
	This information, and more than you ever wanted to know, is available
in several places. The prime sources are the DEC Tech Ref manual sets for
the terminals; $$$. A free cryptic list is that of MS-DOS Kermit, the text
file MSVIBM.VT, on watsun.cc.columbia.edu, directory kermit/a.
        The LWP VT220 emulator is pretty good all around.
	Joe D.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 09:12:54 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for AmigaDos ??

In article <1992Feb10.093005.646@sixcom.sixcom.it> paul@sixcom.it (Paolo Borile) writes:
>
>Does anybody out there know where I can find a version of TCP/IP
>for AmigaDos (R3000 machines) ?

Commodore's AS225 package will do what you want, but it's a "client-only"
implementation (i.e. one can run, say, ftp from the Amiga but one CANNOT
ftp into the Amiga).  Damifino why they did only a partial implementation,
since WIN/TCP on our DOS boxes is a "normal" client/server package.  With
the AS225 one can NFS-mount directories situated on, say, a Sun.

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

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 13:38:22 GMT
From:      dan@dribble.c-mols.siu.edu (Dan Ellison)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SLIP for SCO UNIX

In <1992Feb6.205819.25188@ncsa.uiuc.edu> billp@ncsa.uiuc.edu (Bill Pottenger) writes:

>In article <1992Feb6.184011.5083@cherokee.uswest.com> dir@lookout.uswest.com (Daniel I. Rosenblatt) writes:
>>In article <1992Feb5.131157.2530@arizona.edu>, jdc@mojave.ece.arizona.edu (Jo Dale Carothers) writes:
>>> I need SLIP software that will run on 386 or 486 based PC's that
>>> are running SCO UNIX.  Does this software exist?  If so, where can
>>> I find it.
>>
>>You must have the TCP/IP Runtime package from SCO.
>>Then, as root, do 'mkdev slip' and answer the questions.
>>You might also need to do 'mkdev tcp' and/or 'mkdev streams'
>>The documentation with TCP/IP Runtime will say.
>>
>>Good Luck.
>>Dan R
 
>There is also a PPP/SLIP implementation available from Morningstar.  I've
>been told that it works well under SCO unix.  Email to jamey@morningstar.com.
>Bill

And don't forget about ka9q.  Doesn't require the tcp/ip package,
supports slip and rip and is well developed....

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Admin	  -    	Molecular Science Program SIU-C | 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-7310 	|     

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 13:47:26 GMT
From:      jxr@thumper.bellcore.com (Jonathan Rosenberg)
To:        comp.protocols.iso,comp.multimedia,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Re: Multi-Media Mail Programs

In article <74187@nigel.ee.udel.edu> scoggin@udel.edu () writes:
>Does anyone know of any enhanced mail programs which permit the transfer of
>image and/or sound in X.400 format?  I would prefer something compatible with
>the Sun SPARC / X-Windows environment.

You should check out the Slate system (formerly known as Diamond),
developed by BBN.  One of its developers (Terry Crowley) can be reached
at

	tcrowley@bbn.com

Good luck.

JR

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 14:20:49 GMT
From:      nsb@thumper.bellcore.com (Nathaniel Borenstein)
To:        comp.protocols.iso,comp.multimedia,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Re: Multi-Media Mail Programs

I already replied to John Scogging directly, but since several people
have redirected his query to me, and since Michael Yip's post made an
oblique reference to my software, I figured I should probably reply to
the newsgroups as well.

What follows is a reproduction of my official announcement of Bellcore's
"metamail" software, which may be freely used for any purpose, and parts
of which may indeed be incorporated into the next releases of several
mail reading systems, including xmail and elm.  The metamail
distribution comes complete with patches for these and many other UNIX
mailers, turning them all into MIME-compliant multimedia mail readers.  

The response to metamail has been extremely positive, and many people
have been contributing patches and improvements.  Although what follows
is all still true, you should also be aware that a second version of the
metamail will be available in the very near future.  -- Nathaniel
----------------------------------------------------------------
On behalf of Bellcore, I am happy to announce the availability of the
"metamail" software to the email community.  This package, which is
available free of charge for unlimited use by anyone for any purpose, is
offered in the hope of making multimedia mail more widespread.

					OVERVIEW

The basic idea of "multimedia" electronic mail is to extend email as we
now know it to include many other types of data beyond plain English
text.  In particular, there is no reason, in principle, why email should
not include text in any of the world's languages and character sets, nor
why email should not include pictures, sounds, animations, active
spreadsheets, or any other kind of data that can be stored on a computer.

In recent years, various research systems and even some commercial
products have extended email to include some or all of these
capabilities.  Until recently, however, none of them worked together,
and all of them required whole communities of users to abandon their old
tools en masse in favor of the new tools of a single software vendor.

Recent developments have the promise of changing all of that.  There is
a new proposed standard for the format of multimedia mail, which would
make software from different vendors able to work together smoothly with
multimedia mail, as they do now with plain text mail.  The software
being announced here implements that proposed standard, but takes it a
step further by incorporating it into the existing tools with which
people read mail today, allowing multimedia mail to be adopted in an
evolutionary rather than a revolutionary fashion.

					DETAILS

Metamail is a package that can be used to convert virtually ANY
mail-reading program on UNIX into a multimedia mail-reading program.  It
is an extermely generic implementation of MIME (Multipurpose Internet
Mail Extensions), the proposed standard for multimedia mail formats on
the Internet.   The implementation is extremely flexible and extensible,
using a "mailcap" file mechanism for adding support for new data formats
when sent through the mail.  At a heterogeneous site where many mail
readers are in use, the mailcap mechanism can be used to extend them all
to support new types of multimedia mail by a single addition to a
mailcap file.

The core of the package is a mechanism that allows the easy
configuration of mail readers to call external "viewers" for different
types of mail.  However, beyond this core mechanism, the distribution
includes viewers for a number of mail types defined by the MIME
standard, so that it is useful immediately and without any special
site-specific customization or extension.  Types with built-in support
in the metamail distribution include:

	1.  Plain US ASCII (i.e., English) text, of course.
	2.  Plain text in the ISO-8859-8 (Hebrew/English) character set.  
	3.  Richtext (multifont formatted text, termcap-oriented viewer)
	4.  Image formats (using the xloadimage program under X11)
	5.  Audio (initial "viewer" for SPARCstations)
	6.  Multipart mail, combining several other types
	7.  Multipart/alternative mail, offering data in multiple formats.
	8.  Encapsulated messages 
	9.  Partial & external messages (for large data objects)
	10.  Arbitrary (untyped) binary data 

Other media types and character sets may be easily supported with the
mailcap mechanism, using the provided types as examples/templates.  The
metamail software also provides rudimentary support for the use of
non-ASCII characters in certain mail headers, as described by a
companion document to the proposed MIME standard.

The metamail distribution comes complete with a small patch for each of
over a dozen popular mail reading programs, including Berkeley mail, mh,
Elm, Xmh, Xmail, Mailtool, Emacs Rmail, Emacs VM, Andrew, and others.   
Crafting a patch for additional mail readers is relatively
straightforward.

In order to build the metamail software, a single "make" command
followed by a relatively short compilation will suffice.  Patching your
mail reader is somewhat harder, but can usually be accomplished in less
than an hour if you have the sources at hand.  The experience of beta
testers is that the metamail package can easily be used to get
multimedia mail working with your existing mail readers in less than
half a day.

					AVAILABILITY

To retrieve the file, use anonymous ftp to the machine
thumper.bellcore.com (Internet address 128.96.41.1).  Type "cd pub/nsb".
 In that directory, you will find:

1.  mm.tar.Z -- this is a compressed tar file containing the entire
metamail distribution.  Uncompress it, untar it, and read the top-level
"README" file for further instructions.  Strictly speaking, this is the
only thing you really need to retrieve.

2.  A subdirectory called "samples".  Except for the README file, each
file in this directory is a sample MIME-format message, which can be
used to test your metamail installation.  There is also now a compressed
tar file of this directory, called "samples.tar.Z".

3.  BodyFormats.{ps,txt,ex} -- a copy (in PostScript/text/Andrew format)
of the latest draft of the MIME proposed standard.    This document is
also available as an Internet Draft.

4.  Configuration.{ps,txt,ex} -- a copy (in PostScript/text/Andrew
format) of the latest draft of the Internet informational RFC describing
the mailcap file format.  This document is also available as an Internet
Draft.

A new mailing list has been set up for disucssion of the metamail
software and related issues.  The mailing list is
INFO-METAMAIL@thumper.bellcore.com.  Requests to join the list should be
directed to INFO-METAMAIL-REQUEST@thumper.bellcore.com.

Please feel free to recirculate this announcement as widely as possible.
		-- Nathaniel S. Borenstein <nsb@bellcore.com>
		   Member of Technical Staff, Bellcore

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 14:20:53 GMT
From:      andrey@cco.caltech.edu (Andre T. Yew)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for AmigaDos ??

thad@public.BTR.COM (Thaddeus P. Floryan) writes:

>>Does anybody out there know where I can find a version of TCP/IP
>>for AmigaDos (R3000 machines) ?
 
>Commodore's AS225 package will do what you want, but it's a "client-only"
>implementation (i.e. one can run, say, ftp from the Amiga but one CANNOT
>ftp into the Amiga).  Damifino why they did only a partial implementation,

	Actually you can FTP into your Amiga.  It's really weird having
a passwd file and a passwd program on the Amiga, but you can do it.
You can also rsh into an Amiga.  Plus with the Berkeley sockets library
available, and given enough effort, who knows what one can achieve?

						Andre

	
-- 
Andre Yew                             andrey@tybalt.caltech.edu (131.215.48.100)

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 14:43:47 GMT
From:      rypma@hppad.waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Problem w/ICMP:Port Unreachable

> >	Gee, I hope I haven't violated a rule, but in MS-DOS Kermit v3.12
> >(not out yet) I inserted code to send an ICMP "port unreachable" response
> >when a UDP pkt arrives and the UDP code says no_such_port.
> 
> No, you haven't violated a rule.  This is precisely what ICMP Port
> Unreachable is intended to be used for.
> -- 
> Barry Margolin, Thinking Machines Corp.

Barry's right, this is what Port Unreachable is for...

But IFF you happen to be sending that ICMP Port Unreachable to a host that
did a "connect()" followed by "send()" or "write()" instead of just a
"sendto()" AND that sender also has done another UDP "connect()" to something
on your host (same destination IP address, different port number), it can
expect to get an error on that perfectly OK second UDP "connection", delivered
as a result of the Port Unreachable on the first port number.

An example is tftp with multiple files to be read. When some delays occur in
the remote host with the tftp daemon, and the tftp client goes on to the
next file, a new tftp process will be started to handle the next file. It
is this new tftp process that gets the inappropriate error along with the
first tftp process which should get it.

Ted Rypma
HP Panacom Division
(speaking gibberish on his own, as usual)

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 15:14:16 GMT
From:      fvance@airgun.wg.waii.com (Frank Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on IP for Big Iron?

> In article <1992Feb7.213616.26710@cbnewsj.cb.att.com> rkh@cbnewsj.cb.att.com (robert.halloran) writes:
> >What hardware is required to support TCP/IP connections into an IBM 
> >mainframe running MVS?  What software packages exist, either from IBM 
> >or third party vendors?  What functionality is provided?
> >
> >        Bob Halloran    rkh@ucs.att.com
> 
> I have been looking into the various IP offerings from both
> Big Blue and other vendors. Here is a quick run-down:
> 
> IBM MVS-TCP/IP - 3172 or 3745 ( not available yet ) FEP
                   also BTI ELC2 (much cheaper) or Network Systems boxes
                   (much better)
> Fibronics      - K2000 or K3000 FEP
> Interlink      - proprietary FEP
                   Wrong!  You should hit your salesman over the head if this
                   is what he has told you!
                   The list of interfaces supported by Interlink includes,
                   according to my Interlink Installation Manual:
	ACC: 9310, 9315, or IF-370/DDN
	BTI: ELC2
	IBM: 3172 or 8232
	Interlink: 3722, 3732, or 3742
	Intel: Fastpath
	McData: Linkmaster 6100E
	Network Systems: various boxes
                   In short, any box that uses the CETI, 8232, 1822, or
                   A220 interfaces.

> McData         - proprietary FEP
> 
> Dan Ellsweig    **   Salomon Inc.                     **  dxe@malta.sbi.com
>                 **   Route 3   East Rutherford, N.J.  **  (201) 896-6162
 
-- 
Frank Vance  +1.713.963.2426		Western Geophysical
FrankVance@airgun.wg.waii.com		10001 Richmond Avenue
Fax: +1.713.963.2758			Houston, TX 77042   USA

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 16:08:22 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for AmigaDos ??

thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>>
>>Does anybody out there know where I can find a version of TCP/IP
>>for AmigaDos (R3000 machines) ?
>
>Commodore's AS225 package will do what you want, but it's a "client-only"
>implementation (i.e. one can run, say, ftp from the Amiga but one CANNOT
>ftp into the Amiga).

Actually, an FTP client includes 'server' implementation stuff as your
client requests the apparent 'server' machine to call it back with the
data when transferring files.  So it appears they simply don't include
any server applications, though the server capabilities must exist.

Erick

-- 
----------------------------------------------------------------------------
Erick Engelke			 		       Engineering Computing 
Network Systems Manager 			      University of Waterloo
erick@development.uwaterloo.ca			    (519) 885-1211 Ext. 2965

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 17:07:35 GMT
From:      cokely@gate.nb.rockwell.com (Scott Cokely)
To:        comp.protocols.tcp-ip
Subject:   calendar and subnetting


We had an issue (uh, actually an argument) arise over the use of subnet addresses
on the same physical backbone.  The argument centered around whether it was
possible at all, and to what level of service one could expect.

While using a standard subnet (255.255.255.0), is it a violation of any RFC to
attempt using multiple address ranges on the same physical network?

We have an Apollo network at 129.172.201, a main backbone at 129.172.200, and
a huge volume of Macs that we want to assign the 129.172.202 address block.  To
what extent can the Macs exist on the same physical backbone as the 129.172.200
address machines?

The other issue is that of calendars.  Has anyone proposed a TCP/IP protocol, along
the concept of SMTP/X.400 for calendar sharing programs?  Something like All-In-One
on UNIX networks defined all the way down to the /etc/services level?

thanks in advance.....

-- 
-----------------------------------------------------------------------------
|Scott Cokely       | (714) 833-4760   cokely@gate.nb.rockwell.com          |
|Opinions expressed |-------------------------------------------------------|	
|on USENET are my   |         Speak roughly to your little SUN		    |
|own and are not    |		And boot it when it crashes		    |
|necessarily those  |       It knows that jobs will not get done	    |
|of Rockwell Int.   |           Because the paging thrashes!!		    |
|-------------------|                 Wow!  Wow!  Wow!                      |
|---------------------------------------------------------------------------|
-- 
-----------------------------------------------------------------------------
|Scott Cokely       | (714) 833-4760   cokely@gate.nb.rockwell.com          |
|Opinions expressed |-------------------------------------------------------|	
|on USENET are my   |         Speak roughly to your little SUN		    |

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 18:42:43 GMT
From:      martinh@cac.washington.edu (Martin Hunt)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for AmigaDos ??

In article <5530@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes:
> In article <1992Feb10.093005.646@sixcom.sixcom.it> paul@sixcom.it (Paolo Borile) writes:
> >
> >Does anybody out there know where I can find a version of TCP/IP
> >for AmigaDos (R3000 machines) ?
> 
> Commodore's AS225 package will do what you want, but it's a "client-only"
> implementation (i.e. one can run, say, ftp from the Amiga but one CANNOT
> ftp into the Amiga).  Damifino why they did only a partial implementation,
> since WIN/TCP on our DOS boxes is a "normal" client/server package.  With
> the AS225 one can NFS-mount directories situated on, say, a Sun.
> 
> Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

The AS225 package is a full client/server package.  You can ftp into
an Amiga, rsh and rcp to it, etc.  The only thing lacking is an
NFS server.

-- 

-------------------------------------------------------------------------------
Martin Hunt                            martinh@cac.washington.edu   
Networks and Distributed Computing     University of Washington		  

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 92 19:10:59 GMT
From:      am815@cleveland.Freenet.Edu (Joel Peter Anderson)
To:        comp.dcom.lans.misc,comp.dcom.lans,comp.misc,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Looking for an intelligent token ring NIC

I  am posting this for a colleague, and would be interested in any 
pointers that would help  - please reply either to any of my Email
addresses below, or directly to Dan with snail mail | voice mail.
 
Many  Thanks.
------------
 
Apertus Technologies Inc. of Eden Prairie, Minnesota, a producer
of enhanced communications controllers, is looking for an intelligent
token ring NIC with the following features:
 
- supports 4/16 Mbps token ring speeds,
 
- uses a AT 16 bit ISA bus interface,
 
- supports 9 pin 'D' connectors,
 
- contains LLC on the board,
 
- contains on board RAM with the capability of putting the TCP/IP
protocol stack ON BOARD.
 
 
 
Please call (612) 828-0765 or send information to:
 
^^^^^^^^^   Apertus Technologies, Inc.
^^^^ ^^^^   7275 Flying Cloud Drive
^^^   ^^^   Eden Prairie, MN   55344
^^     ^^
^       ^   Attn: Dan Inderieden
 
--------------------------------------------------------------------------
"..If you own a machine, you are in turn owned by it, and spend your time
serving it...."    The Forbidden Tower, Marion Zimmer Bradley
-------------------------------------------------------------------------
  joela@apertus.mn.org           |GEnie: J.ANDERSON71
  Joel Peter Anderson            |PNET: jpa@pnet51.orb.mn.org
-- 
-------------------------------------------------------------------- 
<Joel Peter Anderson>               |     
Freenet: am815@cleveland.freenet.edu|    Signature under 
 GEnie:J.ANDERSON71                 |      construction.

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 19:23:32 GMT
From:      mregeste@amo.WichitaKS.NCR.COM (Mark Regester)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   VT "Escape" Sequences

I am looking for information on the "escape" characters for the
VT series of terminals.  I have an old list of VT100 commands,
but I need information on newer terminals, VT102 & VT220.

I am looking for this information because I think the LAN WorkPlace
for DOS program, TNVT220, is not working properly.  I am using a
program called qterm that works with Procomm+ 2.01, and Procomm+
Network 1.0, but does not work with TNVT220.  The qterm program 
sends <ESC>[c.  If qterm does not get a response it likes, it then 
sends <ESC>Z.  Procomm+ responds with <ESC>[?6c.  TNVT220 responds 
with <ESC>[?62;2;6;8;9c.  Is this extended sequence from TNVT220 
valid?  Is there a newer version of qterm around?  I have version 
3.0 dated 6/30/87.

Thanks.
-- 
Mark Regester Information Systems & Services, NCR Peripheral Products Division
 NCR:654-8340 <Mark.Regester@WichitaKS.NCR.COM>
(316)636-8340 <uunet!ncrcom!ncrwic!mark.regester>
 FAX:636-8889

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 19:58:59 GMT
From:      asheriff@lucpul.it.luc.edu (Ali Sheriff)
To:        comp.protocols.tcp-ip
Subject:   "Introduction to Internet Protocols", paper ???

Hi I am looking for the paper titled "Introduction to Internet
Protocols". I have the companion paper "Introduction to Administration
of an Internet-based Local Network". I would appreciate any help in
locating this paper.

Thanks.
Ali
(asheriff@lucpul.it.luc.edu)

P.S. You can reply by direct mail or as a reply post, thanks again.
-- 
  |----|  |   |  |---		 /----\   |\  |  |    \   /
    |     |---|  |-	        |      |  | \ |  |     \ /
    |     |   |  |---            \----/   |  \|  |---   |

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 20:24:13 GMT
From:      asheriff@lucpul.it.luc.edu (Ali Sheriff)
To:        comp.protocols.tcp-ip
Subject:   "Introduction to Internet Protocols", paper ???


Hi I am looking for the paper titled "Introduction to Internet
Protocols". I have the companion paper "Introduction to Administration
of an Internet-based Local Network". I would appreciate any help in
locating this paper.

Thanks.
Ali
(asheriff@lucpul.it.luc.edu)

P.S. You can reply by direct mail or as a reply post, thanks again.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 20:43:19 GMT
From:      guyw@knox.uswest.com (Guy Wells)
To:        comp.protocols.tcp-ip
Subject:   Vendor Compliance to Options in RFC 791 and 1122

I have been asked to query "the experts" and find out what sets of
options vendors of IP and ARP are in fact implementing. We here at
Advanced Technologies will be putting together a high-speed link between
an adjunct computer and a digital telephone switch (advanced intelligent
network release 1.0) and no one here is sure what options that the two 
RFCs lay out are implemented, we've asked the vendors, but we never seem
to hook up with the people that really know. Your help would be greatly
appreciated!

One other question: in RFC 1122, an implementation of ARP must provide
some method of flushing the cache, either the unicast poll or some
timeout method. Which is best?

Thanks for the help in advance. Since I don't always get a chance to
read this group, any info directed to guyw@uswest.com would be helpful.

-- 
--
Guy M. Wells <guyw@uswest.com>  Disclaimer: My opinions are mine, no
U S WEST Advanced Technologies  one elses, and certainly not USWEST's!

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 92 20:47:09 GMT
From:      pmaggs@uxh.cso.uiuc.edu (Peter B. Maggs)
To:        comp.protocols.tcp-ip
Subject:   KA9Q autoexec.net for MS DOS?

Does anyone have an autoexec.net file to set up KA9Q for use
with MS DOS on a computer with an ethernet card connected via
a gateway to internet?  If so is it possible you could share it
--or at least the key commands--I don't need your private addresses
of course--with me by email or with this newsgroup?
-
Thanks.
-
Peter B. Maggs                     pmaggs@vmd.cso.uiuc.edu
-

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Feb 1992 23:32:41 GMT
From:      mrs@charlie.secs.csun.edu (Mike Stump)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute pgm

In article <1992Feb7.202403.18412@devildog.att.com> mats@devildog.att.com (Matt Szela) writes:
>Does anyone know (I am sure someone does!!!) how could I get a hold
>of the source code (or binaries if src is not available) of the
>traceroute program ???

You could try the Info Server as documented in comp.sources.wanted for an
immediate answer:

$ telnet charlie.secs.csun.edu 5742
Trying 130.166.2.150...
Connected to charlie.secs.csun.edu.
Escape character is '^]'.
Welcome to info version 2.8, I keep track of all net software, or at least
those important packages people tell me about.

Comments and suggestions to Mike Stump <mrs@csun.edu>.

Type help for help.    Read help to see about regular expression matching.

I currently know of around 2391 packages.

> find traceroute in package
find traceroute in package
Ok...
1 entries (including obsoletes) found.
package:        traceroute
category:       internet
contact:        comp.protocols.tcp-ip
location:       FTP:traceroute.tar.Z@ftp.ee.lbl.gov
description:    diagnostic tool for debugging routing problems
size:           22567
configurer:     Edward Vielmetti <emv@msen.com>
date-entered:   Fri Jan 10 12:56:03 1992

Command completed.
> quit
quit
Ok...
Connection closed by foreign host.
$ 
-- 
If I can get mail to you via a legally registered fully qualified
domain name, you could be on Saturn for all I care.

		-- quote by Bob Sutterfield <bob@MorningStar.Com>

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 00:11:31 GMT
From:      pst@cisco.com (Paul S. Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS broadcast address

Hi Lars,

In an application like yours, where you are just broadcasting to your local
network (as opposed to a directed broadcast),  you might just declare
255.255.255.255 as your broadcast address on all machines.

Remember, routers aren't supposed to forward undirected broadcasts,  so a
global broadcast should always do the right thing.  Thats what I've done for
a number of years and the only time I ran into trouble was when I came across
an old 4.2bsd host that thought that 255.255.255.255 was -1 and refused to set
the address (oh well).

Regards,
Paul

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 07:23:20 CST
From:      bethell@hemlock.cray.com (Andy Bethell)
To:        comp.protocols.tcp-ip
Subject:   Network Firewalls and Connecting to Internet


I understand that there exists a paper/some reference material on 'setting up a
reasonably secure Internet connection', and I also heard that there was a
discussion on network firewalls in this newsgroup about a month ago.

I would be very grateful if someone could point me at a source for this
material so that I can pass it on to someone considering connecting to
Internet.

Many thanks & sorry if this is a FAQ.

AndyB

PS: Sorry if this appears several times, but I am having trouble with newsreaders.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 07:30:54 CST
From:      bethell@hemlock.cray.com (Andy Bethell)
To:        comp.protocols.tcp-ip
Subject:   Network Firewalls and connecting to Internet



I understand that there exists a paper/some reference material on 'setting up a
reasonably secure Internet connection', and I also heard that there was a
discussion on network firewalls in this newsgroup about a month ago.

I would be very grateful if someone could point me at a source for this
material so that I can pass it on to someone considering connecting to
Internet.

Many thanks & sorry if this is a FAQ.

AndyB

PS : apologies if this appears several times - I am having problems with newsreaders

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 02:07:23 GMT
From:      root@rcorco.UUCP (Super user)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Novell, Unix & tcp-ip


Would anyone have experience with TCP-IP to connect a Novell Network
with SCO Unix?

Especially with respect to:	difficulty of installation [especially on
				 the Novell side],
				reliability of operation
				speed and responsiveness of rlogins
				 from novell into the Unix machine
				 [assuming ethernet connections]
				
I have had varied comments as to the ease of installing such a link,
but have spoken to very few with actual hands-on experience.

I would appreciate e-mail responses to:

			clip@rcorsa.uucp
		   	      or
		     uunet!sobeco!rcorsa!clip

I will summarize for the net.

Thanks very much,

Francois Vrana, RCO Consultants [Montreal, Quebec, Canada]

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 16:12:50 -0500
From:      Shikhar Bajaj <sb7c+@andrew.cmu.edu>
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   ICMP over BSD Sockets

Hello all,

    I am trying to send data between two hosts using ICMP over BSD sockets.
The two hosts involved are Sun SPARCstation IIs running SunOS 4.1.1.  For
some reason, the server process never receives any data eventhough
I know that the client has successfully transmitted (confirmed by netstat
and etherfind) it.  The server and client code are basically code are basically
straight out of the IPC primer from Berkeley except that the socket type
is SOCK_RAW and the protocol is IPPROTO_ICMP.

    I've looked at Steven's ICMP example in his ping implementation and I
see some *strange* things.  First, no where are there any port numbers given
the server process does not do any binds.  Am I dense and missing something
or is there is a secret formula for making this work?  Any and all
comments will be greatly appreciated.


Shikhar

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 10:07:04 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for AmigaDos ??

In article <1992Feb11.142053.6915@cco.caltech.edu> andrey@cco.caltech.edu (Andre T. Yew) writes:
>thad@public.BTR.COM (Thaddeus P. Floryan) writes:
|>>Does anybody out there know where I can find a version of TCP/IP
|>>for AmigaDos (R3000 machines) ?
 
|>Commodore's AS225 package will do what you want, but it's a "client-only"
|>implementation (i.e. one can run, say, ftp from the Amiga but one CANNOT
|>ftp into the Amiga).  Damifino why they did only a partial implementation,
|
|	Actually you can FTP into your Amiga.  It's really weird having
|a passwd file and a passwd program on the Amiga, but you can do it.
|You can also rsh into an Amiga.  Plus with the Berkeley sockets library
|available, and given enough effort, who knows what one can achieve?

Well, that's good news!  And if that's true with the current version of
the AS225 package, then I stand corrected and will so advise the person
who mis-informed me.  :-)

Though I'm sure you probably already know this, sources for most (all?) the
BSD networking software suite can be found at ftp.uu.net and gatekeeper.dec.com
(among other places), so it should be interesting to see how far some creative
and industrious person(s) wants to experiment with porting.

I didn't have much difficulty updating the networking software on my 3B1
from the BSD distribution (no NFS support, though, on the 3B1).

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

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 14:33:44 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Subnets and Broadcasting

We have an Ethernet serving a wad of UNIX hosts (SunOS and SCO UNIX).  
It supports a distributed application that currently uses UDP* to 
broadcast messages among its component processes (one per host), all 
bound to a standard port number. We would like to extend this application 
to work over two Ethernets that are connected by an IP router.

QUESTION:  Is there any way to propagate "broadcast" IP packets through 
an IP router - i.e., receive an Ethernet broadcast packet from one  
segment and forward it as a new Ethernet broadcast packet on the other  
Ethernet segment?

How would one set up the subnet addressing, netmasks, IP broadcast
addresses, etc.?

BTW, what are some good references (textbooks, RFCs) for questions 
like this?



* Yes, I know UDP is "unreliable".  The application lives with it.

-------------------------------------------------------------------------
Eric Evans                     evans@titan.tsd.arlut.utexas.edu
Applied Research Laboratory
University of Texas at Austin




-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 14:50:17 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   UDP access via System V TLI


I've been trying to port some code, first implemented on the BSD socket
interface, to the System V Transport Layer Interface (TLI).  The one 
feature I haven't figured out is how to send UDP "broadcast" datagrams 
from a TLI endpoint.

DOES ANYONE OUT THERE KNOW HOW TO DO THIS?

 With sockets, one enables such broadcasts from a given socket with a 
 setsockopt() call, then just sends datagrams with the "broadcast" 
 IP address as the destination IP address.  

 I've tried sending UDP datagrams from a TLI endpoint with the broadcast 
 IP address, but they don't appear to get broadcast.  

 setsockopt() doesn't work for TLI endpoints, which are System V 
 STREAMS-based.  

 I've found no mention of how to accomplish this in the manuals 
 (SCO UNIX) or in a popular text (Stevens, "UNIX Network Programming").


-------------------------------------------------------------------------
Eric Evans                     evans@titan.tsd.arlut.utexas.edu
Applied Research Laboratory
University of Texas at Austin





-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 15:14:43 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Firewalls and Connecting to Internet

In article <1992Feb12.072333.5608@hemlock.cray.com> bethell@hemlock.cray.com (Andy Bethell) writes:
>
>I understand that there exists a paper/some reference material on 'setting up a
>reasonably secure Internet connection', and I also heard that there was a
>discussion on network firewalls in this newsgroup about a month ago.
>
>I would be very grateful if someone could point me at a source for this
>material so that I can pass it on to someone considering connecting to
>Internet.
>
>Many thanks & sorry if this is a FAQ.
>
>AndyB
>
>PS: Sorry if this appears several times, but I am having trouble with newsreaders.


The Feb. 1992 issue of Unix World has an article called "Building
Internet Firewalls".  I haven't read it yet, but it might be useful.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 15:28:17 GMT
From:      cuden@warwick.ac.uk (Dave Williamson)
To:        comp.sys.novell,bit.listserv.novell,comp.protocols.tcp-ip,comp.windows.x
Subject:   eXceed/W,Windows 3.0,LAN WorkPlace for DOS


Hi,

Is anyone successfully running CDC Vista eXceed/W (Version 1.0 PL(4)) X
Window Server over LAN WorkPlace for DOS Version 4.0 TCP/IP Transport?

I'm running both NetWare and LAN WorkPlace using a 3Com 3C503 and all the
latest ODI stuff from ODIUP4.  The problem occurs when starting the X server
using the XDMCP startup mode.  The server will connect to a host using XDMCP
but will freeze during XDMCP negotiation (before starting an xlogin).  This
happens most of the time but occasionally the X server will start up ok.  I
installed Patch Release 1 for LW4D but this made no difference.  I've also
tried tweaking most of LW4D's configuration parameters but with no success.
Once running, eXceed/W seems pretty robust over LW4D.

Any ideas greatly appreciated

Cheers

Dave
-- 
Dave Williamson, Computing Services, Warwick University, Coventry CV4 7AL, UK
INET:	cuden@warwick.ac.uk		JANET:	cuden@uk.ac.warwick
Phone:	+44 203 523059			Fax:	+44 203 523267

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 15:34:08 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: VT "Escape" Sequences

In article <613@amo.WichitaKS.NCR.COM> mregeste@amo.WichitaKS.NCR.COM (Mark Regester) writes:
> Procomm+ responds with <ESC>[?6c.  TNVT220 responds 
> with <ESC>[?62;2;6;8;9c.  Is this extended sequence from TNVT220 
> valid?

Yes. The response message format is a list of capabilities. Most "real"
vt100s send <ESC>[?1;2c.
-- 
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 17:08:51 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP access via System V TLI

In article <1992Feb12.145017.11308@titan.tsd.arlut.utexas.edu> evans@tsd.arlut.utexas.edu (Eric Evans) writes:
>
>I've been trying to port some code, first implemented on the BSD socket
>interface, to the System V Transport Layer Interface (TLI).  The one 
>feature I haven't figured out is how to send UDP "broadcast" datagrams 
>from a TLI endpoint.
>
>DOES ANYONE OUT THERE KNOW HOW TO DO THIS?

Sending broadcasts on TLI endpoints is about the same as it is on socket
endpoints.  Turn on SO_BROADCAST and send the datagram to a broadcast
address.

SO_BROADCAST can be manipulated using t_optmgmt(3N).  For details of how
this works on an SCO system see intro(ADMP).  Note that options management
is implementation specific, so code that works on an SCO system probably
won't work on all systems, although it should work on all Lachman-based
systems.

The following code fragment may be of use.  It turns on SO_BROADCAST
on a TLI-endpoint (fd).  It's the equivalent of 
setsockopt(fd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on)), although because 
it uses TLI it's 10 times larger and harder to understand :->
The use of OPTLEN and OPTVAL is to cause options to be word-aligned.

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <tiuser.h>
        .
        .
	struct t_optmgmt *opt;
	struct opthdr *ohdr;
	.
	.

	if (!(opt = (struct t_optmgmt *)
	    t_alloc(fd, T_OPTMGMT, T_ALL))) {
		error("Couldn't allocate t_optmgmt");
		t_close(fd);
		return;
	}
	ohdr = (struct opthdr *) opt->opt.buf;
	ohdr->level = SOL_SOCKET;
	ohdr->name = SO_BROADCAST;
	ohdr->len = OPTLEN(sizeof(int));
	*((int *) OPTVAL(ohdr)) = 1;
	opt->opt.len = sizeof(struct opthdr) + OPTLEN(sizeof(int));
	opt->flags = T_NEGOTIATE;
	if (t_optmgmt(fd, opt, opt) < 0) {
		error("Options management failed");
		t_close(fd);
		return;
	}
	/* check returned stuff in opt? */
	t_free(opt);

I hope this is helpful.

-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 18:26:37 GMT
From:      ee91ajh@brunel.ac.uk (Adam J Holt)
To:        comp.protocols.tcp-ip
Subject:   Redirection from a socket.

Does anybody have or know of a program that would redirect calls to, say,
flubbel.rht.lft 3251 to oakland.rht.lft 5162

Please email your response... -ee91ajh@brunel.ac.uk

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 20:17:57 GMT
From:      borella@toadflax.UCDavis.EDU (Mike Borella)
To:        comp.protocols.tcp-ip
Subject:   Frame Relay

I'm looking for any and all info/references on Frame Relay
Please send via email.  If there is a more suitable newsgroup
to discuss this, please let me know.

-Mike Borella
 borella@cs.ucdavis.edu

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 21:17:25 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Encrypted IP

I was scratching my head about the subject of IP-based security and the
problems of working over a subnet that allows other hosts/intruders to sniff
packets (such as ethernet).  It occured to me that there are two very
straightforward approaches, that could be described in a 2 or 3 page RFC if
anyone actually felt like using them.  (I looked through the RFC index and
didn't notice anything dealing with this question in particular -- if this is
all old hat, just chalk it up to Johnny working too hard and ignore this
posting....)

The first is to do encryption at a layer below IP.  One could grab a new
ethernet type code, and have that be for "pre-IP encrypted IP traffic".  A
host receiving such a packet would only have the ethernet addresses upon which
to base its decryption, but you could still implement some scheme with, say,
one DES key per subnet, or one per host, or one per host/host(or router) pair.
This is the most secure method since it makes doing traffic analysis much much
harder.  It would entail coming up with a standard way to do the encryption
that is based on knowing only which two machines a packet is travelling
between (so you'd need different techniques for different kinds of subnets).
Problem: everyone, including your routers, needs to be in on the scheme.

A somewhat simpler (to specify, at least) technique would be to have an IP
Encrypted Data Option.  Packets carrying this option would have their data
portion encrypted according to a key that could depend on the next higher
layer protocol, the IP addresses of both hosts and the contents of the option
field (say, random salt for the encryption), as well as the ethernet (or
whatever) identifiers of the two machines.  This would allow fairly easy
implementation (I guess some kind of SETSOCKOPT( Encrypted ) thing), and would
prevent snoopers from reading people's passwords/file contents in their telnet
and ftp sessions, though it would make traffic analysis much more fruitful.
Plus:  routers that don't know a thing about encryption can still route your
packets.

-Johnny Secure

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 21:24:43 GMT
From:      eli@cisco.com (Steve Elias)
To:        comp.protocols.iso,comp.multimedia,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Re: Multi-Media Mail Programs


check out the Poste email system, 
from alfalfa software in arlington mass.
i think it fills all the requirements mentioned in 
the original posting.

i think you can get more info 
by mailing to info@alfalfa.com

/eli
--

/* eli@cisco.com ; 415 688 4517 */

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Feb 1992 21:48:39 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Summary:  TCP/IP over Packet Radio


These are the summarized responses to the following query I posted last week:

>Does anyone out there have experience on this topic?  We have developed a  
>distributed appplication that runs on UNIX hosts on an Ethernet LAN.  The  
>component processes of the application interact via UDP datagrams.  So far so 
>good - this bit works fine. Now we're considering an extension that would allow
>some of the application's component processes to reside on "remote" (within a 
>few miles) UNIX hosts, linked via packet radio.  One host would act as an IP 
>router between the Ethernet subnet and the packet radio subnet (the real   
>"ether" net  :-} ).  Preliminary investigation suggests 2 approaches:
> 
>1.Use the KA9Q implementation of TCP/IP.  As we understand it, KA9Q sends
>  IP packets out on the RF link as AX.25 "UI" frames (essentially datagrams)  
>  and doesn't bother with AX.25 virtual circuits.  Packet retransmission is
>  left up to TCP.
>
>2.Use SLIP to pass IP packets thru AX.25 virtual circuits.  Does this idea 
>  even make sense?  

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

From nyssa!bob@henson.cc.wwu.edu Tue Feb  4 01:44:25 1992
...
 >1.Use the KA9Q implementation of TCP/IP...

Recent versions of KA9Q's NOS can operate in either datagram mode (as
you describe above) or in virtual circuit mode where IP packets are
sent as AX.25 I frames.  The virtual circuits are automatically
created and torn down.
...
Another advantage of NOS is that you can use it as the router between
the ethernet and the packet radio net.

 >2.Use SLIP to pass IP packets thru AX.25 virtual circuits...

It would be much easier to use virtual circuit mode in NOS.  You might
want to check out the recent versions of NOS on ucsd.edu in
~/hamradio/packet/ka9q.

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

From teb@saturn.ACC.COM Tue Feb  4 08:43:21 1992

 >1.Use the KA9Q implementation of TCP/IP...

A few comments on this paragraph.  First, the AX.25 protocol itself supports
both connection-oriented (essentially HDLC) and connectionless (datagram)
traffic at the AX.25 level, and KA9Q supports both.  So, if reliability is
an issue, packet retransmission can be taken care of at the AX.25 level and
you won't have to do it at the application layer.

The second comment is that KA9Q might not be the best starting point for you.
Terminology is used rather freely in the packet radio world, but strictly
speaking KA9Q refers to a DOS program which implements an entire IP stack.
ACC Systems has done some packet radio work for some government agencies,
and we will soon be making publically available a SunOS AX.25 device driver
which interfaces to the integral IP code in SunOS.  Since the government
paid for all the work we did on this code, it will be free.  At the current
time it only supports datagram mode - the connection-oriented code is there,
but we didn't compile it in or test it since it wasn't a requirement for the
project we were involved in.  Even if the Unix you are using is not SunOS,
it might serve as a good starting point.

 >2.Use SLIP to pass IP packets thru AX.25 virtual circuits...

The "virtual circuits" you mention are the same thing as the connection-oriented
service I mentioned above.  But, there seems to be some confusion about the
protocol layering.  SLIP and AX.25 are at the same level - you tend to use
SLIP when only two stations are involved (strictly point to point), whereas
AX.25 is better suited for "ethers" with more than 2 stations.  AX.25 also
has more hooks for half-duplex operation.

Remember that SLIP isn't reliable, so it may not be as good a choice for you
as AX.25 even with two stations.

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

From kquinlan@cvedg.Prime.COM Thu Feb  6 08:23:10 1992

Is this any use to you? it turned up in rec.radio.amateur.packet
recently.  There is also the "tcp-group" mailing list at ucsd.edu that
deals mainly (but not exclusively) with the KA9Q package.
...
[INCLUDED MESSAGE FOLLOWS:]
-----------
Short description:

  This device driver for the SunOS kernel allows the kernel network
  layer to send IP packet inside AX25 (using a TNC on a serial port),
  exactly like KA9Q NOS does.
  The AX25 device appears exactly (ok, minus possible bugs :-) like
  any other network device does to the kernel, so you can use any old
  regular SunOS TCP/IP programs (ftp, telnet, etc). (Tested on Sun3/60
  and Sun4/260, SunOS4.1.1.)
  VERSION 1.0 deraadt@lego.cuc.ab.ca 


Availability:

   Our SunOS AX.25 IP device driver is now available for anonymous ftp 
   at ucsd.edu in /hamradio/packet/ka9q/incoming/sunos_ax25ip.shar.
   Source and man pages only, it's 46116 bytes.

   I'm also willing to distribute it by email -- just drop me a note
   at uug@cpsc.ucalgary.ca asking for it.

   Author: Theo De Raadt 
	   deraadt@lego.cuc.ab.ca

   Amateur: William Graham  VE6UUG 
	    uug@indigo.cuc.ab.ca 
	    uug@cpsc.ucalgary.ca 
-----------

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

From goldstein@carafe.enet.dec.com Fri Feb  7 21:27:35 1992 

 >1.Use the KA9Q implementation of TCP/IP...

Not exactly.  I use the KA9Q NOS program frequenty, though it's not
necessarily easy to find -- it's distributed in source format and
often requires a bit of hacking to get right, since everybody's always
changing _something_.  There are _lots_ of options and compile-in 
features to choose from.  I get a "stable" binary with features I need
from a local redactor.  Anyway, NOS allows virtual circuit or datagramme
operation.  Mode VC means you run the AX.25 LAPB procedures.  Hardly
anybody does this, and it is no panacaea, but I do it on occasion
for grins & chuckles (so I know the packet loss isn't local to me!).
 
I think the main reasons why people use datagramme mode more often
is religious:  Most TCP/IP radio types don't distinguish between
Level 2 VCs (often good) and Level 3 VCs (religiously bad, which is
why they're using TCP/IP instead of, say, X.25 PLP).



-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 21:50:06 GMT
From:      paul@gmc.austin.ibm.com (Paul Greenspan)
To:        comp.protocols.tcp-ip
Subject:   Re: Is it true that RS/6000s don't adhere to rfc1042 ?

In article <12728@labtam.labtam.oz.au> scott@labtam.labtam.oz.au (Scott Colwell) writes:
>I have heard conflicting stories about IBMs conformance to
>rfc1042 for tcp-ip over 802.5 token ring.  One person suggested
>to me that there were some incompatibilities between IBMs implementation
>and some other parties. This seems odd to me but I have been unable
>to verify it.
>
>Do IBM do tcp-ip over token ring as per the rfc or is it different

Possibly you mean RFC 1122.  Specifically the part on page 31 that says
that a host with a single interface should discard packets not destined 
for themselves.

Paul


-- 
Paul Greenspan                  gmc.austin.ibm.com!paul@ibmpa.awdpa.ibm.com
Locus Computing Corporation,    Austin, Texas
(512) 838-4341,                 FAX: (512) 838-4250

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 92 23:28:01 GMT
From:      Lyle_Seaman@transarc.com
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   HP-UX Ethernet MTU

Does anybody have any idea howcum the Ethernet MTU on all the 
HPUX systems I can find is 1497 bytes?

I was pretty surprised by this.
I guess the lesson is: don't use 'em as routers...

(for the skeptical - run "netstat -i")
Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1992 23:44:39 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Multiple subnets on same cable (was Re: calendar and subnetting)

[Note that I changed the subject so that the two subdiscussions can be
distinguished -- in general, it's best not to put unrelated questions in
one posting.]

In article <1992Feb11.170735.7421@nb.rockwell.com> cokely@gate.nb.rockwell.com (Scott Cokely) writes:
>While using a standard subnet (255.255.255.0), is it a violation of any RFC to
>attempt using multiple address ranges on the same physical network?

Not at all.  Many IP router implementations explicitly support this.  For
instance, cisco routers permit the assignment of "secondary" addresses for
interfaces, so that a single physical interface can have an address on each
logical subnet.

There are some gotchas, but nothing critical.  Communication between the
hosts on different logical subnects will still go through the router, since
the hosts don't realize that they're on the same cable.  And broadcasts
will be received by hosts on all the subnets on the cable (but if they are
sent with subnet-specific broadcast addresses, the receiving IP layers will
probably ignore them -- but there was a discussion recently where it was
suggested that IP should treat all MAC broadcasts as IP broadcasts).
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 92 00:12:47 GMT
From:      mike@isg.llnl.gov (Michael E. Hummell)
To:        comp.protocols.tcp-ip
Subject:   Problem: NCSA 2.3.03 : Orchid VGA card causes lockup upon exiting

My friend was using NCSA Telnet 2.3.03 with no problems
using ega monitor.  Then he got a vga monitor and a "Prodesign VGA" video card
made by "Orchid Technology".

PROBLEM:  He connects ok to a host, but when he logs out, the screen goes 
black, there's one beep, then the PC (a 386 clone) locks up.  Have to
CTRL-ALT-DEL to continue.

I tried replacing his 3COM 503 ethernet board with a Western Digital Elite16
board.  Same problem.

Also, set the "video = vga50"  (instead of "video = ega").  Same problem

Any ideas????

Thanks in advance,  MIKE

-------------------------------------------------------------------------------
hummell@llnl.gov   work: LLNL L-363 POB 808    Livermore,CA 94551 (510)422-3922
                   home: Mike Hummell POB 2121 Livermore,Ca 94551 (510)449-9064 
-------------------------------------------------------------------------------

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1992 14:06:20 -0800
From:      brian@ucsd.edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Encrypted IP

Or just take the IP packet, encrypt it, and encapsulate it in another IP
packet.  IP encapsulation is described in a recent RFC; why not an
encrypted version of it?

Give the boys at No Such Agency a few more hours of work to do...
	- Brian

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 1992 01:07:49 GMT
From:      xxronr@convx1.lerc.nasa.gov (Ron Rivett)
To:        comp.protocols.tcp-ip
Subject:   IBM mainframe - tcp/ip help ?


I am working on a project that involves printing to over 150 different 
printers that are connected to many different types of computers. The main 
systems are: 3 mainframes running VM, MVS, or UTS, 2 VAX Clusters running VMS, 
2 Cray supercomputers, A Convex minisupercomputer, about 350 Unix workstations
that consist mostly of SGI, SUN, IBM RS 6000 workstations and a few Appollo
systems. There are are also about 2,500 PC's. This also involves the following
networks or protocols: TCP/IP, IBM SNA, DEC DECNET, XNS. The IBM VM & MVS 
systems have IBM's version of TCP/IP, and both of the VAX clusters have 
Mulinet's version of TCP/IP.

I do not know very much about the IBM mainframe operating systems VM or MVS, 
or the IBM network protocols or network software, but I would like to know if 
the following concept is possible, and roughly how complicated it would be
to implement. If the concept is feasible, and someone can provide some 
information as to how to go about implementing this concept, then I can 
look into obtaining help from someone with the necessary IBM networking skills
that could then handle the IBM aspects of implementing this concept. 

So, here goes:

I plan to procure many "network print servers", which are small hardware
devices that allow a printer with a Data Products, Centronics, or RS-232
interface to connect directly to an ethernet network. The network print server
communicates with a Unix host via a vendor supplied TCP/IP based program that 
resides on the Unix host. This will allow all of the printers on the campus
to become "network" printers (excluding the few printers that are directly
connected to the IBM MVS system), and to allow a wider choice of printers to be
considered for future planning. 

Many of the users would like to be able to access any of the "network printers"
from their CICS applications as if those printers are part of the IBM mainframe
systems. They would also like to do the same from JCL commands or JES commands
or batch mode (I hope I am using these buzz words correctly).

From what I think I learned about parts of the IBM system software, the lowest
layer between the user/applications level and the regular IBM printers seems 
to be at the VTAM or JES level. I would like to be able to add software at this
level that will allow VTAM or JES to communicate with one or more Unix based
"servers" via a TCP/IP socket program or RPC program.  The intention is to 
allow the MVS or VM users to access any of the TCP/IP network printers
as if they are "IBM devices", but the real connection occurs at something like
the VTAM or JES level, through a socket program, and then to the printers (via
one of several Unix servers).
I would also like to be able to do this without any "patches" to the IBM 
software, and only (famous last words) change IBM system configuration tables,
or "regenerate" the IBM system software. If this involves buying some additional
IBM or 3rd party software, then that is fine (depending on the cost and 
support).

Does this sound feasible ?

Does anyone have any suggestions on how to do the with the IBM systems ?


Please feel free to send anything to me via e-mail, paper mail, or contact
me by phone.


================================================================================
Ronald R. Rivett                            voice: (216) 433-8281
Sverdrup Technology                  Sverdrup FAX: (216) 826-6613
NASA Lewis Research Center          NASA LeRC FAX: (216) 433-8000 
21000 Brook Park Road                      E-mail: xxronr@convx1.lerc.nasa.gov
Cleveland, Ohio 44135 
Mail Stop 142-2               
================================================================================


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 92 03:51:31 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Harvard bridge/router performance tests


Many of you know about the router/bridge performance tests that I do here at 
Harvard every now and then and the fact that they were written up in Data 
Communications mag last year and this year (the Feb issue both years)  Lat 
year, after much discussion, I got Data Comm to agree to allow me to put the 
text of the article out on the net for all to get, even if they don't get Data 
Comm.  That was fine but they did not send me the final edited version until 
more than a month after the article appeared by which time I felt it was too 
late to be posted.  This year they actually sent the text before the article 
hit the streets with a requirement that I wait until now to post it.

If you are not interested in it - now is the time to "n"

Some of you have dealt with getting things published in this type of magazine, 
to those of you who have not - you are missing something you want to miss.  
Everything is done at the very last minute and the product sometimes is only 
vaguely related to what you sent in.  It was about that way with Data Comm, the
just is right but the words are not what I sent them.  At times they seemed to 
have decided that the article was about 30% long so they took out 1 in 3 words 
using a pseudo random number selection algorithm that I've not yet broken.  (I 
sent in 10,133 words - 5,448 were published - I talk too much) Here is an 
example:

--From me: (too many words and more than a bit rambling)
Software versions:
        The versions of the software installed in the tested devices are shown 
in table xx.  These tests were designed generally to categorize the performance
of these internetworking devices rather than to gather "data-sheet"  
information.  In some cases (in about one half of the routers), bugs resulting 
from the load created were uncovered during the testing process.  In all but 
one case the vendors repaired the bug and the device was retested.  The results
of the test with the repaired software are used in this report.  It is expected
that the repaired software will soon be part of the standard distribution for 
these products.  In some cases, the entire test suite was repeated with more 
than one version of the device software. (In these cases the production version
was run along with an advance copy of a new release; as one might expect, the 
"better" result was used.  Note that no partial results were used.  
The vendor's representative chose which software to use and the full 
test results with that software were recorded.)
        Even without taking into account these bug fixes, there is no way to be
sure that normal release  (or pre-release) software was provided for the tests 
without comparing the executables to another set obtained by some other means.
Since both Wandel & Goltermann and Alantec will be retailing the test platforms
with copies of the same test as are run at Harvard, it would not seem to be 
worth the risk for a vendor to cheat.  An independent tester could, at
any time, test production devices.  If the performance of these differed 
significantly from the results achieved at Harvard the resultant negative 
publicity  would far outweigh any benefit gained from "special" software. 
To minimize even this risk, and as the result of discussions with a number
of vendors, participants in future rounds of testing will be asked
to sign a statement declaring that the software used in the tests will
be incorporated into the standard release version within 3 months of the 
test date  (or at the next scheduled release after three months, if the vendor
uses a regular release schedule).

--When they got done: (some of the points but not quite the same message)
The software version used in the tested devices can be found in
the vendor list (see the Vendor Roundup, page 65); some
prereleased code was used. Bugs were discovered during the test  
process in about one-half of the routers; in all but one case,           
the vendors fixed the problem and the device was retested. All 
reported results are for corrected software, which will likely 
soon be part of the standard distribution of these products.     
Since both Alantec (Fremont, Calif.) and Wandel & Goltermann Inc.
(Research Triangle Park, N.C.) plan on selling test platforms
that implement the same tests used in these evaluations, there is  
little likelihood that vendors would risk modifying their devices
just for these particular trials.  

---------

You will have to get the Mag if you want the colorful artwork.  All of the data
is on hsdndev.harvard.edu in pub/rtests/10.91 for anonymous ftp.

Note for those of you who have already grabbed a copy of it, a number of new 
results have been added in the last month.  Including devices tested after 
Interop and in one case, a vendor rented the test lab (now in operation) to 
have their device retested with a new release of their software (which is 
faster than the older version)

Comments to me or the list(s) depending on mood.

Here is the text - not that this is copyright Data Comm. ( a requirement - 
sigh) but you can reproduce it as long as the copyright goes along.

Scott

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

Note:  The following text is copyright 1992 by Data Communications,
permission is hearby given for reproduction, as long as attribution is
given and this notice is included. The article was published in the Feb
1992 issue of Data Communications.

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

tophed
LAB TEST / ETHERNET BRIDGES AND ROUTERS

by
By Scott O. Bradner, Harvard University

hed
Ethernet Bridges and Routers:
Faster Than Fast Enough

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

bio
Scott O. Bradner is a consultant at Harvard University and
designs and develops network-based applications. He is chairman
of the technical subcommittee of the Internet Engineering Task
Force (IETF) Benchmarking Methodology Working Group (BMWG) and
the chairman of the technical committee for Nearnet, the New
England Academic and Research Network.

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

Vendors of Ethernet bridges and routers have good reason to be
proud. Over the past two years, they've gotten the performance of
their products to the point that raw speed is no longer the key
consideration in purchasing decisions.

In fact, tests performed this fall at Harvard University and
published here as part of the DATA COMM Lab Tests reveal that all
of the products evaluated -- totaling more than 20 devices from
16 vendors -- can handle better than 99 percent of the maximum
theoretical throughput of an Ethernet LAN with the largest legal
packets. And when it comes to small packets, virtually all of the
bridges and routers tested can hit 50 percent of the maximum
throughput.

That was hardly the case two years ago, when the fastest router
could only support 90 percent of Ethernet's maximum throughput
with large packets and none could achieve 50 percent saturation
with small frames. For network managers, this means that when
Ethernet performance is impaired, it's generally not going to be
their bridges and routers that are at fault. More likely culprits
will be found in other networking gear (such as slow disks on
file servers) or can be traced to inherent Ethernet limitations.

Of course, without performance as a ready measuring stick,
network managers will have to turn to other criteria when
evaluating products -- among them price, vendor support,
interfaces, security, and ease of use.

Other major findings of this round of tests include:

** Bridges and routers themselves are changing. It's true that
boxes with two and four ports now can deliver unprecedented
performance, but a new generation of bridges and routers is
starting to emerge. Equipped with 10 or more ports, these
multistream newcomers can deliver aggregate effective throughputs
of at least 50,000 packets per second (pps). Two multiport
bridges -- Kalpana's Etherswitch and Synernetics's LANplex 5000
-- and a pair of multiport routers -- Cisco's AGS+ and Alantec's
Power Hub -- are definitely the coming trend in internetworking.

** Router vendors have sharpened their products' protocol-
handling abilities to the point that there's less than 5 percent
difference in the speed with which any box deals with TCP/IP,
Apple's Ethertalk, Digital Equipment Corp.'s DECnet, and Novell's
IPX (among others). (For that reason, only performance results
for TCP/IP are presented.)

** With minor exceptions, the remote performance of Ethernet
bridges and routers is virtually identical. All of the products
evaluated far outstrip the WAN links used to connect Ethernets.

Of course, if speed is no longer the deciding factor among
Ethernet routers and bridges, why publish a performance test at
all -- especially since the results of the Harvard tests were
made available over the Internet? For one thing, these findings
indicate an essential change in the way Ethernet bridges and
routers will be judged and thus are too important to go
unheralded. For another, many vendors have been excerpting and
interpreting the Internet test data in ways that put their
products in the best possible light -- a short-term strategy that
can only hurt the industry. Publishing these results along with
meaningful interpretation enables readers of DATA COMM to make up
their own minds.

HEAVY TRAFFIC

Ethernet LANs accommodate a variety of traffic: Terminals
typically generate small frames, on the order of 64 bytes, while
file transfers usually involve larger ones. Since Ethernet can
theoretically accommodate 14,880 64-byte packets each second,
it's generally not the smaller packets that load down a LAN (64
bytes is the minimum legal Ethernet packet). In fact, it would be
very difficult for a network node or reasonable collection of
nodes to generate that level of traffic. Even the busiest
networks at Harvard only average 400 to 500 pps. And peak
throughput doesn't exceed 4,000 pps.

But at Ethernet's maximum legal packet size of 1,518 bytes, it
takes only 812 pps to fully load a LAN. Today's high-speed file
servers easily can generate extended bursts at this rate. Thus,
it's essential that routers and bridges support Ethernet's full
theoretical load at the largest frame size.

The good news is all but two of the devices tested were able to
handle more than 99.8 percent of the full Ethernet load at the
maximum packet size. And even the two routers that couldn't were
able to handle more than 99.1 percent.
There's further good news: It's extremely unlikely that any
production Ethernet with more than two or three devices will ever
approach these theoretical limits. Ethernet is a collision
detection scheme; all nodes send out data at the same time and
contend for the network. The overhead and delay associated with
settling contention guarantee that real-world throughput will be
nowhere near the theoretical limit.

It's safe to say that as long as a bridge or router linking two
Ethernets can process about 5,000 64-byte pps and handle 730 to
771 1,518-byte pps (90 percent to 95 percent of saturation), it
will not hinder network performance. Bear in mind that processing
requirements grow as the number of LAN connections increases. A
router or bridge that has 10 Ethernet ports should be able to
process 25,000 64-byte packets each second. The multiport
products tested surpassed this speed.

SAFE AT ANY SPEED?

The performance of most of the bridges and routers evaluated was
characterized in terms of maximum reliable throughput. As defined
by Internet standard RSC 1242, this metric defines the highest
speed such devices can sustain without dropping a packet. This
series of tests established single-stream throughput for both 64-
byte and 1,518-byte packets. Since all of the products tested
could handle greater than 99 percent of the theoretical limit for
the maximum packet size, only the throughput for minimum-sized
packets is presented in the following tables and figures.

A different metric, packet loss rate, was used for the
multistream testing of the high-end multiport bridges and routers
from Alantec (Fremont, Calif.), Cisco Systems Inc. (Menlo Park,
Calif.), Kalpana Inc. (Los Gatos, Calif.), and Synernetics Inc.
(North Billerica, Mass.). Packet loss, in effect, determines how
these devices behave under stress. To determine the packet loss
rate, the maximum theoretical throughput for a particular packet
size is sent through the device for 30 seconds and the percentage
of lost packets is recorded. The throughput is then reduced to 90
percent of the theoretical maximum and the test repeated. Maximum
useful throughput was not tested for the high-end devices, since
with multiple streams a single slow stream could yield a low
throughput value that might not be indicative of overall device
performance. Only single-stream results are given for all other
vendors; no bidirectional test information is included.

Finally, the bridges and routers were tested only with adjacent,
or directly connected, Ethernets. That meant the routers did not
have to update their routing tables using such protocols as RIP
(routing information protocol). Nevertheless, router designers
and vendors believe that performance for adjacent LANs is a good
indicator of how a product performs when routing tables are
involved. This round of tests used one protocol at a time. Coming
tests at Harvard will use multiple protocols, as well as multiple
data streams and bidirectional traffic (for more details, see
``Test Methodology'').

LOCAL DUAL-PORT BRIDGES

The local two-port bridge tests examined the MB25E from Cabletron
Systems Inc. (Rochester, N.H.); the HP28673a and HP28681a from
Hewlett-Packard Co. (Palo Alto, Calif.); the PCbridge from
LANport Development Inc. (San Francisco); the 8230 from Newbridge
Networks Inc. (Herndon, Va.); and the LEB-1 from RAD Network
Devices (RND, Rochelle Park, N.J.).

When tested with 1,518-byte packets, all of the local two-port
bridges were able to handle more than 97 percent of the
theoretical maximum load (812 pps). With 64-byte packets, all but
one of these products were able to deal with at least 7,000 64-
byte pps, almost half of Ethernet's theoretical maximum of 14,880
pps with 64-byte packets. The one exception, RND's LEB-1, was a
beta version of a new product. The vendor says the production
version is far faster (see Figure 1).

The two top performers were both from HP. The most surprising
performance was turned in by the Newbridge 8230. By extensively
using surface-mount technology to reduce the size and weight of
its box, the company has managed to pack a lot of power into what
at first looked to be an empty black plastic case.

The field for the remote two-port bridge test consisted of the
HP28674a, the Newbridge 8230, and the RND REB-10. The maximum
packet rates that routers and bridges with WAN connections could
achieve were 120 pps for a 56-kbit/s link and 3,300 pps for a T1
link (using a data rate of 1.536 Mbit/s). Both packet rates are
110 percent of the maximum possible at 56 kbit/s and T1 to allow
for the header compression performed by some devices.

The fastest remote dual-port bridge when tested over a 56-kbit/s
WAN link was the HP 28674a, which was about 20 percent faster
than the rest of the pack (see Figure 2). Since the 120-pps
maximum that a remote bridge can obtain on a 56-kbit/s line is
only about 0.3 percent of an Ethernet, differences between
products would not normally be visible to the user. All of the
devices exhibited virtually identical performance with maximum-
sized packets -- hardly surprising since the rate is largely
determined by the link speed. It should be noted that even though
the dual-port bridges were not tested at T1, some of them offer
this option.

THE FASTEST DEVICES

The most impressive performance was turned in by the high-speed
multiport bridges -- Kalpana's Etherswitch and Synernetics's
LANplex 5000 -- and the top-end multiport routers -- Cisco's AGS+
and Alantec's Power Hub.

The Kalpana, Synernetics, and Alantec products are the first of a
new generation of internetworking devices that move full bridge
or router functions into hub-type architectures. This is a step
beyond the bridge or router cards that can be plugged into a hub.
These new products deliver bridging or routing on a per-port
basis. All three can be configured as multiport bridges, and the
Alantec Power Hub also can be set up as a multiport router. (The
Cisco AGS+, although not designed to replace Ethernet hubs, can
be configured as both a multiport bridge and router.)

Devices like these often are used as central hubs linking
multiple Ethernets in buildings or campuses. Network
administrators claim this configuration delivers excellent
performance and a number of management advantages over LANs
linked by distributed routers connected by an FDDI LAN.

The four devices were tested on their ability to handle six data
streams. In this case, the maximum theoretical throughput with
64-byte packets is 89,280 pps (6:14,880). Three of the four
devices were able to process more than 65,000 64-byte packets per
second, actually outrunning the test setup (see Figure 3). The
Power Hub handled slightly more than 50,000 pps, but when tested
with 1,518-byte packets it could still push through more than 98
percent of six full Ethernets -- a rate of nearly 58 Mbit/s.

Interestingly, when the Cisco and Alantec products were
configured as routers, they turned in virtually the same
performance as the two multiport bridges. Tests conducted with
the Cisco and Alantec boxes configured as bridges revealed that
performance is within 1 percent of stated router performance.

LOCAL MULTIPORT TCP/IP ROUTERS

There were some surprises when it came to the testing of two-,
three-, and four-port local TCP/IP routers: A pair of general-
purpose workstations configured as routers beat their standalone
competition (see Figure 4). The PCroute from LANport and the
Sparcstation II from Sun Microsystems Inc. (Mountain View,
Calif.) both processed more than 10,000 64-byte packets per
second, although it should be noted that the Sun platform was not
all that useful as a workstation while forwarding at this rate.
Still, this is impressive performance. One advantage of working
with PCs configured as routers is that network administrators
don't have to start from scratch with an unfamiliar standalone
unit.

The PCroute was not equipped with WAN interfaces, and the correct
cables for linking the Sparcstation to the wide area were not
available until after the tests, but both systems should be able
to easily route over a WAN link.

The rest of the local TCP/IP routers are more than adequate for
connecting two Ethernets. Note that the performance of the BBN
T/20 is misleading. As reported last year, the T/20 is able to
process 100 percent of Ethernet traffic with frames of 256 bytes
and above (see ``Testing Multiprotocol Routers: How Fast Is Fast
Enough?'' February 1991). The relatively low throughput with 64-
byte packets is the result of a conscious design choice; its
overall ability to forward data is actually better than that of
the other products in this category. It also should be noted that
the 3Com Netbuilder I was tested, not the announced Netbuilder
II. Even though Netbuilder I meets all the requirements of local
IP routing (and does a fine job routing over WAN links), 3Com
claims Netbuilder II is much faster.

LOCAL MULTIPORT TCP/IP ROUTERS

Five routers were evaluated in this category, all with more than
four ports. Each exhibited a throughput of more than 10,000 64-
byte pps and above 99.2 of the theoretical maximum load with a
single stream of 1,518-byte packets (see Figure 5A). A number of
the routers, in one path or another, achieved a throughput of
more than 14,000 64-byte pps (more than 94 percent of the
theoretical limit).  Many of these devices also were tested with
two or more streams -- with equally impressive results. (The
findings of those tests are not presented since testing is not
complete.)

This portion of the tests measured throughput both between the
boards in a device and between ports on the same board. Cisco's
AGS+, the Time/LAN 100 from Timeplex Inc. (Woodcliff Lake, N.J.),
and the CNX 500 from Proteon Inc. (Westborough, Mass.) performed
better between boards; the NSC 6800 from Network Systems Corp.
(Minneapolis) performed better between the ports on one board.

All of the remote TCP/IP routers were able to keep up with 64-
byte traffic over a 56-kbit/s link and with 1,518-byte packets on
a T1 link. The least expensive of the remote routers, the
LANb/280 from Network Application Technology (Cupertino, Calif.),
was somewhat slower with small frames at both WAN speeds (see
Figures 5B and 5C). It did well enough with large frames over T1
to win any price/performance contest. The Cisco AGS+ and IGS and
the Proteon CNX 500 must do some form of header compression,
since they were able to support virtually all of the offered
frames, even though that load was 110 percent of what should be
theoretically carried on the WAN link.

USER CHECKLIST

As the tests indicate, performance is no longer the deciding
factor when purchasing an Ethernet bridge or router. The
following checklist should help network managers trying to
evaluate products:

** Price

** Political issues: Has the purchasing committee or top
management already signed off on a particular vendor?
** Support: Does the vendor offer electronic access to its
support staff? Can software updates be had over the Internet?

** Scale of purchase: If spare units are kept on hand (so-called
local sparing), switching vendors is only worthwhile when enough
new units are needed to make it cost-effective to purchase
required spares.

** Vendor expertise: How well does the vendor track standards?
What committees does it have representatives on? How influential
is the vendor on standards committees? Expertise will show up in
product design and performance.

** Interfaces required: Are the types of needed interfaces
supported?

** Protocol support: Are the requisite protocols supported?

** Security: What filtering options are available? Is it possible
to filter on characteristics of the data stream such as source
and destination address, protocols used, and applications being
executed?

** User interface: How intuitive is the interface? Does the
router require a special terminal for configuration?

** Documentation: Does the vendor provide readable documentation,
including a comprehensive index?

** Network management: Does the product support SNMP? Can it
accommodate MIB II and its extensions for different protocols?
Does it supply adequate tools for troubleshooting, such as
``ping,'' the TCP/IP echo request?

** Uptime: If the router is in a mission-critical appliction,
does it have hot-swappable components and redundant power
supplies?

** Operational characteristics: Can the system image be booted
from across the network or does it have to be loaded manually at
each router? Can new software be remotely downloaded?

FUTURE TESTS

In addition to the ongoing testing activities of the Harvard lab,
a special series of tests concentrating on FDDI and token ring
will be done in time for the Interop 92 spring show. Another
open-invitation series of tests will be run early this fall, and
the results will be published in DATA COMMUNICATIONS. The test
suite will be expanded to follow the recommendations of the
IETF's Benchmarking Methodology Working Group (BMWG) and will
include the measurement of device latency. The BMWG documents are
explicitly promote the development of parallel testing
activities, and it is hoped that other organizations, some with
better resources than the Harvard lab can muster, will join in
the process of quantifying the performance characteristics of
network interconnection devices. All descriptions of the test
setup at Harvard and any Harvard-produced software or testing
scripts will be available over the Internet. The greater the
number of facilities available that implement equivalent testing
procedures, the better it will be for the consumer.


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


Test Methodology
The accompanying article summarizes the results of the fourth
series of performance evaluations of data network interconnection
devices run at Harvard University (Cambridge, Mass.).
Participating vendors consisted of a self-selected group: Some
vendors saw the test announcement that had been posted to an
Internet bulletin board (comp.protocols.tcp-ip). Others read the
DATA COMM Lab Test ``Testing Multiprotocol Routers: How Fast Is
Fast Enough?'' (February 1991) and contacted the lab. Much of
last year's article was devoted to examining conditions on data
networks and the criteria for selecting network interconnection
devices. That information has not been repeated here.

The tests were developed using the guidelines on which the
Benchmarking Methodology Working Group (BMWG) of the Internet
Engineering Task Force (IETF) has been working.

The software version used in the tested devices can be found in
the vendor list (see the Vendor Roundup, page 65); some
prereleased code was used. Bugs were discovered during the test
process in about one-half of the routers; in all but one case,
the vendors fixed the problem and the device was retested. All
reported results are for corrected software, which will likely
soon be part of the standard distribution of these products.
Since both Alantec (Fremont, Calif.) and Wandel & Goltermann Inc.
(Research Triangle Park, N.C.) plan on selling test platforms
that implement the same tests used in these evaluations, there is
little likelihood that vendors would risk modifying their devices
just for these particular trials.

In most cases a vendor representative was present during testing;
this representative configured the router or bridge according to
the test specifications. Routers were set up to enable all
protocols to be tested along with bridge mode, if supported. The
configuration was not modified while the test suite was run. If
the same device was used with more than one interface (for
example, local Ethernet and WAN), it was reconfigured to enable
those interfaces. Specifically, devices could not be reconfigured
between tests to affect the performance with a particular
protocol or packet size.

With many protocols, a router must receive an information frame
of some type from the destination node in order to set up its
internal routing control table. The test equipment was programmed
to supply these frames.

When a bridge receives a frame, it normally forwards it to all of
its ports (flooding) unless it knows the specific port through
which the destination can be reached. The bridge learns the
location of devices by watching the source address field of all
frames on all connected LANs. In order to ensure that the bridge
would operate in nonflooding mode, before each test a frame was
sent with its source address set to the hardware address that
would be used as the destination of the frames in the test
stream.

The Alantec Power Bits, a specialized version of the Alantec
Power Hub configured with automatic testing software, was used to
generate and check the traffic sent through the devices (see
figure). The Power Bits was connected to a pair of Thin Ethernet
transceivers from Cabletron Systems Inc. (Rochester, N.H.) using
the company's AUI transceiver cables. The transceivers were
attached to two separate thin Ethernet networks, one referred to
as the input network and the other as the output network.
Transceivers on each of these networks were connected to ports on
the device under test. When testing WAN devices, two identical
devices were connected using an EL551VX-FT channel/data service
unit (CSU/DSU) from Digital Link Corp. (Sunnyvale, Calif.) in
place of the single device under test. The Power Bits generated
the packets; put an identifying stamp on each; sent them to the
device under test; then checked and verified the packet
information on return. The testing software and a full set of the
test results are available over the Internet (via anonymous ftp
from the node hsdndev.harvard.edu in the directory
pub/rtests/10.91). A Wandel & Goltermann DA-30 LAN/WAN protocol
analyzer was used to verify the accuracy of the Power Bits and as
a LAN analyzer.

The local and remote tests were performed with packets of 64,
128, 256, 512, 768, 1,024, 1,280, and 1,518 bytes; only the
results at 64 and 1,518 bytes are cited. The packet size includes
the frame check sequence (FCS) but not the preamble.

The maximum theoretical rate for each packet size was used. For
the wide-area tests, this was calculated as 110 percent of the
maximum data rate, to allow for the header compression performed
by some devices. The data rate used for T1 was 1.536 Mbit/s.

Maximum Packet Rate

Packet size      56 kbit/s    T1             Ethernet
64 bytes        120 pps       3,300 pps      14,880 pps
1,518 bytes       5 pps         139 pps         812 pps


These tests involved one or more streams of data packets. With
single streams, the packets were transferred from one node
address on one network to a second node address on a second
network. With multiple streams, each stream consisted of a series
of packets, all from the same address, with each addressed to a
node on a separate network. For example, in the six-stream test,
each of the six streams consisted of repeated sequences of six
packets. The first packet in each sequence was addressed to a
node on the first output network, the second frame to a node on
the second output network, and so forth. Only one node address
was used on each input and output network. All addresses were
designed to appear as nodes on adjacent nets (that is, LANs that
were directly connected to the router being tested). Setting up
the addressing in this way eliminated any requirement to supply
actual routing table updates, since routes to adjacent networks
are permanently entered into such tables.

The BMWG draft suggests that multiple, random, nonadjacent
network addresses be used. Future versions of the test will
implement these suggestions.

A number of experiments were performed in order to evaluate the
reliability and repeatability of the test configuration.
Throughput values for a bridge were randomly checked by the W&G
DA-30. The results were within a few percentage points of one
another.

In order to test the tester, a direct connection was made between
the input and output networks and the full test suite run. For
all tests, the maximum theoretical values were obtained.
Throughput was recorded at the theoretical media limit, and the
packet loss test produced no lost packets at any data rate. To
check repeatability, the entire bridge test was repeated nine
times on the same bridge; the routing tests were repeated nine
times on the same router. Within each group of tests, the results
were within one percent of one another.

Devices that supported four or more Ethernet ports also were
tested in a multistream configuration to help determine total
aggregate packet handling. Only the packet loss test was
performed on multiple streams. The Power Bits can generate and
check up to six separate full-rate Ethernet streams.  The input
and output streams were distributed evenly between all interface
boards and, as noted, individual packets in each input stream
were addressed sequentially to each output port to ensure the
most realistic traffic mix.

Internet standards are of two basic types, protocol and
informational. Both are known as Request For Comments (RFCs).

The BMWG has produced one RFC, Benchmarking Terminology for
Network Interconnection Devices (RFC 1242). This defines many of
the parameters that are measured in the tests reported in this
article. The BMWG is now completing a draft for another RFC that
addresses the mechanisms that should be used in the actual
testing.

These tests were performed at the Harvard Network Device Test
Laboratory of the Harvard Office of Information Technology. This
laboratory was established to provide a facility where the
technology required to perform extensive characterization and
simulation tests on various types of data network interconnection
devices could be developed and made available.

A number of vendors have contributed or loaned equipment for use
in the lab, including Alantec, Cabletron, Digital Link, and
Wandel & Goltermann. Proteon Inc. (Westborough, Mass.) supplied
token ring test hardware and software; Timeplex Inc. (Woodcliff
Lake, N.J.) provided Time/LAN 100 Router Bridges with testing
software and FDDI cables.

The lab will be used twice a year for public tests, the results
of which will be presented at Interop and published in DATA
COMMUNICATIONS. The lab is available for use by individuals or
organizations wishing to perform their own performance tests and
to conduct research. The equipment in the lab implements much of
the BMWG test suite and can be used to simulate the protocol and
traffic mix that users would find on their networks. The results
of the tests can be added to the results repository on
hsdndev.harvard.edu or kept private.

For more information on the lab or these tests, please contact
the author via the Internet at sob@harvard.edu.
-- S.O.B.


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


Thanks
A number of acknowledgements must be made in conjunction with
these tests. First, of course, are the vendors that supplied test
equipment -- Alantec, Cabletron, Cisco, Digital Link, Proteon,
and Timeplex. The tests could have never been accomplished
without the hard work of the programmers at Alantec and Proteon.

As in any endeavor of this sort, the first participants wound up
helping with the debugging process. I'd like to thank Earl Veal
of Hewlett-Packard and, particularly, Roger Beeman of Cisco
Systems for the long hours they contributed during the start-up
phase of this round of testing.
 -- S.O.B.

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

Vendor Roundup

BRIDGES
Cabletron Systems Inc.
603-332-9400


Cabletron MB25E
Software version tested: Not applicable
Spanning tree support: yes
Management protocols: SNMP
Interfaces: Ethernet

Hewlett-Packard Co.
800-752-0900


HP28673a 10:10 LAN Bridge MB
Software version tested: C.01.00
Spanning tree support: yes
Management protocols: SNMP
Interfaces: Ethernet, 10Base-2


HP28674a Remote Bridge RB
Software version tested: C.01.00
Spanning tree support: yes
Management protocols: SNMP
Interfaces: Ethernet, 10Base-2, serial from 9.6 kbit/s to T1


HP28681a 10:10 LAN Bridge LB
Software version tested: 8.01.06
Spanning tree support: yes
Management protocols: SNMP
Interfaces: Ethernet, 10Base-2

Kalpana Inc.
408-428-1150


Etherswitch EPS-1500
Software version tested: Not applicable
Spanning tree support: Not applicable
Management protocols: SNMP agent
Interfaces: Ethernet

LANport Development Inc.
415-775-0188


PCbridge
Software version tested: 1.21
Spanning tree support: no
Management protocols: none
Interfaces: Ethernet, async serial from 9.6 kbit/s to 115 kbit/s
Newbridge Networks Inc.
703-834-3600


8230 Ethernet Little Bridge
Software version tested: Release 1
Spanning tree support: yes
Management protocols: SNMP, proprietary
Interfaces: Ethernet, 10Base-T, 10Base-2, FOIRL, frame relay,
serial from 19.2 kbit/s to 2 Mbit/s


RAD Network Devices (RND)
714-891-1446

LEB-1 Local Ethernet Bridge
Software version tested: 0.00 beta
Spanning tree support: yes
Management protocols: proprietary
Interfaces: Ethernet, 10Base-T


REB-10 Remote Ethernet Bridge
Software version tested: 3.02
Spanning tree support: no
Management protocols: proprietary
Interfaces: Ethernet, fiber, serial from 4.8 kbit/s to 2 Mbit/s

Synernetics Inc.
508-670-9009


LANplex 5000
Software version tested: 1.0.0.
Spanning tree support: No
Management protocols: SNMP, Telnet, rlogin
Interfaces: 10Base-T, FDDI

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


ROUTERS

Alantec Corp.
415-770-1050


Power Hub
Software version tested: 1.0
Transport protocols: TCP/IP
Routing protocols: RIP
Bridge Mode: Ethernet transparent, Telnet
Management protocols: SNMP
Interconnect protocols: Not applicable
Interfaces: Ethernet, 10Base-T, 10Base-5

BBN Communications Corp.
617-873-3268


T/20 Internet Router
Software version tested: 1.2
Transport protocols: TCP/IP
Routing protocols: RIP, EGP, SPF, BGP
Bridge mode: no
Management protocols: SNMP, Telnet
Interconnect protocols: X.25, PPP, BBN-Trunk
Interfaces: Ethernet, 4-Mbit/s token ring, serial from 9.6 kbit/s
to 10 Mbit/s

Cisco Systems Inc.
415-326-1941


AGS+
Software version tested: 8.3 beta
Transport protocols: TCP/IP, DECnet IV and V, IPX, XNS, OSI-CLNS,
Appletalk I and II, Apollo Domain, Banyan Vines
Bridge Mode: Ethernet transparent, source routing
Routing protocols: proprietary IGRP, RIP, HELLO, EGP, BGP
Management protocols: SNMP, virtual terminal access via  Telnet
or MOP
Interconnect protocols: HDLC framing, LAP-B, X.25, PPP, frame
relay, SMDS
Interfaces: Ethernet, 4/16-Mbit/s token ring, FDDI, serial from
9.6 kbit/s to 52 Mbit/s


IGS/R
Software version tested: 8.2(5)
Transport protocols: TCP/IP, DECnet IV and V, XNS, IPX,
Appletalk I and II, OSI-CLNP, Apollo Domain, Banyan Vines, PUP,
Chaosnet
Routing protocols: RIP, EGP, IGRP, HELLO, BGP, bridge spanning
tree
Bridge Mode: Ethernet transparent
Management protocols: SNMP, Telnet
Interconnect protocols: X.25, PPP, SMDS, frame relay
Interfaces: Ethernet, serial from 9.6 kbit/s to 4 Mbit/s

Hewlett-Packard Co.


HP 27285A Router ER
Software version tested: V 5.43
Transport protocols: TCP/IP, DECnet IV, Appletalk II, XNS, IPX
Routing protocols: RIP, OSPF, EGP, bridge spanning tree
Bridge mode: Ethernet transparent
Management protocols: SNMP, Telnet
Interconnect protocols: X.25
Interfaces: Ethernet, serial from 9.6 kbit/s to 2 Mbit/s

LANport Development Inc.


PCroute
Software version tested: 2.23
Transport protocols: TCP/IP
Routing protocols: RIP
Bridge mode: bridge/router software available
Management protocols: none
Interconnect protocols: proprietary
Interfaces: Ethernet, async serial from 9.6 kbit/s to 115 kbit/s

Network Application

Technology Inc.
408-733-4530


LANB/280
Software version tested: 1.10
Transport protocols: TCP/IP
Routing protocols: RIP
Bridge mode: no
Management protocols: SNMP
Interconnect protocols: PPP
Interfaces: Ethernet, serial from 9.6 kbit/s to 2 Mbit/s

Network Systems Corp.
612-424-4888


6800 Series
Software version tested: 3.0
Transport protocols: TCP/IP, IPX, DECnet IV, Appletalk II
Routing protocols: RIP, EGP, HELLO
Bridge Mode: Ethernet transparent
Management protocols: SNMP, Telnet
Interconnect protocols: PPP, frame relay, SMDS, DX link
Interfaces: Ethernet, FDDI, serial from 9.6 kbit/s to T3,
Hyperchannel, IBM and Cray Channel, minicomputer, IBM Micro
Channel

Proteon Inc.
508-898-2800


CNX 500
Software version tested: 11.0
Transport protocols: TCP/IP, DECnet IV and V, Appletalk I and II,
XNS, Apollo Domain, IPX, OSI-CLNP
Routing protocols: RIP, OSPF, EGP, IS-IS, bridge spanning tree
Bridge mode: Ethernet transparent, source routing
Management protocols: SNMP, Telnet
Interconnect protocols: X.25, frame relay
Interfaces: Ethernet, 4-Mbit/s token ring, 16-Mbit/s token ring,
FDDI, serial from 9.6 kbit/s to 2 Mbit/s


Sun Microsystems Inc.
415-960-1300


Sparcstation II SS2
Software version tested: 4.1.1B
Transport protocols: TCP/IP
Routing protocols: RIP, EGP
Bridge mode: no
Management protocols: SNMP
Interconnect protocols: SLIP
Interfaces: Ethernet, serial from 9.6 kbit/s to T1

3Com Corp.
800-638-3266


Netbuilder I
Software version tested: 1.1
Transport Protocols: TCP/IP, DECnet IV, IPX, XNS, OSI, Appletalk
II, Banyan Vines
Routing protocols: RIP, EGP, OSPF, IS-IS, bridge spanning tree
Bridge mode: Ethernet transparent
Management protocols: SNMP, Telnet
Interconnect protocols: X.25, PPP, frame relay, SMDS
Interfaces: Ethernet, 10Base-2, serial from 9.6 kbit/s to 7
Mbit/s

Timeplex Inc.
201-391-1111


Time/LAN 100 Router Bridge
Software version tested: 2.1.1
Transport protocols: TCP/IP, XNS, IPX
Routing protocols: EGP, RIP, OSPF, bridge spanning tree
Bridge mode: Ethernet transparent, source routing, SRT
Management protocols: SNMP, Telnet
Interconnect protocols: X.25, DDN, PPP, frame relay
Interfaces: Ethernet, 4/16-Mbit/s token ring, FDDI, serial from
9.6 kbit/s to 2 Mbit/s






-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 92 10:37:55 MDT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Problem w/ICMP:Port Unreachable

In article <2340007@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
>> >	Gee, I hope I haven't violated a rule, but in MS-DOS Kermit v3.12
>> >(not out yet) I inserted code to send an ICMP "port unreachable" response
>> >when a UDP pkt arrives and the UDP code says no_such_port.
>> 
>> No, you haven't violated a rule.  This is precisely what ICMP Port
>> Unreachable is intended to be used for.
>> -- 
>> Barry Margolin, Thinking Machines Corp.
> 
> Barry's right, this is what Port Unreachable is for...
> 
> But IFF you happen to be sending that ICMP Port Unreachable to a host that
> did a "connect()" followed by "send()" or "write()" instead of just a
> "sendto()" AND that sender also has done another UDP "connect()" to something
> on your host (same destination IP address, different port number), it can
> expect to get an error on that perfectly OK second UDP "connection", delivered
> as a result of the Port Unreachable on the first port number.
> 
> An example is tftp with multiple files to be read. When some delays occur in
> the remote host with the tftp daemon, and the tftp client goes on to the
> next file, a new tftp process will be started to handle the next file. It
> is this new tftp process that gets the inappropriate error along with the
> first tftp process which should get it.
> 
> Ted Rypma
> HP Panacom Division
> (speaking gibberish on his own, as usual)
--------------
	You might well be correct in all this. However the specs say (& I do)
attach the incoming headers as returned data. This allows smart recepients to
discover which ports were referenced and thus (fingers crossed) decide which
conversation receives the bad news. Thus one ICMP Port Unreachable message
should not, quoted, disturb other connections.
	Joe D. 

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 92 08:55:16 GMT
From:      raj@hpindda.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   A frag here, a frag there, pretty soon your talking real memory.

Here is another toss-up for the net...

Consider, if you will, IP fragment reassembly. RFC 1122 (#? Host
Requirements Protocol Layers) is of the opinion that unfufilled
fragments should be kept anywhere from 60 to 120 seconds before being
discarded by time-out. Fine. Or is it?

Now, add to your consideration that in 60 seconds, on an Ethernet, it
is possible to receive ~60MBs worth of fragments. Make that 600MBs for
FDDI, and some gawd-awful number for HiPPI, Carrier-Pigeon-on-Speed,
ATM, etc. That's a lot of memory to be sitting around - even by
today's standards.

How might this happen? In just about any fashion - anything from spray
to ttcp could be used to send bunches of fragments. With CPU's being
faster than a speeding Ethernet	and at worst nearly as powerful as an
FDDI, it ain't that tough to overflow outbound queues, and thereby
send just the first fragment of say a six fragment datagram again and
again.

I would like to avoid giving-away all of that memory when someone is
being doubleplusunnice towards my system. How am I to do it? Should I:

	1) Put some limit on the number of fragments in the reassembly
	   queue? If so, how do I handle the overflow - drop the
	   recent arrivals, drop the oldest fragment? I'd rather not
	   be doing much calculation.

	2) Decide that RFC 1122 is being too liberal in what it
	   accepts and select a timeout much smaller - say five or ten
	   seconds? 

	3) Both

	4) Neither - hope that it never happens and systems don't send
	   bogus fragments at me.

inquiringly from the peanut gallery,

rick jones

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 1992 16:26:04 GMT
From:      gwe@cbnews.cb.att.com (george.w.erhart)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   ISO routing via CISCO router

I have the following situation:

                             ----------------
	        ----+--------| CISCO ROUTER |------+-----
	SUBNET1     |        ----------------      |      SUBNET2
		    |                              |
		 UNIX BOX			   PC
		Running StarGROUP		Running DOS/Windows
		3.4 Software			and StarGROUP 3.4 Software
		(LAN Manager Server)		(LAN Manager Client)

The CISCO router is currently routing TCP/IP traffic from SUBNET1 to/from
SUBNET2. The StarGROUP software is based on Microsoft's LAN Manager 1.X
software. This package implements the ISO protocol stack.

My question is, can the cisco route the ISO traffic as well as the TCP/IP
package. 

The cisco manual states that it can do ISO CLNS. The problem is that the
LAN Manager package seems to have no accessable addressing information
as required by the cisco. 

Help!
-- 
George Erhart
AT&T Bell Laboratories
Columbus, Ohio
att!archie!gwe or gwe@archie.att.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1992 18:22:09 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnets and Broadcasting

In article <1992Feb12.143344.11112@titan.tsd.arlut.utexas.edu> evans@tsd.arlut.utexas.edu (Eric Evans) writes:
>QUESTION:  Is there any way to propagate "broadcast" IP packets through 
>an IP router - i.e., receive an Ethernet broadcast packet from one  
>segment and forward it as a new Ethernet broadcast packet on the other  
>Ethernet segment?

In general, there isn't a way to do this.  Cisco routers have a
configuration option that enables it.  You give a specific list of
destination ports that should be forwarded, and then for each interface
through which those packets might be received you can specify an address to
which they should be forwarded (which could be a broadcast address on
another subnet).  And if your routers are also bridges, there's an option
to make use of the spanning-tree data that the bridges use in order to
flood broadcasts throughout your site's network (the spanning tree is
needed to prevent forwarding loops).

Other routers may have similar options.  If you're using a Unix host as a
router, there's no automatic way to do it, though.  You could install a
modified version of the server on these hosts, though; in addition to the
normal processing, it would also forward the broadcast to its other subnet
(you might need to alter the protocol, though, since the IP/UDP source
address won't be the original application-level source).
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 92 19:22:33 GMT
From:      subbarao@wilma.nmsu.edu (Ravi Subbarao)
To:        comp.protocols.tcp-ip
Subject:   Elementary question about telnet session

I have a simple question about telnet sessions. I am guessing that this is
got to do with the tcp/ip protocol involved.

When I try telneting into a remote machine, I have a substantial delay before
the login prompt comes up. After that, the interaction seems regular with
no awkward delays.

But, when I try telneting into the same machine again, I dont get this extra
delay as earlier. Somehow, the path seems straight enough now and the 
session proceeds without awkword delays.

Is there any solid theoretical reason for this, and if so, what is it?

Please send replies to subbarao@nsu.edu

Thanks!

Ravi
Ravi Subbarao    | New Mexico St Univ. Dept 3AT | Internet: subbarao@NMSU.Edu
Network Engineer | Las Cruces NM 88003-0001     | Bitnet:   subbarao@nmsu
                 | Tel: (505) 646-5115          | UUCP:     uunet!nmsu!subbarao
-------------------------------------------------------------------------------

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 1992 19:33:56 GMT
From:      ji@polaris.ctr.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP addresses on a single Ethernet interface

This is a topic that comes up once in a while on comp.protocols.tcp-ip
and other newsgroups. The question is, how to get a machine with one
network interface to respond to more than one IP addresses. 

The other day, a colleague forwarded to me a request from the
namedroppers mailing list for exactly that. Here's my response:

> In article <1992Feb1.082712.18549@mahler.ntt.jp> hitoaki@mahler.ntt.jp (Hitoaki Sakamoto) writes:
>    >In article <216@pivot.sbi.com> jordan@pivot.sbi.com (kuo-lin Hu) writes:
>    > >But it is just out of my curiousity that whether it is possible
>    > >I can assign dual IP addresses to a single controller?
 
>    >No,you can't.
> 
> Is this restriction common among UNIX TCP/IP implementations?
> Has anybody tried to modify this?
> 
> -- Kenji
> --
> Kenji Rikitake 
> kenji@macrofield.or.jp // kenji@macrofield.org // ...!uunet!reseau!kenji 

I have a solution than might suit you.  For my doctoral work (there's
a paper about it in this year's ('91) SIGCOMM, also available for
anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm*.ps.Z), I've
developed what I call the "Virtual Interface" (VIF). To the networking
code, it looks like an interface. It gets ifattach()ed when you open
the /dev/vif* device, and then you can ifconfig it as you like. It
does not have an if_input procedure; it only has an if_output. Packets
that it receives (from higher-level protocols) which have its
IP address, it simply loops back (like any well-behaved if driver).
Packets that it receives that are destined for some other address, it
encapsulates in an encapsulation protocol I call IPIP (IP-within-IP,
protocol number IPPROTO_IPIP == 94), and sends it to another machine
that groks that encapsulation protocol. This feature you won't need,
but here's how to have multiple IP addresses on a machine with a
single real interface:

Let's say your primary interface's IP address is 198.3.2.1, and you
also want it to respond to addresses 198.4.3.2 and 198.5.4.3 (note
that these are three distinct class C addresses in three distinct
class C nets). Here are the ifconfigs:

  ifconfig le0 198.3.2.1 up -trailers	# config primary interface

  ifconfig vif0 198.4.3.2 up 		# config first virtual interface
  route delete net 198.4.3 198.4.3.2	# delete spurious route 
  route add host 198.4.3.2 198.4.3.2 0	# add route for this i/f

  ifconfig vif1 198.5.4.3 up		# config second virtual interface
  route delete net 198.5.4 198.5.4.3	# delete spurious route 
  route add host 198.5.4.3 198.5.4.3 0	# add route for this i/f

The route deletes are needed because the ifconfig creates a default
route to the interface's network, which can cause problems; all that's
needed is the (host) route to the interface's address. 

Now, get le0's ethernet address (say, 8:0:20:3:2:1), and add the
following static ARP entries:

  arp -s 198.4.3.2 8:0:20:3:2:1 pub
  arp -s 198.5.4.3 8:0:20:3:2:1 pub

This will cause any ARP requests for the VIF addresses to be replied
with your machine's ethernet address. 

Now, make sure your default route is to your segment's gateway,
throught the real interface. FInally, make sure your routers and/or
hosts on the same segment as yours know that 198.4.3.2 and 198.5.4.3
are on that cable. 

Here's what you've accomplished.

ARP requests for any of your host's addresses will be replied to with
the host's ethernet address (the real one, because that's what it is,
the virtual ones because of the public static arp entries). Packets
reaching your host with any of these addresses will be accepted by the
ip_input routine because they match the address of one of the host's
interfaces. Packets leaving your host can have any of its addresses
(real and virtual). 

The code for vif follows. To use it, put the stuff in netinet/if_vif.c
and netinet/if_vif.h, configure your kernel with the number of
virtual interfaces you want using a line like:

pseudo-device	vif4		# Virtual IP interface

in your configuration file, and two lines like

netinet/if_vif.c	optional vif device-driver
netinet/if_vif.hc	optional vif device-driver

in the files file. Also, add the appropriate entries in conf.c, so
that you can access the if_attach() routine when you open the device:


------------------------in conf.c------------------------------------------

add this in the appropriate place in the headers of conf.c:

--------------------
#include "vif.h"
#if NVIF > 0
int	vifopen(), vifclose(), vifread(), vifwrite(), vifselect(), vifioctl();
#else
#define vifopen		nodev
#define vifclose	nodev
#define vifread		nodev
#define vifwrite	nodev
#define vifselect	nodev
#define vifioctl	nodev
#endif
--------------------

then, way down in the definition for cdevsw[]:

--------------------
	vifopen,	vifclose,	vifread,	vifwrite,	/*31*/
	vifioctl,	nodev,		nodev,		0,
	vifselect,	nodev,
--------------------

Make sure you remember the correct major device number!

------------------------in conf.c------------------------------------------

Finally, here's the code. It has the tunneling pieces removed (you
need more code to use that anyway), and it comes from a Mach 2.6
kernel; it should compile on any berkeley-derived unix with minor
changes (most likely only in the includes). 

---------------------netinet/if_vif.h--------------------------------------
typedef struct 
{
	struct ifnet	vif_if;
	struct ifnet	*vif_sif;	/* slave interface */
	int		vif_flags;
} vif_softc_t;

#define	VIFMTU	(1024+512)
---------------------------------------------------------------------------

and
---------------------netinet/if_vif.h--------------------------------------
/*
 * HISTORY
 * $Log:$
 */
 
/*
 * $Header:$
 *
 * Virtual IP interface module. 
 */

#include <multicast.h>

#include "param.h"
#include "systm.h"
#include "mbuf.h"
#include "socket.h"
#include "errno.h"
#include "ioctl.h"

#include "../net/if.h"
#include "../net/netisr.h"
#include "../net/route.h"

#ifndef MACH
#include "../machine/mtpr.h"
#endif

#ifdef	INET
#include "../netinet/in.h"
#include "../netinet/in_systm.h"
#include "../netinet/in_var.h"
#include "../netinet/ip.h"
#endif

#ifdef NS
#include "../netns/ns.h"
#include "../netns/ns_if.h"
#endif

#include "in_pcb.h"

#include "ip_var.h"
#include "ipip.h"
#include "ipip_var.h"
#include "micp.h"
#include "micp_var.h"

#include "if_vif.h"
#include "vif.h"

vif_softc_t vif_softc[NVIF];

int vifs_inited = 0;

int	vifoutput(), vififioctl();

vifattach()
{
	register int i;
	register struct ifnet *ifp;
	
	for (i=0; i<NVIF; i++)
	{
		ifp = &vif_softc[i].vif_if;
		ifp->if_name = "vif";
		ifp->if_unit = i;
		ifp->if_mtu = VIFMTU;
#if	MULTICAST
		ifp->if_flags = IFF_MULTICAST | IFF_NOARP;
#else	MULTICAST
		ifp->if_flags = IFF_NOARP;
#endif	MULTICAST
		ifp->if_ioctl = vififioctl;
		ifp->if_output = vifoutput;
		if_attach(ifp);
	}
}

vifopen(dev, flag)
int dev, flag;
{
	int unit;
	
	if (!vifs_inited)
	{
		vifattach();
		vifs_inited = 1;
		printf("vif initialized\n");
	}
	
	unit = minor(dev);
	if ((unit < 0) || (unit >= NVIF))
	{
		return ENXIO;
	}
	
	return 0;
}

vifclose(dev, flag)
int dev, flag;
{
	return 0;
}

vifread()
{
	return ENXIO;
}

vifwrite()
{
	return ENXIO;
}

vifselect()
{
	return ENXIO;
}

vifoutput(ifp, m0, dst)
	struct ifnet *ifp;
	register struct mbuf *m0;
	struct sockaddr *dst;
{
	int s;
	register struct ifqueue *ifq;
	struct mbuf *m;
	struct sockaddr_in *din;
	
	if (dst->sa_family != AF_INET)
	{
		printf("%s%d: can't handle af%d\n", 
		       ifp->if_name, ifp->if_unit,
		       dst->sa_family);
		m_freem(m0);
		return (EAFNOSUPPORT);
	}

	din = (struct sockaddr_in *)dst;
	
	if (din->sin_addr.s_addr == IA_SIN(ifp->if_addrlist)->sin_addr.s_addr)
	{
		printf("%s%d: looping\n", ifp->if_name, ifp->if_unit);
		
		/*
		 * Place interface pointer before the data
		 * for the receiving protocol.
		 */
		if (m0->m_off <= MMAXOFF &&
		    m0->m_off >= MMINOFF + sizeof(struct ifnet *)) {
			m0->m_off -= sizeof(struct ifnet *);
			m0->m_len += sizeof(struct ifnet *);
		} else {
			MGET(m, M_DONTWAIT, MT_HEADER);
			if (m == (struct mbuf *)0)
			  return (ENOBUFS);
			m->m_off = MMINOFF;
			m->m_len = sizeof(struct ifnet *);
			m->m_next = m0;
			m0 = m;
		}
		*(mtod(m0, struct ifnet **)) = ifp;
		s = splimp();
		ifp->if_opackets++;
		ifq = &ipintrq;
		if (IF_QFULL(ifq)) {
			IF_DROP(ifq);
			m_freem(m0);
			splx(s);
			return (ENOBUFS);
		}
		IF_ENQUEUE(ifq, m0);
		schednetisr(NETISR_IP);
		ifp->if_ipackets++;
		splx(s);
		return (0);
	}

	return EHOSTUNREACH;
}

/*
 * Process an ioctl request.
 */
/* ARGSUSED */
vififioctl(ifp, cmd, data)
	register struct ifnet *ifp;
	int cmd;
	caddr_t data;
{
	int error = 0;

	switch (cmd) {

	case SIOCSIFADDR:
		ifp->if_flags |= IFF_UP;
		/*
		 * Everything else is done at a higher level.
		 */
		break;

	default:
		error = EINVAL;
	}
 return (error);
}

vifioctl(dev, cmd, arg, mode)
dev_t dev;
int cmd;
caddr_t arg;
int mode;
{
	int unit;
	
	unit = minor(dev);
	if ((unit < 0) || (unit >= NVIF))
	  return ENXIO;
	
	return EINVAL;
}
---------------------------------------------------------------------------- 

To use it, compile your kernel, and reboot. Then create the vif
device:

# mknod /dev/vif c 31 0

(or whatever major number it ended up being), and echo something into
it:

# echo > /dev/vif

This will cause the device to be opened, which will if_attach the
interfaces. If you feel like playing with the code, you may want to
kmem_alloc() the vif_softc structrure at open time, and use the minor
number of the device to tell it how many interfaces to create. 

Now you can go ahead and ifconfig etc. 

I'll be happy to answer minor questions, and hear about success and
failure stories, but I cannot help you if you don't already know how
to hack kernels.

Good luck! 

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 1992 21:40:34 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Encrypted IP

In article <1992Feb12.211725.27304@m.cs.uiuc.edu>, zweig@cs.uiuc.edu (Johnny Zweig) writes:
|> A somewhat simpler (to specify, at least) technique would be to have an IP
|> Encrypted Data Option. [...]

I like this second idea. And while we're at it, we should also have an
IP Authentication Option; either or both could be used in a given
packet.

This seems much cleaner and more general than adding encryption or
authentication to each and every Internet application protocol.

OSI has something called SP3/SP4 that's purported to work in this way.
But when I obtained a copy it was written in the usual OSIfied manner
and was almost indecipherable, so to speak. How about doing it right
in TCP/IP?

Phil

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 1992 21:46:55 GMT
From:      nowak@fraser.sfu.ca (Bradley Stephan Nowak)
To:        comp.protocols.tcp-ip
Subject:   Looking for dialup slip for tn3270 .

I obtained tn3270 and a slip driver (slip8250.com) this seems to work ok,
but I would like to be able to dial into a cisco terminal server and
enter the command "slip" and begin a sesion . Is there any software that will
allow me to do this (if there is where is it ?).

thanx in advance :
Brad .


-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 92 22:36:00 GMT
From:      coolidge@speaker.wpd.sgi.com (Don Coolidge)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: HP-UX Ethernet MTU

In article <kdaOq1H0BwwbI1AZhg@transarc.com>, Lyle_Seaman@transarc.com writes:
|> Does anybody have any idea howcum the Ethernet MTU on all the 
|> HPUX systems I can find is 1497 bytes?
|> 
|> I was pretty surprised by this.
|> I guess the lesson is: don't use 'em as routers...
|> 
|> (for the skeptical - run "netstat -i")
|> Lyle		Transarc		707 Grant Street
|> 412 338 4474	The Gulf Tower		Pittsburgh 15219

It's because HP supports both Ethernet and IEEE 802.2/.3 packet 
encapsulation concurrently on the same network, and the 802.2/.3
MTU is 1497. The interface MTU has to be the lesser of the two,
since IP has no idea what encapsulation will be used on any given
packet.

If you're running 7.0 or later (I _think_ this fix made it into
7.0), just ifconfig ieee off (for 8.0, the plan was to move that 
functionality into the new lanconfig command). When only Ethernet 
is configured, the MTU is 1500.

So, sure, use them as routers. Just know what you're doing first.

- Don Coolidge
coolidge@speaker.wpd.sgi.com

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Feb 1992 22:44:53 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem w/ICMP:Port Unreachable

In article <1992Feb13.103755.52672@cc.usu.edu>, jrd@cc.usu.edu (Joe R. Doupnik) writes:
> In article <2340007@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
> >> >	Gee, I hope I haven't violated a rule, but in MS-DOS Kermit v3.12
> >> >(not out yet) I inserted code to send an ICMP "port unreachable" response
> >> >when a UDP pkt arrives and the UDP code says no_such_port.
> >> 
> >> No, you haven't violated a rule.  This is precisely what ICMP Port
> >> Unreachable is intended to be used for.
> >> -- 
> >> Barry Margolin, Thinking Machines Corp.
> > 
> > Barry's right, this is what Port Unreachable is for...
> > 
> > But IFF you happen to be sending that ICMP Port Unreachable to a host that
> > did a "connect()" followed by "send()" or "write()" instead of just a
> > "sendto()" AND that sender also has done another UDP "connect()" to something
> > on your host (same destination IP address, different port number), it can
> > expect to get an error on that perfectly OK second UDP "connection", delivered
> > as a result of the Port Unreachable on the first port number.
> > 
> > Ted Rypma
> > HP Panacom Division
> > (speaking gibberish on his own, as usual)
> --------------
> 	You might well be correct in all this. However the specs say (& I do)
> attach the incoming headers as returned data. This allows smart recepients to
> discover which ports were referenced and thus (fingers crossed) decide which
> conversation receives the bad news. Thus one ICMP Port Unreachable message
> should not, quoted, disturb other connections.
> 	Joe D. 

Hmm - I seem to have started something here! For those that came in
late, I reported that sending an ICMP:Port Unreachable massage to a Sun
SPARCstation (e.g. in response to a packet from an old connection after
the my end had crashed) for a TCP packet caused the Sun to drop all
other TCP connections between the two hosts. Barry (and several others)
pointed out the USUAL thing to do is send a RST segment, not Port
Unreachable, but technically the Sun should accept the ICMP message as
equivalent to a RST packet. It seems much the same happens for UDP
connections, although Barry has tested that a ICMP:Port Unreachable from
a UDP port doesn't cause the Sun to drop TCP connections - what a
relief! It seems this is common to all BSD systems.

I contend that it is BETTER to send an ICMP packet than a TCP
RST segment in this case, because of the extra information provided -
receiving a RST segment means the other end doesn't want to talk to you,
but receiving an ICMP Port Unreachable (or host/net unreachable) tells
you WHY the other end doesn't want to speak to you. Regardless of this
position, the ICMP:Port Unreachable allows the TCP (or UDP) to isolate
which port it applies to, so the receiver should NOT affect any other
connection.

So who do we contact to get BSD code fixed?



Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 92 22:45:49 GMT
From:      mike@isg.llnl.gov (Michael E. Hummell)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   SUMMARY: Problem: NCSA 2.3.03: Orchid VGA card causes lockup

I got 3 responses overnight ( Many Thanks !! ) .

First, there's a bug in NCSA's video refresh, which can be overcome with 
"-n" option in telbin (viz:  telbin -n -h config.tel  ). 

Second:  The PC didn't lockup, only the video screen.  One can run a 
video utility (one came with the Orchid board) to refresh the screen as soon
as you're out of Telbin (e.g., put "vmode vga" right after Telbit in a bat
file).

I tried both of these.  Both worked.   Thanks so much  ...  MIKE

P.S.  HERE ARE THE RESPONSES I GOT:
-----------------------------------

Article 9562 of comp.protocols.tcp-ip.ibmpc:
From: mjn@oregon.uoregon.edu (Mike Neuburger)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Problem: NCSA 2.3.03: Orchid VGA card causes lockup upon exiting
Date: 13 Feb 92 04:34:55 GMT
Sender: news@nntp.uoregon.edu
Distribution: na
Organization: University of Oregon

There is a bug in the video refresh code if I remember correctly.  You need 
to use the -n flag win running telbin (ie. telbin -n -h c:\utility\config.tel
)

Hope this helps,

Mike Neuburger
Network Engineer
University of Oregon

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

From witte@cunixf.cc.columbia.edu Wed Feb 12 19:35:26 1992
To: mike@isg.llnl.gov
Subject: Re: Problem: NCSA 2.3.03: Orchid VGA card causes lockup upon exiting
Newsgroups: comp.protocols.tcp-ip.ibmpc
Organization: Columbia University

I've had a similar problem with that software (different hardware
though).  Are you sure it's locked up?  I thought mine was, but I
could flash the disk light by running software, etc.

If it's not really hung (ie just the display), see if you can use a
video mode selection utility (one that may have come with the card),
to change modes, and either type the required command, or put it in a
batch file which is used to run ncsa telnet.

Speaking for myself, hoping for the best,

/Breck Witte
-------------------------------------------------------------------------------
      breck witte			    columbia university libraries
      witte@columbia.edu	    	     systems office - 221m butler
      rutgers!columbia!cunixf!witte 	               new york, ny 10027
-------------------------------------------------------------------------------


From cdunn@convex.mitek.com Thu Feb 13 09:18:37 1992
To: mike@isg.llnl.gov
Subject: Re: Problem: NCSA 2.3.03 : Orchid VGA card causes lockup upon exiting
Newsgroups: comp.protocols.tcp-ip
Organization: OpenConnect Systems

OpenConnect Systems has a product to work with this board as a terminal emulatorAlso, you might try to set the mode upon exit.  On some VGA Mono Monitors our 
program has had a similar problem upon exit the screen goes blank.  However one would think that the program locked-up and then reboot the machine.  If you set
up a batch file to reset the mode the program works fine. In the similar case 
the user could not see that the session is still active but yet the VGA card 
would not reset the correct mode. If I can be of futher help let me  know 
cdunn@mips.oc.com

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1992 09:19:25 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Elementary question about telnet session

In article <1992Feb13.192233.22832@nmsu.edu> subbarao@wilma.nmsu.edu (Ravi Subbarao) writes:
>When I try telneting into a remote machine, I have a substantial delay before
>the login prompt comes up. After that, the interaction seems regular with
>no awkward delays.
>
>But, when I try telneting into the same machine again, I dont get this extra
>delay as earlier.

This delay is probably from accessing domain name servers to translate the
host name into an address.  Most systems maintain a local cache of this
information, so the next time you try, you get the address from the local
cache quickly (that's the whole point of caches).

-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 12:36:00 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with ICMP:Port Unreachable to Sun

>Most implementations that I've seen treat port unreachable messages the
>same as host unreachable messages, and send the error condition to all
>UDP sockets on the system that are connected to same host that
>generated the ICMP msg. That is if the originating bad packet was of
>the UDP flavor.

There was a posting about a year ago on this exact "feature" by Guy Harris.
He said the reason for this behavior (the UDP port unreachable going to all
processes talking to the same host) was a bug in the BSD code: in_pcbnotify()
in netinet/in_pcb.c to be exact.  He claimed Sun fixed this in either 4.1 or
4.1.1, and I also notice that it appears to be fixed in the Reno sources.

	Rich Stevens  (rstevens@noao.edu)

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 15:11:38 GMT
From:      ag129@cl.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   Nameserver TXT records


Can anyone give a definite ruling on the format of nameserver TXT records,
specifically whether the first data byte is a length byte or the first
character of the string?  RFC 1035 isn't as explicit as it could be, and 
(some) lookup programs don't agree with what's in (some) nameservers.
Thanks...

Alastair Grant, MVS Network Systems Programmer, Cambridge University, UK

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Feb 1992 15:25:40 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   Re: Elementary question about telnet

The telnet server process may be swapped to disk, if no one has established a session in some time.  The connection may establish immediatly but the program may have to wake up swap to memory and send "Welcome" down the line.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Feb 1992 15:27:09 GMT
From:      jcook@ardneh.rtpnc.epa.gov (Jim Cook)
To:        comp.windows.x,comp.sys.novell,comp.protocols.tcp-ip
Subject:   X over IPX/SPX vs. TCP/IP ??

I'm curious if this can be done.  I'd rather not get into WHY
anyone would want to, but are there technical limits that
prevent it?

I.E., Could I run X clients on a UNIX machine together with
Portable Netware and use X server software on  DOS PCs with only
the Novell protocol stacks?  Assuming the previous is technically
possible, is there any software that can do it today?

Jim Cook - jcook@ardneh.rtpnc.epa.gov
-------------------------------------

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 15:28:35 GMT
From:      ppollock@ub.d.umn.edu (Paula Pollock)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: NCSA 2.3.03 : Orchid VGA card causes lockup upon exiting

In article <117916@lll-winken.LLNL.GOV> mike@isg.llnl.gov (Michael E. Hummell) writes:
>My friend was using NCSA Telnet 2.3.03 with no problems
>using ega monitor.  Then he got a vga monitor and a "Prodesign VGA" video card
>made by "Orchid Technology".
>
>PROBLEM:  He connects ok to a host, but when he logs out, the screen goes 
>black, there's one beep, then the PC (a 386 clone) locks up.  Have to
>CTRL-ALT-DEL to continue.
>

We are experiencing the same problem with NCSA Telnet 2.3.03 and two
zeos computers with Hercules monochrome.  Any input would be appreciated.

-------------------------------------------------------------
  Paula Pollock        |   internet:  ppollock@ub.d.umn.edu
  Information Services |   BITNET:    ppollock@UMNDUL 
     University of Minnesota Duluth   Duluth, Minnesota
--------------------------------------------------------------

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Feb 1992 16:23:34 GMT
From:      cole@etonic.gsg.dco.dec.com (Larry Cole)
To:        comp.protocols.tcp-ip
Subject:   Implementations of IP Security ?

I am looking for information about any implementations of
Extended IP Security Options (RFC 1108, RFC 1038).



thanks,

larry cole
Digital Equipment Corporation
Landover, MD
Email:	cole@dco.dec.com

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 16:27:16 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: A frag here, a frag there, pretty soon your talking real memory.

In article <6200044@hpindda.cup.hp.com> raj@hpindda.cup.hp.com (Rick Jones) writes:
 [ "What to do if I find myself holding more IP fragments than I like?"]

>I would like to avoid giving-away all of that memory when someone is
>being doubleplusunnice towards my system. How am I to do it? Should I:
>
>	1) Put some limit on the number of fragments in the reassembly
>	   queue? If so, how do I handle the overflow - drop the
>	   recent arrivals, drop the oldest fragment? I'd rather not
>	   be doing much calculation.

I vote for this option.
I prefer it over the others because it doesn't throw anything away
unless there really is a resource shortage.

Selecting the oldest fragment, or the datagram with the most
missing fragments, both seem reasonable to me.  In any case, if you
toss one fragment you might as well toss that entire datagram, because
nobody does selective fragment retransmission!

Note that you are unlikely to ever encounter a situation like this,
unless you have malicious systems programmers in the neighbourhood,
because your high-speed LAN would not normally fragment local-origin
traffic, and remote sources that would be subject to fragmentation
probably cannot pump significant traffic through your gateways.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 16:36:44 GMT
From:      Lyle_Seaman@transarc.com
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: HP-UX Ethernet MTU

coolidge@speaker.wpd.sgi.com (Don Coolidge) writes:
> In article <kdaOq1H0BwwbI1AZhg@transarc.com>, Lyle_Seaman@transarc.com writes:
> |> Does anybody have any idea howcum the Ethernet MTU on all the 
> |> HPUX systems I can find is 1497 bytes?
> |> 
> It's because HP supports both Ethernet and IEEE 802.2/.3 packet 
> encapsulation concurrently on the same network, and the 802.2/.3
> MTU is 1497. The interface MTU has to be the lesser of the two,
> since IP has no idea what encapsulation will be used on any given
> packet.

The 802.3 MTU is 1492.
I got another explanation from HP, I'm still trying to figure it out.
I'll post it when I do.

> If you're running 7.0 or later (I _think_ this fix made it into
> 7.0), just ifconfig ieee off (for 8.0, the plan was to move that 
> functionality into the new lanconfig command). When only Ethernet 
> is configured, the MTU is 1500.
> 
> So, sure, use them as routers. Just know what you're doing first.

Thanks - I'll give this a try and see what happens.

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 21:35:28 GMT
From:      prao@hcfmail.ucsb.edu (Parik Rao)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: NCSA 2.3.03 : Orchid VGA card causes lockup upon exiting

In <117916@lll-winken.LLNL.GOV> mike@isg.llnl.gov (Michael E. Hummell) writes:

>My friend was using NCSA Telnet 2.3.03 with no problems
>using ega monitor.  Then he got a vga monitor and a "Prodesign VGA" video card
>made by "Orchid Technology".
 
>PROBLEM:  He connects ok to a host, but when he logs out, the screen goes 
>black, there's one beep, then the PC (a 386 clone) locks up.  Have to
>CTRL-ALT-DEL to continue.

I had a similiar problem.  My solution was not very elegant, but it works.
Download clarkson's telnet from omnigate.clarkson.edu.  On one machine
only TN3270 v2.2E would work, but for most of them, CUTCP telnet worked
fine.  These were all 486's using ProDesign's or Speedstars.

The weird thing is the machine actually didn't lock up; it would just blank
the moniter.  If you did a dir a: the floppy would access.  DIR would
show the hd light blink on/off.  WIN would load up windows, but we couldn't
see anything.

If anyone finds a solution (yes, I tried bios=no,yes,maybe) I'd appreciate
a copy.

--
Parik Rao         [.]      prao@{bluemoon || hcfmail || voltaire}.ucsb.edu
Major in Comp-Sci  |       Gravity is a myth.... the Earth sucks. 
and Sorcery        |        

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Feb 1992 22:01:39 GMT
From:      mahmood@freedom.msfc.nasa.gov (Rafique Mahmood)
To:        comp.sys.sun.admin,comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   TCP Summary: anomalous packet size & CPU utilization

 Thanks everyone who sent me different suggesion on my
TCP UDP results.

I was trying different posibility but there were few
reasons for my anomalous throughput and :

   1. for TCP I changed my send and receive buffer size
	using SO_SNDBUF and SO_RCVBUF options. I thought
	I did same thing before, by editing the kernel 
	files and rebuilding the kernel but for some reason
	I got better result by setting these option.

	If anyone know the difference between these two methods
	please let me know.

   2. To get the accurate results benchmarks need to run
	on identically configured machines, but because
	of the unavailibility of similar machines, in 
	some cases I ran between two different vendor's
	machines. Because of the effeciency of one ethernet
	driver from other, the receiving machine received
	all the packets but it dropped them before it put them
	in the memory via DMA. 

	This time I choose the different pair of machines 
	with similer ethernet driver.
  
	 
   3.  The memory fluctuation was partly may be due to 
	the re-transmission of the packets in TCP; therefore
	I saw the fluctuation in both the TCP send and receive
	rates.

	Other reason could be the ethernet interrupt. In some
	case in UDP, I saw the fluctuation for receive case.
	Ethernet interrupt has hig priority, so when 
	interrupt was occuring kernel was putting the process
	to sleep and taking care of I/O. Therefore, while
	monitoring I was seeing burst of work then sleep again.  

I have got much better results with all the machines except
for Decstation 5000, at 1100 byte and above size packets
TCP receive rate dropped significantly and also the CPU 
utilization for TCP send dropped significantly.

If anyone has any suggesion on this plese let me know.

Thanks again. 


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 22:58:31 GMT
From:      ian@unipalm.uucp (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Picking IP numbers (non-Internet)?

dfk@cwi.nl (Daniel Karrenberg) writes:

>jhawk@panix.com (John Hawkinson) writes:
 
>>I'm in a situation where I have to pick IP#'s for a small number
>>of PC's (<20) which will not be on the Internet (say, for the next
>>5 years at the earliest) ...
 
>Get an official IP number and save yourself or those coming after you 
>lots of potential hassle!

I agree. I just spent 7 hours last weekend changing IP addresses to get
us on to the Internet. The price of a class C address is quite
reasonable :-)

-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
Vapourware is the programming industry's answer to solid-state computers.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 92 23:23:58 GMT
From:      scliew@ecst.csuchico.edu (Lewis Liew)
To:        comp.protocols.tcp-ip
Subject:   Master Project's Topic Needed


	Hi guys, I'm a computer science graduate student desperately looking
for a topic for my master project. My interest is writing a network application
program in Unix environment, such as finger, ftp, etc.

	So, anybody has any specific topic in this area, please e-mail me. My
e-mail address: scliew@cscihp.ecst.csuchico.edu

	Thanks in advance.

Lewis Liew

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Feb 92 23:41:15 GMT
From:      coolidge@speaker.wpd.sgi.com (Don Coolidge)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: HP-UX Ethernet MTU

In article <Adaz0Q30BwwbI0ovwB@transarc.com>, Lyle_Seaman@transarc.com writes:
|> coolidge@speaker.wpd.sgi.com (Don Coolidge) writes:
|> > In article <kdaOq1H0BwwbI1AZhg@transarc.com>, Lyle_Seaman@transarc.com writes:
|> > |> Does anybody have any idea howcum the Ethernet MTU on all the 
|> > |> HPUX systems I can find is 1497 bytes?
|> > |> 
|> > It's because HP supports both Ethernet and IEEE 802.2/.3 packet 
|> > encapsulation concurrently on the same network, and the 802.2/.3
|> > MTU is 1497. The interface MTU has to be the lesser of the two,
|> > since IP has no idea what encapsulation will be used on any given
|> > packet.
|> 
|> The 802.3 MTU is 1492.
|> I got another explanation from HP, I'm still trying to figure it out.
|> I'll post it when I do.

802.2/.3 with SNAP (that is, RFC 1042 for IP datagrams) MTU is 1492. 
HP still uses old-style 802.2/.3, with an MTU of 1497 (the IP header 
directly follows the CTRL field of the 802.2 header), for ISO support, 
for backward IP compatibility (pre-RFC 1042 specified an IP SAP of 6), 
and for communication with their other boxes running MPE and RTE, using
old-style (i.e. non-compliant) 802.3 IP. I believe their only kernel 
SNAP support is on token rings, though the code could be used on 
Ethernets, too, without too much trouble. However, when I was at HP,
trying to get "permission" to put 802.2/.3 SNAP support in was like 
trying to get permission to date Mother Theresa...

Don Coolidge
coolidge@speaker.wpd.sgi.com 

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Feb 1992 23:54:35 GMT
From:      blumen@infonode.ingr.com (Dwayne Blumenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM 3090 and TCP/IP

In article <1992Feb11.095842.2463@idx.com> jrb@idx.com writes:
>Hi Folks,
>
>We have a need to talk to an IBM 3090. We are running on a VAX using multinet
>TCP/IP.  We are told by the IBM folks that you can't talk from CICS (what they
>program in) to the TCP/IP driver.
>
>Does anyone have any experience in communicating from TCP/IP on the 3090 to CICS
>on the 3090?  Is it possible?
>
>Thanks for any info you can give me!
>
>Jim Bresee


It depends on what you mean by "communicating".  If you mean using
TN3270 to telnet to CICS via TCP/IP, you should have no problem.
Telnet will go through VTAM, so the TN3270 session looks like any
other VTAM terminal session to CICS.

If on the other hand, you mean having a CICS application communicate
to some other program on the network via TCP/IP, say, for example,
using sockets, then things become more difficult.  Unless the socket
library on the IBM is smart enough to issue CICS waits instead of
operating system wait calls (and I don't know of any that are), each
blocking socket call will likely place the ENTIRE CICS SYSTEM into
wait state, not just your transaction.  CICS effectively becomes a
single-user system.

Another problem with TCP/IP and CICS is that there's no way that
I know of to initiate a CICS transaction from an external network
event as can be done with SNA LU 6.2.  Long-running "listener"
-type programs are generally a big NO-NO in CICS; CICS transaction
times are normally measured in seconds and fractions of seconds.

I'm not saying it's impossible to use sockets and CICS, just that
it must be done very carefully.

-- 
Dwayne A. Blumenberg            | Internet:  dwayne@dwayneb.b17d.ingr.com
MVS Systems Programmer          | UUCP:      ...uunet!ingr!b17d!dwayneb!dwayne
Intergraph Corp., M.S. IW17D1   | Voice:     (205) 730-7785
Huntsville, AL  35894-0001      | FAX:       (205) 730-7509

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 92 02:36:57 GMT
From:      leonid@netcom.COM (Leonid Crossman)
To:        comp.protocols.tcp-ip
Subject:   Rlogin/Telnet number of session restriction - Help Wanted!

I am running SCO ODT 1.1 between two 386 clone. If I have rlogin or telnet
session (in one direction) and try to open the second from other window,
I receive 'connection closed' message. If I close connection in first window
the second starts to work. It happens for different cards and drivers and
therefore seems to be system problem. ( ODT serial numbers are different, of
course). If I run the only rlogin or telnet session I can use ftp, nfs tran-   
sfers, ping etc. from different windows at the same time. 
If somebody has any suggestions please let me know.
            Thanks a lot in advance.
                                        leonid@netcom.com 

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Feb 92 22:16:37 GMT
From:      dpayne@isis.cs.du.edu (Dirk Payne)
To:        comp.protocols.tcp-ip
Subject:   SLIP on IPC w/ 4.1.1

I have had a SLIP kernel installed in the past on a SPARC1 running 4.1.1, yet
I am experiencing problems with the streams interface in 4.1.1 recognizing
the SLIP interface installed in the kernel on an IPC. I have followed the 
instructions contained in the CSLIP distribution tar, but to no avail.

The only response that I receive from the kernel is that the "slip" stream
driver is invalid, yet the "slip_attach" function (which I chose to include)
shows installation on the console during the boot. Wierd.

The only fundamental difference between the two machines (other than the
arhitecture) is that I now serve a local printer (HPIII), and the new IPC
sports the low end Sun color display (cgthree I believe is the driver).

Any help would be GREATLY appreciated. Thanks in advance.

--
===============================================================================
"If at first you don't succeed ... hack, hack again!!"    dpayne@isis.cs.du.edu
===============================================================================

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Feb 1992 23:16:55 GMT
From:      contrct2@cheops.qld.tne.oz.au (Contract_2_login)
To:        comp.protocols.tcp-ip
Subject:   Time out on name service


	The summary says it all.

-- 
------------------------------------------------------------------------------
"Love makes the world go around, but sex makes the ride fun..."
                   Telecom does not know I'm saying this.
	Stephen Hocking			contrct2@cheops.qld.tne.oz.au

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Feb 1992 01:29:11 GMT
From:      ME.DMG@forsythe.stanford.edu (David Gaba M.D.)
To:        comp.protocols.tcp-ip
Subject:   Elementary question about telnet

This is a super-elementary question, but you got to start somewhere

I have just discovered the ability to telnet to my usual university
host.  When I am away is there a standard way to connect to a
local host just for the privilege of telneting to my usual host.
If so, how does one go about doing this in far away cities?

Thanks,  D. Gaba, M.D., Asst Prof of Anesthesia, Stanford


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Feb 1992 03:05:45 GMT
From:      pmaggs@uxh.cso.uiuc.edu (Peter B. Maggs)
To:        comp.protocols.tcp-ip
Subject:   Re: Elementary question about telnet

ME.DMG@forsythe.stanford.edu (David Gaba M.D.) writes:

>This is a super-elementary question, but you got to start somewhere
 
>I have just discovered the ability to telnet to my usual university
>host.  When I am away is there a standard way to connect to a
>local host just for the privilege of telneting to my usual host.
>If so, how does one go about doing this in far away cities?
If you have an IBM PC at the office with a modem, you can just
call it up and use a remote control program, either one of the
fancy ones that costs $150 or "TELREPLICA", a shareware program
to control your PC, and then go from there onto the network to
which your PC is hitched.  You can do the same with a MAC, and
I assume there are similar programs for other machines.  Even
better, if you can talk your way onto a university computer
where you are on your trip, you can telnet from it onto your regular
campus host.  Another alternative is to call long distance to
mainframe A on your campus and telnet from there to other
hosts on your campus.
I used the first scheme (PC in office with modem; PC also on
3COM network gatewayed to campus network) all last summer,
working from Hawaii on computers at the University of Illinois.
I never had any trouble.  If you download files that need a
lot of editing, edit them locally and then upload, the phone
bills aren't too bad.  (I used the TELREPLICA program.)
Peter Maggs  -- pmaggs@vmd.cso.uiuc.edu


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 03:17:35 GMT
From:      bob@pta.pyramid.com.au (Bob Vernon)
To:        comp.protocols.tcp-ip
Subject:   Rlogin protocol description.


I have been reading this group, ftp'ing various RFCs and even reading
source code.  But nowhere can I find a description of the rlogin
protocol.  If anyone could point me to somewhere that has a low-level
description of rlogin, I'd be grateful.  Note that this is the protocol
used by the Unix rlogin program, not telnet which is described in its
rfc as a "protocol for remote logins".

My specific problem is that I have two systems that talk quite well via
rlogin.  But whenever the remote side switches from cooked to raw mode,
the terminal side receives three single character packets (0x80, 0x90
and 0xA0).  These are displayed on the screen instead of being
interpreted as rlogin commands.  I'd appreciate any suggestions at all
about what is happening here.

Email replies are preferred.  I'll summarize any responses I get.

      -m-------   Robert Vernon			  bob@pta.pyramid.com.au
    ---mmm-----   Pyramid Technology (Australia)
  -----mmmmm---   402 Pacific Highway		  PHONE: +61 2 901 5333
-------mmmmmmm-   Artarmon 2064 Australia	  FAX: +61 2 906 4353

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 14:50:03 GMT
From:      liam@dcs.qmw.ac.uk (William Roberts)
To:        comp.protocols.tcp-ip
Subject:   Re: A frag here, a frag there, pretty soon your talking real memory.

In <1992Feb14.112716.7515@jarvis.csri.toronto.edu> thomson@hub.toronto.edu 
(Brian Thomson) writes:

>Note that you are unlikely to ever encounter a situation like this,
>unless you have malicious systems programmers in the neighbourhood,
>because your high-speed LAN would not normally fragment local-origin
>traffic, and remote sources that would be subject to fragmentation
>probably cannot pump significant traffic through your gateways.

Except, of course, that most NFS implementations will fragment IP packets *at 
source* in their attempt to ship 8K+ write requests and/or read replies. It 
isn't hard, with diskless clients and the like, to spew fragments all over the 
place. If this happens to you, changing your NFS mounts to have rsize=1024, 
wsize=1024 will make all of the NFS traffic fit into unfragmented IP packets.
--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Computer Science Department     
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 16:18:38 GMT
From:      sorace@scxel3ec.bull.fr (Sorace Jean-Dominique)
To:        comp.protocols.tcp-ip
Subject:   Looking for Info about RFC1006

I would appreciate if anyone could give me any information
or descriptions about RFC1006 implementation.
To be more precise I am looking for any details on RFC1006 source
code or porting experience on STREAMS.

thanks in advance.
please e-mail answers to J.D.Sorace@frec.bull.fr

-- Jean-Do.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 16:24:55 GMT
From:      kent@manzi.unx.sas.com (Paul Kent)
To:        comp.protocols.tcp-ip
Subject:   OpenConnect and telnet option negotiation

hi,

i hope this is not too far from the topic...

My application (SAS/Connect) expects to read and write a 
network virtual terminal over the socket connected to the
TELNET port of some host...

i respond WONT to the DO TERMINAL TYPE telnet options request
(i'm quite inflexible when it comes to negotiating options,
plain vanilla is all i want!)


When my program connects to a host running sna3270 from 
"OpenConnect Software"? they send 3270 datastreams (or at least 
cursor control to fake it) and this "gets in the way"


Does anyone out there know if its possible to configure this
sna3270 software to do "linemode" telnet, (even if it has to
run on a non-standard port-number - my program can deal with that)


I'd appreciate any tips so that i might help the customer of ours
(and OpenConnect's) that is running into this problem...


Thanks,
Paul






-- 

Paul Kent (SQL r&d)                   " nothing ventured, nothing disclaimed "
kent@unx.sas.com         SAS Institute Inc, SAS Campus Dr, Cary NC 27513-2414.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 16:36:40 GMT
From:      asheriff@lucpul.it.luc.edu (Ali Sheriff)
To:        comp.protocols.tcp-ip
Subject:   Email address for Peter Haakanson??

Does anybody know the address of Peter Haakanson. He works for VolvoData
Sweden. I replied to his mail which was bounced back as invalid address.

I would appreciate any help.

Thanks.
Ali.
(asheriff@lucpul.it.luc.edu)

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Feb 92 23:34:10 EST
From:      max@underg.UUCP (Max Cray)
To:        comp.protocols.tcp-ip
Subject:   Good Book on TCP/IP networking

 
Can someone recommend a good book, on tcp/ip networking from a 
users/sysadmin's (not programmer's) point of view? Please e-mail replies. 
Thank you.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                            -= Max Cray =-
 Net:     underg%max@uunet.uu.net                         Support
 UUCP:    ...!uunet!idsvax!underg!max                     Free
 Data:    The Underground Computing Foundation BBS        Software
          401-847-2603 -=- 9600 baud (v.32)               (w/src)
 CI$:     76334,2203

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 18:49:53 GMT
From:      tjh+@andrew.cmu.edu (Tom Holodnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Firewalls and connecting to Internet

Andy,
	You might avail yourself to online documentation on cert.sei.cmu.edu
(192.88.209.5).  FTP anonymously and you will find information related
to securing the machines on your network.   
	I'm not certain whether they have information explicitly detailing all
of the details involved in firewalling, but this is a good start.  

Hope this helps,
-tom

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 18:52:09 GMT
From:      justice@moeng2.minc.umd.edu (Joseph R. Justice)
To:        comp.unix.ultrix,comp.sys.dec,comp.mail.sendmail,comp.unix.admin,comp.unix.misc,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Q: Experiences installing Sendmail, BIND on Ultrix 3.1, 4.2

Hello.  I am about to try to install the following software packages:

	BIND 4.8.3

	Sendmail 5.65c + IDA 1.4.4

on my MicroVAX II system running Ultrix 3.1.  Soon thereafter, I
expect to install them on DECstation 5000/200 and 2100 systems running
Ultrix 4.2 (soon 4.2a).  These are based on Berkeley 4.2.  I have
binary-only systems (e.g. no BSD or Ultrix sources beyond what's been
released onto the net.)  I am currently running OLDER versions of this
software (e.g. what DEC provided); I want to get up-to-date.

Before I attempt to actually *install* these packages (e.g. post
sucessful compilation, level 0 dump of everything, etc.), I'd like to
tap the collective experience of the net, and find out if there is
anything I need to know BEFORE installing these packages.  The
semi-shotgun approach to broadcasting this query is so that I have as
best a chance as possible to hear the one bit of information I *NEED*
to know.  I want to bring my systems into the "modern era", while
taking as little chance as possible of seriously breaking something.

I actively follow comp.unix.ultrix, and to a lesser extent
comp.unix.admin.  I *have* set followup to comp.unix.ultrix; however,
just in case, please make sure that NetNews posts go to
comp.unix.ultrix only, because I'm sure the other newsgroups I've
initially posted to don't really give a darn...  :-).  Of course, I
welcome private e-mail as well, and will summarize if it provides
information not otherwise posted to a newsgroup.

Thank you for your time.  I look forward to hearing from you.

-- 
Joseph R. Justice, Mgr., Engineering Computing Ctr. (ECOIL Lab)
School of Engineering, Morgan State University, Baltimore, MD  21239
Voice phone (410) 319-3695 or 444-7245; School of Engineering 319-3231
Pager: (410) 712-8052            Internet: justice@moeng2.minc.umd.edu

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 19:31:26 GMT
From:      ivar@ppc.ubc.ca (ivar jonsson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Translation of newline char. (RS to LF) in NCSA


I have a short question.

I am trying to utilize the NCSA FTP package to move files between a
QNX (real-time application UNIX) system to UNIX.

I am capable to connect the two systems and transfer files, but unfortunately
the QNX system has an RS as a new line character instead of the usuall LF or
CR/LF characters.

Can I change the translation of the characters in a simple way in FTP or do
I have to change some of the source programs and recompile the package?


Regards, Ivar


-- 

Ivar Mar Jonsson			E-mail: ivar@ppc.ubc.ca
Pulp and Paper Centre			Tel:  (604) 822-8567
University of British Columbia

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 92 20:54:13 GMT
From:      hunnic@ecsvax.uncecs.edu (Jeff Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip for old att system5 pc


 Hi All,

I have a faculty member here who has an old ATT 6300 running
Sys V unix version 2.1. I have been given the task of finding
some sort of tcp-ip package that will run on this platform. If
aanyone knows where I can find such an animal please email me
wwith the particulars. Thanks in advance.

-- 
Jeff Hunnicutt, UNC-Wilmington/Information Systems/Networks Manager
           Wilmington, North Carolina  "Unc by the Sea"
hunnic@uncecs.edu  hunnicutt@vxc.uncwil.edu hunnicu@seq.uncwil.edu
          "The rhythm of big generators, the music of machines!"

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Feb 1992 22:31:48 GMT
From:      R1503@vmcms.csuohio.edu (Wayne A. Hogue II)
To:        comp.protocols.tcp-ip
Subject:   Archie Client

Does anyone know where I can get the specs for an ARCHIE CLIENT?
 
 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Wayne A. Hogue II  aka  T G R                 r1503@vmcms.csuohio.edu
                                                tgr@asgard.csuohio.edu
Proud AMIGA Owner!                            bb493@freenet.cleveland.edu
 
"Let me tell you about heart ache and the loss of God,
 wandering, wandering in endless night." -JDM
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 92 00:45:01 GMT
From:      greggt@VAX1.CC.UAKRON.EDU (Gregg F. Thompson)
To:        comp.sys.encore,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Arrow keys work certain ways, won't work other ways.


I have access to an encore running UMAX System V Unix, running an office
automation package called MaxUsers from EDGE Systems.  On the initial Menu
and in their editor the arrow keys only work from terminals logging in from
annexes.  If you connect to the encore from a PC via telnet of some sort, or
from a sun system using telnet, the program "beeps" at you as if you typed
in something wrong.  It is also true from an NCD Xwindow terminal running their
xtelnet, and Humming Birds Xterm too.  On the PC I am running Beame & Whiteside.

The weird thing is I just installed the latest Beame & Whiteside and their
"telnet" now works with the arrow keys on the main menu.



Anyone have any ideas as to what is happening???
Please reply via mail or in comp.sys.encore






-- 
To live is to die, to die is to live forever;			GRegg Thompson
Where will you spend eternity?			     greggt@vax1.cc.uakron.edu


"Why can't people wait and see if there actually IS a problem before 
wasting a lot of time discussing a SOLUTION to it?" -- Paul Haeberli

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Feb 1992 01:13:01 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SLIP to SCO Unix SysV.3.2 - does it work?

Since SCO don't seem to have their own newsgroup, except for one for
Xenix, I have to try here. We are planning to hook PCs to a SCO SysV 3.2
Unix server ('386/25) over direct serial lines running SLIP, through
a multi-port serial board from Stallion Technologies. Does anyone have
any tales to relate about setting up the SCO box to do SLIP? I know
Interactive's implementation has a few problems (based on aa posting a
month or so here) - is SCO's any better?


Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Feb 1992 03:36:20 GMT
From:      mahesh@cis.uab.edu (B.G. Mahesh )
To:        comp.windows.x,comp.protocols.tcp-ip
Subject:   Looking for tips on increasing the screen size of tn3270 session

Hi !

I am using tn3270 to access some mainframe sessions which I would like 
to accessin more than 45 lines sessions. ie, I would like to use an xterm 
which has about53 lines or so. I know somebody does it thru mac.

BTW, I have access to source code, if thats important.

thanks a much
Please respond to jkshah@eos.ncsu.edu.


****************************
PS: I am posting this for a friend. I have set the REPLYTO environment,
    so if you use "r" to reply it *should* reach him automatically.
****************************
-- 
B.G. Mahesh                       Internet : mahesh@agnos.eng.uab.edu
System admin
Dept of Biomedical Engg
University of Alabama at Birmingham

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 92 04:13:57 GMT
From:      christos@dworkin.wustl.edu (Chris Papadopoulos)
To:        comp.protocols.tcp-ip
Subject:   where am I loosing packets?


	I was trying to measure the throughput that can be achieved
between two Sparc 2 machines when I observed a very strange behavior:
Although throughput would increase as expected as I increased the
socket buffer sizes, when buffers reached about 28 KBytes the throughput
begun to drop. It kept dropping as the buffers were made larger,
until it was down to 3 Mbps at 51 KBytes. Before this the throughput was
more than 8 Mbps! (very lightly loaded Ethernet, nothing else running on
the machine)
	To measure the thoughput I used simple client and server programs
timing the data transfer. A total of 10 Mbytes was transmitted for
the experiment. The Sparcs are running SunOS 4.1.
	It seems to me that some packets are being lost when the buffers
exceed a certain size. Any ideas where and why?

Christos.

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Feb 92 05:05:38 GMT
From:      Jaap Vermeulen <jaap@sequent.com>
To:        comp.windows.x,comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: X over IPX/SPX vs. TCP/IP ??

In <1992Feb14.152709.7044@rtpnc.epa.gov> jcook@ardneh.rtpnc.epa.gov (Jim Cook) writes:

>I'm curious if this can be done.  I'd rather not get into WHY
>anyone would want to, but are there technical limits that
>prevent it?

Not that I know of.  X is network protocol independent (it can at least
use TCP/IP and DecNet).

>I.E., Could I run X clients on a UNIX machine together with
>Portable Netware and use X server software on  DOS PCs with only
>the Novell protocol stacks?  Assuming the previous is technically
>possible, is there any software that can do it today?

The SYSV version of X11R4 was based on TLI (if you didn't have socket
emulation and if you had the time to fix the X source code).  Given
that portable netware on SYSV is also based on TLI I would say that it
should be rather easy to port X clients to IPX/SPX.  Of course I could
be overlooking something... :-)  I have no idea how hard it is to port
the X server to DOS using IPX/SPX...

Hope this helps,

	-Jaap-

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 92 05:32:24 GMT
From:      mcorn@dimona.lannet.hellnet.org (Michael Corn)
To:        comp.protocols.tcp-ip
Subject:   SLIP drivers needed

Where can I find the latest PD SLIP implementation for
Sun workstations?

Thanks
Michael Corn
mcorn@lannet.hellnet.org

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Feb 1992 06:54:04 GMT
From:      mjn@oregon.uoregon.edu (Mike Neuburger)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: NCSA 2.3.03 : Orchid VGA card causes lockup upon exiting

In article <2601@ub.d.umn.edu> ppollock@ub.d.umn.edu (Paula Pollock) writes:

>In article <117916@lll-winken.LLNL.GOV> mike@isg.llnl.gov (Michael E. Hummell) writes:
>>My friend was using NCSA Telnet 2.3.03 with no problems
>>using ega monitor.  Then he got a vga monitor and a "Prodesign VGA" video card
>>made by "Orchid Technology".
>>
>>PROBLEM:  He connects ok to a host, but when he logs out, the screen goes 
>>black, there's one beep, then the PC (a 386 clone) locks up.  Have to
>>CTRL-ALT-DEL to continue.
>>
 
>We are experiencing the same problem with NCSA Telnet 2.3.03 and two
>zeos computers with Hercules monochrome.  Any input would be appreciated.
 
>-------------------------------------------------------------
>  Paula Pollock        |   internet:  ppollock@ub.d.umn.edu
>  Information Services |   BITNET:    ppollock@UMNDUL 
>     University of Minnesota Duluth   Duluth, Minnesota
>--------------------------------------------------------------

There is a bug in the in the screen restore.  You can disable this by using 
the -n option (telbin -n -h c:config.tel <host>).

Mike Neuburger
Network Engineer
University of Oregon
Computing Center
Eugene, OR 97403
internet: mjn@oregon.uoregon.edu
bitnet: mjn@oregon

ps.

I am having a problem with NCSA 2.3.03 when you ftp back to your pc and then 
try to put a file the transfer crashes.  Is this being worked on or a patch.

Thanks in advance,

Mike

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 92 11:16:57 GMT
From:      saunders@hawk.nstn.ns.ca (Jim Saunders)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   PCNFS and Multiple IP Stacks

Hi

I would like to use PCNFS, while at the same time, use applications like
gopher and TRUMPET.  Has any one accomplished this?  I would like to
hear from you if you have!

I have looked at pktd.sys, but this does not seem to solve the problem.

I am currently exploring NDIS, but I am not sure this will solve the
problem either.

You can respond to me directly and I will post a summary to the list.

Thanks

Jim Saunders               Saunders@hawk.nstn.ns.ca
NSTN Customer Support      Phone: (902)-468-NSTN

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 18 Feb 1992 16:47:22 EST
From:      <PVJQC@CUNYVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Slip for Sparcstns with 4.1.1 ???

Hi,
        I hope this is an appropriate group for my qstn.  I have a
network about 15 suns (sparc1, ipcs, sparc2, sun 3s, etc).  These suns
are also on Internet.  I am thinking of having a dialin capability to
the Suns from home using PCs.  If my understanding is correct, following
are the two possibilites.
1)  Configure the serial-port on Suns for the dial-in modem  and that is it.
This can give me a terminal connection and kermit capability.
2)  Using 'Slip' have telnet/ftp capability over the serial port.

I am more interested in the SLIP option and want to know how do we go about
it?  Do we buy SLIP or is there a public-domain SLIP available for Suns?
Also, We have NCSA-telnet/ftp software running on PCs. I believe, it has
some support for SLIP.
Any information would be highly appreciated.
Thanks a lot.
-------

         *********************************************************
         *  PRASHANT V. JOSHI                                    *
         *  COMPUTER SCIENCE DEPARTMENT                          *
         *  CITY UNIVERSITY OF NEW YORK.                         *
         *  INTERNET ADDRESS: PVJQC@CUNYVM.CUNY.EDU,             *
         *  BITNET ADDRESS  : PRASHANT@QCVAX.BITNET              *
         *                                                       *
         *********************************************************


-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 92 12:36:11 GMT
From:      ipb@bnr.co.uk (Ian Beeby)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip for old att system5 pc

If you find sources to a tcp/ip package that will use serial ports (ie 
SLIP) please could you e-mail me?  I have an old SVR2 machine at home and
that has tcp/ip on it but alas, no slip.  I have some code which is derived
from KA9Q tcp/ip for the MS-DROSS PC but that relies on SVR3 system calls
that don't exist in SVR2 (eg poll()).  There seems to be no shortage of
code for SVR3+ but alas little for SVR2.  I have neither the expertise nor
the time to attempt a port directly.  End application here is Ham Radio.

Regards

Ian Beeby

G8OGJ

e-mail:	I.P.Beeby@bnr.co.uk

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Feb 1992 14:48:29 GMT
From:      andy@uis.com (Andy Edwards)
To:        comp.protocols.tcp-ip
Subject:   SLIP performance question


As the subject states, I am wondering about how well 9.6kps SLIP
performs with respect to a direct tty connection (i.e. UUCP) for
data transfer.  We did a small experiment with a very small file
and saw about 24kps throughput using FTP.  The same file went
about 6.8kps over UUCP.  This wasn't very scientific, but it was
unexpected.  Is this typical?

Any comments about the cost (in connect time) and performance of
9.6kps SLIP would be appreciated.


Thanks.



-- 
-----------------------------------------------------------------
Andy Edwards   *   Unix Integration Services   *  Urbandale, Iowa
EMAIL: andy@uis.com                         PHONE: (515) 254-3074

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 92 15:55:46 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   BSD ping source

Does anyone know of any archive where I can get a copy of the BSD ping source?
Thanx in advance.



Shikhar

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 92 08:50:07 -0800
From:      Ed.Wilts@BCsystems.Gov.BC.CA (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Archie Client

In article <16790F684.R1503@vmcms.csuohio.edu>, R1503@vmcms.csuohio.edu (Wayne A. Hogue II) writes:
> Does anyone know where I can get the specs for an ARCHIE CLIENT?
>  
Full source for Archie clients is available.  There was a VMS version recently
posted to vmsnet.sources and should be archived on cerritos.edu. 

-- 
        .../Ed     Preferrred:  Ed.Wilts@BCSystems.Gov.BC.CA
Ed Wilts            Alternate:  EdWilts@BCSC02.BITNET    (604) 389-3430
B.C. Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Feb 1992 23:09:29 GMT
From:      peterd@tscc2.macarthur.uws.edu.au (Peter Degotardi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.rt
Subject:   terminal servers. what and how.

We would like to setup a terminal server for our network.
What we'd like to know is, are terminal servers boxes that do nothing else,
or can we setup a unix box (specifically an ibm rt) to do this for us ?
If we can, is there any public domain/shareware software available?

Thanks in advance.
--
Peter Degotardi ( p.degotardi@uws.edu.au ) | Disclaimer: Any opinions expressed 
University of Western Sydney, Macarthur    | are my own, and may not reflect
Teaching and Services Computing Centre     | those of my employer or anyone
Campbelltown, New South Wales, Australia ! | else. (In case you're interested.)

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Feb 1992 09:13:55 -0500
From:      Mailer-daemon <postman+@andrew.cmu.edu> (Postmaster, Carnegie Mellon, Pittsburgh, PA)
To:        comp.protocols.tcp-ip
Subject:   Returned mail: No such destination mail domain

The following message from ``sb7c+@andrew.cmu.edu'' could not be
delivered to ``max@underg.UUCP'' because:
There is no such destination mail domain as ``underg.UUCP''.

The undelivered message follows:
----------------
Received: from sarnoff.ini.andrew.cmu.edu via qmail
          ID
</afs/andrew.cmu.edu/service/mailqs/q000/QF.cdcaKv600io=I0ZG12>;
          Wed, 19 Feb 1992 09:12:11 -0500 (EST)
Received: from sarnoff.ini.andrew.cmu.edu via qmail
          ID
</afs/andrew.cmu.edu/usr16/sb7c/.Outgoing/QF.YdcaKmO00io=0D9mF9>;
          Wed, 19 Feb 1992 09:12:03 -0500 (EST)
Received: from
VUI.Andrew.3.20.CUILIB.3.45.SNAP.NOT.LINKED.sarnoff.ini.andrew.cmu.edu.pmax.ul4
          via MS.5.6.sarnoff.ini.andrew.cmu.edu.pmax_ul4;
          Wed, 19 Feb 1992 09:12:02 -0500 (EST)
Message-ID: <YdcaKmG00io=8D9m87@andrew.cmu.edu>
Date: Wed, 19 Feb 1992 09:12:02 -0500 (EST)
From: Shikhar Bajaj <sb7c+@andrew.cmu.edu>
To: max@underg.UUCP
Subject: Re: Good Book on TCP/IP networking

Max,

   I have two suggestions

1)  INTERNETWORKING WITH TCP/IP (Vols I and II) by Douglas Comer (Prentice
    Hall Publishers).  If you are going to be working with the Internet
    protocols, these books (at least volume 1) are a must.  Volume I is
    more of a high level overview and goes into the principles and
    architecture of TCP, UDP, IP, ICMP, etc.  Volume 2 is essentially full
    of code (written in Xinu not C) for implementing a transport mechanism.
    This is helpful if you plan to hack system code in an administration
    capacity because you will have an idea of how the code basically works.

2)  UNIX NETWORK PROGRAMMING by W.Richard Stevens (Prentice Hall) is
    also something I would recommend because it explains how to access
    and use the various transport facilities at the application level.
    This book is more attuned to the network programmer so it may not
    necessarily be what you are looking for.

Hope this helps.


Shikhar

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

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 92 02:09:19 GMT
From:      alen@crash.cts.com (Alen Shapiro)
To:        comp.protocols.tcp-ip
Subject:   KA9Q/Telnet problem connecting to certain sites?

I'm an Apple-mac internet host connected to the internet via a fast(ish)
SLIP line. I can connect with my host and can access all the USA sites
for telnet and ftp. I can also access .de .isr .jp domains though these
tend to be a bit slower :). I have had NO sucess however connecting to
any uk sites. My internet host IS able to however. I get no response
at all from KA9Q pings to the uk (I do from other sites). What is stopping
my packets getting through to the uk?

Cisco's telnet says that it is trying to open the connection and times out.
KA9Q goes into a SYM-sent state from which it never returns.

The site I mostly use for testing is:

128.86.8.7 sun.nsfnet-relay.ac.uk

Is there any form of route testing I can do? Please note that my host site
(the one that I dial) CAN connect to the above test IP number.

tia for any help/advice

--alen

alen@crash.cts.com

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 92 06:47:52 GMT
From:      frank@rniwi.rni.sub.org (Frank Mogaddedi)
To:        comp.windows.x,comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: X over IPX/SPX vs. TCP/IP ??

In <1992Feb14.152709.7044@rtpnc.epa.gov> jcook@ardneh.rtpnc.epa.gov (Jim Cook) writes:

>I'm curious if this can be done.  I'd rather not get into WHY
>anyone would want to, but are there technical limits that
>prevent it?

Why not? It makes perfect sense for sites like ours, where we already
have TokenRing in all of our buildings. Now we start putting *nix
boxes in different locations. I don't think running an ethernet parallel
to the existing TR would make much sense. Novell 3.11 does already
do the routing for you as well as nfs, tcp/ip, print-servers etc.

>I.E., Could I run X clients on a UNIX machine together with
>Portable Netware and use X server software on  DOS PCs with only
>the Novell protocol stacks?  Assuming the previous is technically
>possible, is there any software that can do it today?

Portable Netware? I dunno! But w/ things like Lan Workplace for DOS
and PC-Xview, or HCL-eXceed I have a X-server running under DOS or
Windows and can fire up any X-client on any *nix-box. The only
difficulties you might have is the setup of network-addresses, since
you can't join physical nets into logical ones. That may result
in problems w/ broadcasts (rwho asks just _your_ net).

Otherwise I think it works like a charm.

Hope I could help you,
	Frank

-- 
+-----------------------------------------------------------------------------+
| e-mail: frank@rniwi.rni.sub.org | Disclaimer: "Read my lips" (George Bush)  |
|       If there are aliens watching us, why don't we hear them laughing?     |
|	  Beauty is only skin-deep, but ugliness goes clean to the bone	      |

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Feb 1992 15:21:19 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   wanted - RFC for SMTP return receipt

I am looking for the RFC that describes the implementation of return-receipt
for SMTP mail.  I have been told that it is not a part of the original SMTP
specification, but rather an add-on, optionally-supported feature.  I have
verified that it is not described in RFC 821 or 822.  I have looked in the
RFC index and didn't see anything there.  Can someone tell me the RFC #
that describes return receipt?

Thanks.
***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 92 15:55:02 GMT
From:      skaamjm@ucl.ac.uk (Matthew Moore)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET

jim@cs.strath.ac.uk (Jim Reid) writes:

>In article <1992Feb6.141740.11809@spider.co.uk> keith@spider.co.uk (Keith Mitchell) writes:
 
>   (I think the number of people whose *job* it is to run JIPS can be
>   counted on your fingers.)
 
>Close, but no cigar as they say. The staff employed by JIPS can be
>counted on the number of thumbs on one hand. The other folk working on
>JIPS are doing it in addition to their regular job - like running the
>JANET/Internet mail gateway or looking after the comms. kit on a
>campus or administering a bunch of machines.

The pilot wasnt called "Shoestring" for nothing, was it?

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 92 16:46:38 GMT
From:      Ed.Wilts@BCsystems.Gov.BC.CA (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Firewalls and connecting to Internet

In article <0dc0DF600WCs06KERL@andrew.cmu.edu>, tjh+@andrew.cmu.edu (Tom Holodnik) writes:
> Andy,
> 	You might avail yourself to online documentation on cert.sei.cmu.edu
> (192.88.209.5).  FTP anonymously and you will find information related
> to securing the machines on your network.   
> 	I'm not certain whether they have information explicitly detailing all
> of the details involved in firewalling, but this is a good start.  

You can also FTP to research.att.com and get Cheswick's paper entitled
"Designing a Secure Internet Gateway".  It's in the /dist directory.
It's an excellent paper and was scheduled to be presented at last week's Decus
conference in Calgary; unfortunately Bill Cheswick didn't make it.

-- 
        .../Ed     Preferrred:  Ed.Wilts@BCSystems.Gov.BC.CA
Ed Wilts            Alternate:  EdWilts@BCSC02.BITNET    (604) 389-3430
B.C. Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Feb 1992 17:49:44 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   IBM MVS TCP/IP (again)

There have been several queries recently about IBM MVS TCP/IP solutions.
A few knowledgeable people have replied to these queries.  I would like
to ask some questions about this subject to anyone who knows about it.
I have tried posting a message to a Bitnet mailing list called IBM-NETS
but have not gotten any response.  If you are knowledgeable about IBM MVS 
TCP/IP solutions and have a few keystrokes to spare, can you e-mail me?

Thanks in advance.
***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Feb 1992 18:42:35 GMT
From:      berry@hawking.pei.com (Berry Kercheval)
To:        comp.windows.x,comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: X over IPX/SPX vs. TCP/IP ??

>>>>> On 18 Feb 92 05:05:38 GMT, jaap@sequent.com (Jaap Vermeulen) said:
Jaap> In <1992Feb14.152709.7044@rtpnc.epa.gov> jcook@ardneh.rtpnc.epa.gov (Jim Cook) writes:

Jim>I'm curious if this can be done.  I'd rather not get into WHY
Jim>anyone would want to, but are there technical limits that
Jim>prevent it?
Jaap> Not that I know of.  X is network protocol independent (it can at least
Jaap> use TCP/IP and DecNet).

X can use any reliable bytestream protocol.  Besides tcp/ip and
DecNet, implementations using shared memory (DecStation 5000), unix
domain sockets (MIT sample server) and RS232 serial lines (NCD X
terminals) exist -- why not Novell?  (That list is not intended to be
complete!)

Jim> Assuming the previous is technically
Jim>possible, is there any software that can do it today?

Not that I know of, but what does that mean?

Jaap>I have no idea how hard it is to port
Jaap> the X server to DOS using IPX/SPX...

Porting the X server to DOS using ANY net interface is a pain in the socket!
I did it once and have absolutely no desire to ever get involved in anything
like it again.

  --berry


--
Berry Kercheval :: Protocol Engines Inc :: berry@pei.com
"One of the main advantages of Unix over, say, MVS, is the tremendous number 
of features Unix lacks." -- Chris Torek
"Fixed in SVR4" -- USL

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1992 22:58:50 GMT
From:      sob@tmc.edu (Stan Barber)
To:        comp.periphs.printers,comp.protocols.tcp-ip
Subject:   Device implementing lpd protocol for placing printers on the net

I am looking for a device that attaches a serial or parallel printer to the 
network and looks like an lpd host to a client. I am aware of certain
devices of this ilk:
	PC-NFS 3.5c supports the lpd protocol using a TSR.

	Microplex has something called the M200. I am unsure if this
	actually supports lpd. I think not from the literature.

	MiLAN also has a similiar device called FastPort, Model 3000.
	Again, I think it does not do lpd.

	Novell's NFS services comes bundled with a lpd NLM to allow
	access to Novell queues. (Why Novell will not sell this
	seperately is a mystery to me....)

	There are a number of devices like this for Novell.

	Of course, we know about printer support in appletalk.

Have I missed something? PD is ok if source is available and it works.
Commericial is good.

Send me mail and I will summarize.

Thanks

-- 
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: rutgers!bcm!sob             and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Feb 92 01:46:42 GMT
From:      keithr@sco.COM (Keith Reynolds)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for SCO UNIX

You are Dan Ellison <dan@dribble.c-mols.siu.edu>.
You are standing in article <dan.697815502@dribble>.
There are comments here.
> 
> In <1992Feb6.205819.25188@ncsa.uiuc.edu> billp@ncsa.uiuc.edu (Bill Pottenger) writes:
> 
> >In article <1992Feb6.184011.5083@cherokee.uswest.com> dir@lookout.uswest.com (Daniel I. Rosenblatt) writes:
> >>In article <1992Feb5.131157.2530@arizona.edu>, jdc@mojave.ece.arizona.edu (Jo Dale Carothers) writes:
> >>> I need SLIP software that will run on 386 or 486 based PC's that
> >>> are running SCO UNIX.  Does this software exist?  If so, where can
> >>> I find it.
> >>
> >>You must have the TCP/IP Runtime package from SCO.
> >>Then, as root, do 'mkdev slip' and answer the questions.
> >>You might also need to do 'mkdev tcp' and/or 'mkdev streams'
> >>The documentation with TCP/IP Runtime will say.
 
> >There is also a PPP/SLIP implementation available from Morningstar.  I've
> >been told that it works well under SCO unix.  Email to jamey@morningstar.com.
> >Bill
> 
> And don't forget about ka9q.  Doesn't require the tcp/ip package,
> supports slip and rip and is well developed....

The next release of SCO TCP supports PPP, and has some performance
improvements in SLIP, including the Van Jacobsen modifications.  I
don't know the official release date, but it should be out RSN.

-- 
Keith Reynolds, Software Engineer, The Santa Cruz Operation, Inc.

keithr@sco.COM, @uunet.UU.NET:keithr@sco.COM, keithr%sco.COM@uunet.UU.NET
{uunet,decvax,sun}!sco!keithr

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 03:05:01 GMT
From:      rick@ut-emx.uucp (Rick Watson)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   MacSLIP beta testing

I need a few good beta testers for MacSLIP.  Yes, that's right,
MacSLIP for MacTCP.  I'm specifically looking for people
who will give it a good test with virtual memory and 32 bit mode
as well as a wide variety of SLIP implementations (on the other
end) and MacTCP applications.

In order to forestall 10,000,000 questions showing up in my mail
tomorrow, here are some details about MacSLIP:

- It does support TCP Header Compression (CSLIP).
- It does not support PPP (yet).
- It will not be freeware but it won't be too expensive either.
  I'm working on a couple of options for distribution.
- It supports a connection script for dialing the phone, logging in, etc.
- It currently requires System 7.  Also MacTCP 1.1.
- I've tested it with a fairly wide range of applications that use MacTCP
  including NCSA Telnet, MacX, XferIt, Intercon's NFS/Share, Eudora, 
  and TheNews. Sorry for any misspellings. Some of the above may be 
  trademarks.
- It has been tested on several machines including a Mac II, IIfx,
  Powerbook 140, and SE/30.

The only serious known problem right now is really a MacTCP problem.
MacTCP has problems with its timers across slow links, not restricted
to SLIP links. Hopefully, Apple will release a fix for this someday.
Meanwhile, you will probably see lots of retransmitted packets when
sending data from the Mac to another host over a slow link. 

I only need a few beta testers.  If there are no major problems
encountered, I hope to go into full distribution in a few weeks -- but
please don't bug me if my schedule, er, slips. :-) I have a full time
job that doesn't include developing MacSLIP, plus I have other
consulting contracts. 

If you think you would be a good beta test candidate, tell me why.
I'll reply to those who I think will be good sites.  Otherwise, thanks
in advance for your interest.  I may not have time to answer all the
mail I'm likely to get.  It is my goal to be able to deliver a solid
product as soon as possible. I know that lots of people out there are
impatient to be able to use MacTCP over a SLIP link.  I was impatient
enough to spend lots of long nights writing and debugging code. 

Please, please address all electronic correspondance to:

  macslip@utexas.edu

Rick Watson
The University of Texas at Austin


-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 06:58:01 GMT
From:      bob@pta.pyramid.com.au (Bob Vernon)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin protocol description.

In article <1992Feb17.031735.12391@pta.pyramid.com.au> I wrote:

>I have been reading this group, ftp'ing various RFCs and even reading
>source code.  But nowhere can I find a description of the rlogin
>protocol.  If anyone could point me to somewhere that has a low-level
>description of rlogin, I'd be grateful.  Note that this is the protocol
>used by the Unix rlogin program, not telnet which is described in its
>rfc as a "protocol for remote logins".

Thanks to everyone who replied.  There were some requests for a
summary, so just in case I missed anyone, here it is :-

Up until late last year, rlogin was documented purely by the source.
No source, then no documentation.

RFC1258 by Brian Kantor was issued in September, 1991.  This describes
the existing usage of the protocol.

RFC1282 superceding RFC1258 was issued in December, 1991.  The only
differences are in the window size negotiation.  I think the original
rfc was incomplete.

However the best description I found of rlogin is in "UNIX Network
Programming" by W. Richard Stevens, Prentice-Hall 1990,
ISBN-0-13-949876-1.

This was recommended to me by a few people (including the author,
thanks Rick).  I'd like to say to anyone doing anything with Unix
networking, to first look in here.  It has a mine of useful
information and explains many concepts very well.  Not to mention the
source listings.


>My specific problem is that I have two systems that talk quite well via
>rlogin.  But whenever the remote side switches from cooked to raw mode,
>the terminal side receives three single character packets (0x80, 0x90
>and 0xA0).  These are displayed on the screen instead of being
>interpreted as rlogin commands.  I'd appreciate any suggestions at all
>about what is happening here.

I almost described this problem right but not quite.  At connection
time the server (in this case a Pyramid running OSx) issues a Window
size request (0x80) as out-of-band data as the very first packet after
connection.  If it doesn't get a response to this then all other o-o-b
requests are OR'd with 0x80 until the client responds.  So 0x90 is
Request Client to switch to Raw mode (0x10|0x80) and 0xA0 is Request
Client to resume local processing of control-S and control-Q
(0x20|0x80).  This is all as the source, the rfc's and Stevens say is
correct.

When the client receives the Window size request it should send window
information to the server in a "magic" packet.  But some clients don't
seem to understand Window size requests (I could name at least 2).  Not
only that but instead of throwing away o-o-b requests they don't
understand (as commonsense and everyone else suggests is correct), they
display the requests as data.

If you have one of these brain-dead clients the symptoms are that
immediately before the first server display (usually the Password
prompt) you will see a couple of unexpected characters :-

- On a vt100 (which strips the 8th bit) character set, you get NUL,
DLE, SPACE, which isn't too bad.

- On a wyse (which strips the 8th bit) character set, you get NUL, some
box drawing character, SPACE, which is annoying.

- On a PC or a terminal using the IBM character set you will see the
european characters C-cedilla, E-accent, a-accent, which is very
annoying.

- On a vt220 character set you get some character sequence which
clears the screen and locks the keyboard, which really pisses me off.

You also see some these characters (or symptoms) at each switch into
and out of raw mode.  The two solutions to this problem are :-

1.  Fix the client.  (Usually not practical).

2.  Hack the Unix rlogind source.  This is really yuck as it means that
the server will not handle window resizing anymore.  But it is a
one-line change to stop the window-resize request and if none of the
clients handle window sizing anyway then this is a simple solution.



Bob V!

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 07:34:02 GMT
From:      stullich@quando.quantum.de (Thomas Stullich)
To:        comp.protocols.tcp-ip
Subject:   Re: Time out on name service

If you are able to recompile your application, which tries to ask the
nameserver, you should examine resolv.h and change the definition

#define RES_TIMEOUT	5	/* min. secs between retries */

Probably it would solve your problem.


-- 
Thomas Stullich
  Quantum GmbH  Bitnet: stullich%quando@UNIDO(.bitnet)
    Dortmund    Internet: stullich@quantum.de OR
    Germany     Internet: stullich%quando.uucp@mail.Germany.EU.net

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 20 Feb 1992 16:23:18 EST
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP (again)

In article <1992Feb20.181635.75544@watson.ibm.com>, rubin@watson.ibm.com (Bill
Rubin) says:

>In <1992Feb19.174944.14341@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU
>(Robin Goldstone) writes:
>> (...)
>I strongly recommend subscribing to the Bitnet LISTSERV list
>IBMTCP-L@PUCC.PRINCETON.EDU (to subscribe, send a note to
>LISTSERV@PUCC.PRINCETON.EDU, with the first line of mail as "SUBSCRIBE your
>name".  (...)
>the development group monitors and actively participates in it.

Notebook archives (IBMTCP-L LOGyymm) go back to 8901 at that site.

/Pete
--
Peter M. Weiss                     | pmw1 @ PSUADMIN  |  psuvm.psu.edu|psuvm
31 Shields Bldg - PennState Univ.  | not affiliated with psuvm.psu.edu|psuvm
University Park, PA USA 16802-1202 | A hexadecimal kindof guy in a decimal world

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 13:16:32 GMT
From:      jpretty@casbah.acns.nwu.edu (Jon Prettyman)
To:        comp.protocols.tcp-ip
Subject:   Looking for POP Server for SCO Xenix

Can some point me to a POP 2 or 3 server for SCO Xenix.  I have tried
porting the BSD sources from UUNET, but Xenix is too strange to make
it easy.

Thanks,

Jon
------
Jon Prettyman                               jpretty@casbah.acns.nwu.edu
Peapod Delivery Systems                                  1(708)866-1813
1840 Oak Avenue
Evanston, IL  60201

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 13:39:11 GMT
From:      syj@ecmwf.co.uk (Jean-Philippe Martin-Flatin)
To:        comp.protocols.tcp-ip
Subject:   Re: Good Book on TCP/IP networking

In article <N8oBgB1w164w@underg.UUCP>, max@underg.UUCP (Max Cray) writes:
<*>  
<*> Can someone recommend a good book, on tcp/ip networking from a 
<*> users/sysadmin's (not programmer's) point of view? Please e-mail replies. 
<*> Thank you.

W. Richard Stevens, "UNIX Network Programming", Prentice Hall
ISBN 0-13-949876-1 

/----------------------------------------------------\
| Jean-Philippe Martin-Flatin                        |
| European Centre for Medium Range Weather Forecasts |
| Shinfield Park                                     |
| Reading RG2 9AX                                    |
| England                                            |
|----------------------------------------------------|
|  Disclaimer: I speak for myself, not my employer   |
\----------------------------------------------------/

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 14:11:50 GMT
From:      rh0083b@medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Novice TCP-IP help

A friend of mine wants to start with TCP/IP. He is the system manager of
a VAX with TCP/IP. He would like some literature to introduce him to the
world of TCP/IP basics, configuration and management. I could of course
give him the RFCs but he sure won't like those... Any pointers?

Sorry if this in an FAQ (I guess it *must* be)....

-Roger

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Feb 1992 16:34:31 GMT
From:      sfb@NCoast.ORG (Stephen F. Bush)
To:        comp.protocols.tcp-ip
Subject:   Host independent application routing


I am looking for the "most standard" solution to the following problem.

Assume there is a LAN with a variety of applications. Users access
applications through a terminal server. Is there a standard mechanism
for connecting the user from the terminal server to the application he
requests. The mechanism should be independent of which host the application
happens to reside on.  It should also be fault resistant, i.e. not
depend on a single host to route the user to the application. It would
also be nice if it took load balance into account, i.e. if one 
application is on more than one host, send the user to the host with
the least load.

I suppose X.500 may provide a standard solution, but I'm wondering
if there is any IP protocol standard which would solve this problem. 

How do most people do this ?
How do you maintain security with the mechanism used ?

Any information would be appreciated !

					Thanks,
					Steve Bush
					GEIS

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 22:46:29 EST
From:      "bernard guillaumot" <bernard.guillaumot@channel1.com>
To:        comp.protocols.tcp-ip
Subject:   tcp/ip and as/400

Hello,

Does anyone can tell me if there is a IBM 5250 emulation product
over TCP/IP ... for PATHWORKS (DEC), LAN WORKPLACE (NOVELL) or
any other products (OS/2 or OS/2 DOS/BOX) ?

Help greatly appreciated.

Thanks.

Bernard  GUILLAUMOT
--
+-----------------------------------------------------------------------+
| T.N.I.S. Consultants - 35, Rue des Longs Pres - 92100 Boulogne FRANCE |
| Phone : (33) 146-082-527 - Fax : (33) 146-213-673 - 48 50 N / 2 20 E  |
|            Telecommunications - Networking consulting group           |
 +-----------------------------------------------------------------------+
|UUCP    :  Bg@tnis.frmug.gna.tfd.com                          (France) |
|Path    :  .....!tdf.com!afp!gna!frmug!tnis!bg                         |
|                                                                       |
|Email   :  Bernard.Guillaumot@f7.n320.z2.fidonet.org          (France) |
 +-----------------------------------------------------------------------+
|US EMail:  Bernard.guillaumot@Channel1.com                    (USA)    |
+-----------------------------------------------------------------------+

 * SLMR 2.1a * 
--
Channel 1 (R)   Cambridge, MA


-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Feb 1992 18:16:35 GMT
From:      rubin@watson.ibm.com (Bill Rubin)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP (again)

In <1992Feb19.174944.14341@ecst.csuchico.edu> rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone) writes:
> There have been several queries recently about IBM MVS TCP/IP solutions.
> A few knowledgeable people have replied to these queries.  I would like
> to ask some questions about this subject to anyone who knows about it.
> I have tried posting a message to a Bitnet mailing list called IBM-NETS
> but have not gotten any response.  If you are knowledgeable about IBM MVS
> TCP/IP solutions and have a few keystrokes to spare, can you e-mail me?

I strongly recommend subscribing to the Bitnet LISTSERV list
IBMTCP-L@PUCC.PRINCETON.EDU (to subscribe, send a note to
LISTSERV@PUCC.PRINCETON.EDU, with the first line of mail as "SUBSCRIBE your
name".  This is the list devoted to IBM TCP/IP for VM, MVS and OS/2, and
the development group monitors and actively participates in it.

Bill Rubin
IBM TJ Watson Research
rubin@watson.ibm.com

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 18:27:30 GMT
From:      jchen@ctt.bellcore.com
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Measuring transit delay between asynchronized systems

Hi,

I am trying to develop a utility to measure the network transit delay between asynchronized systems.
The network connecting the end systems is a packet switched network and therefore exhibits varible
delays.  The key issue is to estimate the time difference between the two systems to the milisecond.

I understand that  "ping" provides round trip delay measurements, but  I would like to get measurements
for each direction of transmission.

I would appreciate any information on
   1) existing tools
   2) ideas to do it
   3) references to published papers.

Thanks in advance.
  
-- 
C. Jason Chen
jchen@ctt.bellcore.com

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 19:51:17 GMT
From:      Lyle_Seaman@transarc.com
To:        comp.windows.x,comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: X over IPX/SPX vs. TCP/IP ??

frank@rniwi.rni.sub.org (Frank Mogaddedi) writes:
> In <1992Feb14.152709.7044@rtpnc.epa.gov> jcook@ardneh.rtpnc.epa.gov (Jim Cook)\
>> [ "Is it technically possible to convert X to use IPX/SPX, and does
>>    such a thing currently exist?" ]
>>
> Why not? It makes perfect sense for sites like ours, where we already
> have TokenRing in all of our buildings. Now we start putting *nix
> boxes in different locations. I don't think running an ethernet parallel
> to the existing TR would make much sense. Novell 3.11 does already
> do the routing for you as well as nfs, tcp/ip, print-servers etc.

clue:
You can run TCP/IP over damn near any kind of network hardware.
There's no reason to "run an ethernet parallel to the existing TR"

clue:
"Novell 3.11" does not equal "IPX/SPX"

> >I.E., Could I run X clients on a UNIX machine together with
> >Portable Netware and use X server software on  DOS PCs with only
> >the Novell protocol stacks?  Assuming the previous is technically
> >possible, is there any software that can do it today?
> 
> Portable Netware? I dunno! But w/ things like Lan Workplace for DOS
> and PC-Xview, or HCL-eXceed I have a X-server running under DOS or
> Windows and can fire up any X-client on any *nix-box. The only
> difficulties you might have is the setup of network-addresses, since
> you can't join physical nets into logical ones. That may result
> in problems w/ broadcasts (rwho asks just _your_ net).
> 
clue:
Lan Workplace is not "only the Novell protocol stacks".   You may
think so, since it's (now) a Novell product, but nonetheless, that's
TCP/IP under there, which is not a "Novell protocol stack".

X will not run over IPX directly, no matter what you do to the X
server, short of implementing another protocol.
SPX is a reliable stream protocol.  X could run over it.  SPX sucks.

SPX as implemented in the Portable NetWare streams stacks will be very
slow - even slower than as implemented on DOS.  

Don't do this if you really intend to use the X server for anything.

If memory is a problem, and you really can't run the multiple protocol
stacks simultaneously, you've got two choices:
1.  Stick with Messdos and buy some "memory-manger" and/or DesqView
2.  get a real OS.

Lyle.
[ my employer is not responsible for my attitude ]

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 92 22:12:01 GMT
From:      tvf@cci632.cci.com (Tom Frauenhofer)
To:        comp.protocols.tcp-ip
Subject:   Broadcast Examples

I'm trying to implement a routine to periodically broadcast some status
information to other workstations.  I've tried various tricks to get this to
work, but I can't seem to get anything to work (this includes using
setsockopt() to set SO_BROADCAST on).  And, yes, I have tried referring to
the various MAN pages, the Steven's book "Unix Network Programming", and the
4.3BSD Design book by Leffler and group.

Does anyone have any ideas/code samples that work?  Is there something
subtle I'm missing?

Thanks in advance.
--
Thomas V. Frauenhofer, WA2YYW, tvf@cci.com, ...!uunet!uupsi!cci632!tvf
tvf1477@ma.cs.rit.edu
Waitress: "Do you want me to cut your pizza into 6 or 8 pieces?"
Yogi Berra: "6.  I don't think I can eat 8."

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 01:50:08 GMT
From:      mills@engin.swarthmore.edu (Patrick Mills)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Apple LocalTalk TCP/IP

HELP!
	Does anyone understand / know how to program the Apple LocalTalk PC card to
reach internet addresses?  I have read Inside AppleTalk, LocalTalk manual, and the
Inside Macintosh file on the AppleTalk Manager, but none of them seem to discuss this
problem.  I have gathered that I need to open a socket to a gateway using socket (hmm.)
I think its 78...anyway, once that's open and I've registered myself with NBP on the
same socket number, how do I access the Internet?  How does one use the ipgp structure?

Any information about where to find sample code (I already have the LOCALTLK packet
driver source) would be helpful, or sample code (C would be nice, but ANY code would
be great!), or comments about the whole process would be greatly appreciated.

Please E-MAIL to mills@engin.swarthmore.edu.

Thanks in advance...
						-Pat


-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 11:41:33 GMT
From:      hooper@ccs.QueensU.CA (Andy Hooper)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP (again)

In article <1992Feb20.181635.75544@watson.ibm.com>, rubin@watson.ibm.com
 (Bill Rubin) writes:
| IBMTCP-L@PUCC.PRINCETON.EDU (to subscribe, send a note to
| LISTSERV@PUCC.PRINCETON.EDU, with the first line of mail as "SUBSCRIBE your
| name".

That should be
    subscribe ibmtcp-l your name

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 92 12:09:02 GMT
From:      shaman@cix.compulink.co.uk (Leo Smith)
To:        comp.protocols.tcp-ip
Subject:   re: LPD on PC.


Commercial DOS products supporting LPD protocol:
        PC/TCP (Ftp Software)
        PC-NFS (Sun Microsystems)
        Beame & Whiteside.

All these work, but all have problems: The most serious of these
problems is DOS itself: Imagine - DOS is busy spooling to the
printer, deep in the BIOS, and a new print job comes in. Net result -
not able to service incoming job correctly - Crashed PC or lost job.

Best results are using proper multi-tasking operating system with
decent deviec drivers. Unix is GREAT, but too expensive.

OS/2 works like a charm. Use FTP's PC/TCP for OS/2.
I believe IBM's may work as well.

This combination will give you RELIABLE spooling from multiple hosts
to multiple printers, at reasonable cost, and you get much better
error messages back from the printers etc. You can even telnet into
the OS/2 machine if it is in trouble.

Other possible solutions involving Windows 3.0 and one or other of
the DOS products mentioned might work, but I would prefer to stick to
OS/2 until NT comes along.

Leo

Disclaimer: The above is the result of prejudice gained over a long
period of time with the described scenarios.

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 16:15:31 GMT
From:      ava@bcrka486.bnr.ca (Anthony VanAlphen 1572587)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP Socket routines for MAC

I am looking for routines that can be included in MPW code for TCP
socket i/o from a MAC runnning AppleTalk or Ethernet.
--
-------------------------------------------------
Anthony Van Alphen          Phone: (613) 763-5101
BNR Power Group             Mail:  ava@bnr.ca
-------------------------------------------------

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 16:45:58 GMT
From:      norm@b8.ingr.com (Norm Howe)
To:        comp.protocols.tcp-ip
Subject:   Ethernet address

A quick question, does anyone out there know what vendor
owns the ethernet address block 08-00-34-xx-xx-xx? I've
looked through all my lists and I can't identify the owner.
 If you identify the owner, email me at norm@ip4551.b8.ingr.com,
and thanks in advance.

Norm Howe at Intergraph Corporation


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 92 18:13:48 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Getting connected in Camden


	I have been asked to help set up a network for somebody in Camden,
NJ, probably including a connection to The Internet.  What are my choices
for vendors for an Internet connection there?  I've already got PSI and
UUNET on my list to ask for quotes, but is there anybody else I should
investigate?  I'm expecting their needs will be served by a 56k, or maybe
even a 19.2k circuit.
-- 
roy@alanine.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 92 19:05:16 GMT
From:      GREELY@KGNVMA.VNET.IBM.COM ("Charles Greely")
To:        comp.protocols.tcp-ip
Subject:   TCP options field

Greetings, I have a question about the TCP header options field. If anybody
can answer this or point me in the right direction, I'd appreciate it. Here it
is: Is the use of the options field only limited to the maximum segment size,
end of option list and no-op options? In other words, can an implementation use
this field for anything it wants? And, by the way, is there a rule on how
implementations should respond to unknown options? The implementations I see
seem to ignore them. Thanks for any help I receive.
Charles B. Greely

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 92 20:28:28 GMT
From:      bloomer@rodson.crd.ge.com (John Bloomer)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   source code for _Power Programming with RPC_ now on ftp.uu.net

The source code for the new book _Power Programming with RPC_ (an
O'Reilly & Assoc.  Nutshell Handbook) is available at the ftp.uu.net
archive as /nutshell/rpc/rpc.tar.Z.

Table of Contents
____________________________________________
Preface
Chapter 1:  Introduction to Remote Procedure Calling
Chapter 2:  Network Computing Today
Chapter 3:  Developing High-level RPC Applications
Chapter 4:  Protocol Compiling and Lower-level RPC Programming
Chapter 5:  UNIX Networking and Interprocess Communication
Chapter 6:  Application Development: Networked Parallel Image Processing
Chapter 7:  Distributing Existing Applications
Chapter 8:  Managing RPC Servers
Chapter 9:  Multiple Clients  and Servers
Chapter 10:  RPC Under Windowing Systems
Chapter 11:  ONC Transport-independent RPC
Chapter 12:  Advanced Programming Issues
The ONC RPC Programming Reference
  Section One:  ONC XDR Library Routines
  Section Two:  ONC Portmap Library Routines
  Section Three:  ONC RPC Library Routines
  Section 1:  ONC XDR Library Routines
  Section 2:  ONC Portmap Library Routines
  Section 3:  ONC RPC Library Routines
Appendix A:  Obtaining RFCs (Internet Standards, Request for Comment)
Appendix B:  An RPC Case Study: Networked Ray Tracing
Appendix C:  Generalized Server Initialization, Inquiry, and Removal
Appendix D:  Parallel Processing In A Nutshell
Appendix E:  Buzzwords: A Glossary
-- 
 **
John J. Bloomer <jbloomer@crd.ge.com, uunet!rodson.crd.com!bloomer >
voice: (518)387-6964	fax: (518)387-7332
KWC317, General Electric Corporate Research and Development

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 21:33:30 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP options field

In <9202211909.AA17432@ucbvax.Berkeley.EDU> GREELY@KGNVMA.VNET.IBM.COM ("Charles Greely") writes:

+>Greetings, I have a question about the TCP header options field. If anybody
+>can answer this or point me in the right direction, I'd appreciate it. Here it
+>is: Is the use of the options field only limited to the maximum segment size,
+>end of option list and no-op options? In other words, can an implementation use
+>this field for anything it wants? And, by the way, is there a rule on how
+>implementations should respond to unknown options? The implementations I see
+>seem to ignore them. Thanks for any help I receive.
+>Charles B. Greely

	I think the accepted way of dealing with unknown options is to 
ignore them.  If you write an option that modifies the behavior of both
sides of the connection, what you want to do is have some sort of option
negotiation between the two sides before altering behavior in accordance
with the option.
	There are other tcp options in use.  The ones I know of are related
to high performance networks and are outlined in one or two RFC's.  They
are the ECHO option, the WINDOW SCALE option, and the selective ack (SACK)
option.

	There may be some new ones related to security as well, but I can't
say.  I also can't remember if there is an RFC that lists which ones are
taken.  If you want to play around with options, I would suggest picking a
medium-high option number and/or making the first data byte of your option
a "flag" that indicates it really is "your" option rather than someone elses.





-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 92 21:38:32 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP options field

In article <9202211909.AA17432@ucbvax.Berkeley.EDU> GREELY@KGNVMA.VNET.IBM.COM ("Charles Greely") writes:
>And, by the way, is there a rule on how
>implementations should respond to unknown options? The implementations I see
>seem to ignore them.

Here is the relevant section from rfc1122:

            A TCP MUST be able to receive a TCP option in any segment.
            A TCP MUST ignore without error any TCP option it does not
            implement, assuming that the option has a length field (all
            TCP options defined in the future will have length fields).
            TCP MUST be prepared to handle an illegal option length
            (e.g., zero) without crashing; a suggested procedure is to
            reset the connection and log the reason.

Expermental options have been defined for such things as larger windows and
round-trip timestamps.  There is no real reason that you can't define one for your
own use, but you should try to avoid type numbers that have already been used.
RFC1072 defines options 3 through 7. RFC1146 defines options numbered 14 and 15.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 21:52:04 GMT
From:      harlan@plus5.com (Harlan Stenn)
To:        comp.protocols.tcp-ip
Subject:   PPP + Dialupip2.0?

Has anybody taken DialupIP2.0 and replaced the SLIP parts with PPP?

I've been trying to get DialupIP 2.0 (patch 1) running on two machines
and while I can the the connection established, I'm unable to actually
get packets to pass correctly through both sides of the connection.

I weas hoping that somebody has taken the current PPP release (which
seem to do a better job of moving packets around) and hacked the
call management portion of Dialup IP to work with it.

If anybody has this, I can make it available for public FTP on wuarchive.

Thanks...
-- 
Harlan Stenn  +1(314)230-8847

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Feb 1992 23:06:47 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   sockets (global or local) VMEexec VNE tasks UNIX process

I am working on software project where multiple tasks share the same socket.    The socket is SOCK_DGRAM and AF_INET.  If I only have one task, I can perform   sendto and recvfrom without a problem.  If I have two tasks, and the task that  created the socket sends the socket to another task(via ipc), that task can not communicate over that socket.  Are sockets local to a task? If I do a bind or a connect will the status of the socket change.  Can I then share it and does it become global?
If no-one knows these answers in VMEexec please answer the question in terms of UNIX sockets and processes 

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 92 02:23:42 GMT
From:      oscar@dobag.in-berlin.de (Carsten Tschach)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Geting raw tcp/ip packages on a sun

Hi,

I'm looking for a c-language function, library or module to read ALL (!)
packets (tcp/ip, decnet, appletalk etc.) on the net.


Thanks a lot for your answer, Carsten (tschach@math.fu-berlin.de)

-- 
/ Carsten Tschach, Stanzer Zeile 21             tschach@opal.cs.tu-berlin.de  \
| 1000 Berlin 45,  Voice: +4930-7110990         tschach@math.fu-berlin.de     |
|                                                                             |
\             Saterday night - the loneliest night in the week !              /

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Feb 1992 03:34:33 GMT
From:      R1503@vmcms.csuohio.edu (Wayne A. Hogue II)
To:        comp.protocols.tcp-ip
Subject:   Re: Good Book on TCP/IP networking

In article <N8oBgB1w164w@underg.UUCP>
max@underg.UUCP (Max Cray) writes:
 
>
>Can someone recommend a good book, on tcp/ip networking from a
>users/sysadmin's (not programmer's) point of view? Please e-mail replies.
>Thank you.
>
>
Try 'Internetworking with TCP/IP vol. 1; Principles, Protocols, and
Architecture'  -Douglas E. Comer
 
 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Wayne A. Hogue II  aka  T G R                 r1503@vmcms.csuohio.edu
                                                tgr@asgard.csuohio.edu
Proud AMIGA Owner!                            bb493@freenet.cleveland.edu
 
"Let me tell you about heart ache and the loss of God,
 wandering, wandering in endless night." -JDM
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1992 16:59:13 -0800
From:      jamin@caldera.usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   New Release of tcplib

Hello,

There is a new version (0.9) of tcplib on jerico.usc.edu 
(128.125.51.17), under ~ftp/pub/jamin/tcplib.

The differences between this version and the previous version are:
    - Two bug fixes.
    - Uniform use of lrand48() in place of random().
    - Addition of telephone (voice) conversation characteristics.
    - Addition of application breakdown characteristics.
    - A more descriptive tech report.  Among other things, the tech
      report shows how to use the traffic application breakdown to 
      derive a simple conversation arrival model.
If you use the old version of tcplib, you want to get the new version 
if just for the bug fixes.  And if you do use tcplib, please send us
your e-mail address to expediate future bug fixes.

Following is the orginal release note of tcplib.  The papers 
[Caceres91] and [Danzig92] cited in the tech report are also available
for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/traffic. The file
traffic.ps.Z is for [Caceres91] and the files journal.part[1-4].ps.Z 
are for [Danzig92].

=======================================================================
The following technical report and the source library it describes are
available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
(Jerico's IP address is 128.125.51.6.) The directory contains the 
following files:

  README
  libtcp_ds31_ultrix41.a.Z
  libtcp_hp90_hpux847.a.Z
  libtcp_sun3_sunos411.a.Z
  libtcp_sun4_sunos411.a.Z
  brkdn_dist.h
  tcpapps.h
  tcplib.1
  tcplib.tar.Z
  tcplibtr.ps.Z

All you need to transfer to use the library are: README, brkdn_dist.h, 
tcpapps.h, tcplib.1, and one of libtcp* that matches your setup.  You
need tcplib.tar.Z only if you must generate the library yourself.  
The file tcplibtr.ps.Z is the PostScript version of the tech. report 
which is introduced below:


    tcplib: A Library of TCP Internetwork Traffic Characteristics

                 Peter B. Danzig       Sugih Jamin

                    Computer Science Department, 
                 University of Southern California,
                 Los Angeles, California 90089-0781

                     traffic@excalibur.usc.edu

                            USC-CS-91-495

1. Introduction
  When simulating computer networks, it is necessary to specify the 
traffic between network nodes.  Typically, simulation studies of 
wide-area tcp/ip networks model traffic as a combination of Poisson 
processes and maximal rate streams--corresponding to telnet traffic 
and large file transfers respectively.  Such traffic models are 
justified when the modeler wants to show, for example, that his flow 
control or gateway scheduling algorithm responds well to worst case 
traffic or when essentially nothing is known about the real network
traffic.  However, such models do not reveal how similarly robust 
algorithms respond to the common case load.
  This paper describes tcplib, a library to help generate realistic 
tcp/ip network traffic.  Tcplib is motivated by our observation that 
present-day wide-area tcp/ip traffic cannot be accurately modeled with 
simple analytical expressions, but instead requires a combination of 
detailed knowledge of the end-user applications responsible for the 
traffic and certain measured probability distributions [Caceres91].  
We collected three-day traces of wide-area Internet traffic at UC 
Berkeley, University of Southern California, and Bell Communications 
Research.  Our study identified that out of more than 35 different 
application programs, ftp, smtp, nntp, vmnet, telnet, and rlogin are
responsible for 96% of wide-area tcp/ip bytes.  Two related studies, 
one at University College London and the other at Lawrence Berkeley 
Laboratory, identified a subset of these six applications as 
responsible for most of their wide-area tcp traffic [Crowcroft91] 
[Paxson91]. Tcplib models five of these six applications.  It excluded 
vmnet, an IBM mail exchange application , because it was absent from 
three of the five traces.  Furthermore, since telnet and rlogin have 
essentially the same characteristics, we have included in tcplib only 
routines describing telnetUs.  Additionally, we included characteristics 
of phone conversations based on the study reported in [Brady65] and a 
distribution of conversations composition breakdown derived from several 
stub-network traces.
-- 
sugih                                             Use e-mail, save a tree.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 92 15:54:28 GMT
From:      sthaug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc,comp.sys.sun.wanted,comp.sys.sun.admin,comp.dcom.lans
Subject:   Need traffic generator/measurement tool with adjustable amount of broadcast

Hello! I am looking for something similar to spray, but with the ability to
send a mixture of normal (directed) UDP packets, and broadcast packets. I
need this to be able to measure how well various systems here tolerate
varying amounts of broadcast traffic. It should preferably be possible to
vary the broadcast amount from < 1% to > 25%. Yes, I *know* you don't want
25% broadcast on your nets :-)

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 92 18:09:05 GMT
From:      dennis@longs.LANCE.ColoState.Edu (Dennis Miyoshi)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: Telnet and Rlogin fails on 386 UNIX

Thanks to all who answered my plea for help.  After attempting all
solutions, we found that the tunable paramaters were too low.  This
in turn caused most of tcp/ip and nfs to fail.  We actually found this
when we realized that the X-Win system had been removed and the
parameters had been reset to their initial state.

Thanks again for the help.

Dennis E. Miyoshi, PE
Systems Engineer
USDA-SCS

--
===============================================================================
ARPA Internet:  dennis@longs.lance.colostate.edu
UUCP         :  ...ncar!boulder!ccncsu!longs.lance.colostate.edu!dennis
========================= ( ROBUST == A Broken Robot ) ========================

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 92 22:19:32 GMT
From:      toreh@merkur.sds.no (Tore Haraldsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin/Telnet number of session restriction - Help Wanted!

In article <1992Feb15.023657.12839leonid@netcom.COM> leonid@netcom.COM (Leonid Crossman) writes:
>I am running SCO ODT 1.1 between two 386 clone. If I have rlogin or telnet
>session (in one direction) and try to open the second from other window,
>I receive 'connection closed' message. If I close connection in first window
>the second starts to work. It happens for different cards and drivers and
>therefore seems to be system problem. ( ODT serial numbers are different, of
>course). If I run the only rlogin or telnet session I can use ftp, nfs tran-   
>sfers, ping etc. from different windows at the same time. 
>If somebody has any suggestions please let me know.
>            Thanks a lot in advance.
>                                        leonid@netcom.com 

Observe that your SCO Odt has a login limit of max. 2 simultaneous users
at any one time. You do not observe this fact if you usually work from
the console (with multiscreens).

If you run a dialup-type of connection between your SCO boxes, one
session will be used by the dialing-in SLIP connection, leaving one more
session only.

-- Tore Haraldsen

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 92 07:44:26 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   udp/tcp echo host...



this might be useful to someone, but i dont claim so:-)

-----------------bounce.sh - cut here--------
# This is a shell archive, shar, format file.
# To unarchive, feed this text into /bin/sh in the directory
# you wish the files to be in.

echo creating directory bounce 1>&2
mkdir bounce
echo x - bounce/bounce.1 1>&2
sed 's/^X//' > bounce/bounce.1 << 'End of bounce/bounce.1'
X.TH BOUNCE L "UCL, Jan 1992"
X.SH NAME
Xbounce \- a general purpose udp/tcp echo program
X.SH SYNOPSIS
X.B
Xbounce [-T] [-r####] [-t????] [-l@@@@] [-b size] host-foo
X.SH DESCRIPTION
X.I Bounce
Xis a simple echo application for TCP or UDP.
XNormally you would probably use a kernel based or router based IP
Xechoer. However, these usually just reverse source and destination
Xaddresses and bounce the packet: - you may waant a source of traffic
Xelsewhere than the sink; or you may want the sink on the same port as
Xsource (a problem on the same host!); or some other perverse reason.
X.PP
Xbounce uses a pair of sockets. it receives on "####", transmits what it
Xreceives to host-foo, port "????", from port "@@@@".
X.PP
XRunning
X.I Bounce host-foo
Xwith defaults the receive, transmit and local ports, to 2000, 2000 and
Xnext free port respectively. 
X
X.PP
XTypical usage:
X.SH OPTIONS
X.TP
X.BI \-rijkl 
XSet the receive port to
X.I ijkl
X(default: 2000).
X.TP
X.BI \-tijkl 
XSet the transmit port to
X.I ijkl
X(default: 2000).
X.TP
X.BI \-lijkl 
XSet the local port to
X.I ijkl
X(default: next free port).
X.TP
X.BI \-T
Xuse TCP instead of UDP.
X.I Note Bene
XTCP does not guarantee receve/send boundaries.
X.TP
X.BI \-b#
Xuse buffer size (for UDP) # bytes
X.I Note Bene
XTCP does not guarantee receve/send boundaries.
X.SH SEE ALSO
Xttcp(l), tcpdump(l), mash(l).
X.SH AUTHOR
XSteve Hailes, Jon Crowcroft, UCL
X.br
XI.Lastname@cs.ucl.ac.uk
End of bounce/bounce.1
chmod u=rw,g=r,o= bounce/bounce.1
echo x - bounce/bounce.c 1>&2
sed 's/^X//' > bounce/bounce.c << 'End of bounce/bounce.c'
X#include <stdio.h>
X#include <string.h>
X#include <ctype.h>
X#include <errno.h>
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <sys/time.h>
X#include <netinet/in.h>
X#include <netdb.h>
X#include <arpa/inet.h>
X#include <fcntl.h>
X
X#define HOST_NAME_SIZE	128
X
X#define BUFFER_SIZE	1024
X#define RECEIVE_PORT	2000
X#define TRANSMIT_PORT	2000
X
X#ifndef INADDR_NONE
X#define INADDR_NONE     0xffffffff      /* should be in <netinet/in.h> */
X#endif
X
Xint   usetcp = 0;
Xint   r_port;
Xint   t_port;
Xint   l_port;
Xchar* host_name;
X
Xint   bufsiz;
Xchar* buf;
X
X
Xvoid get_options(argc,argv)
Xint argc;
Xchar *argv[];
X /*
X  * Get the options from the command line, and convert them into
X  * meaningful parameters.
X  *
X  *     Input:
X  *	   -T use TCP, not UDP
X  *        -r <receive_port>
X  *        -t <transmit_port>
X  *	   -l <local port>
X  *        -b <buffer_size>
X  */
X{
X  void usage();
X  void parse_frame_file();
X
X  int i;
X  char *name = *argv;
X
X  while(--argc > 0 && ((*++argv)[0] == '-'))
X  { switch(*++(*argv))
X    { 
X      case 'T':         /* TCP instead of UDP */
X	usetcp++;
X	break;
X
X      case 'r':         /* receive port number */
X        r_port = atoi(++*argv);
X        break;
X
X      case 't':         /* transmit port number */
X        t_port = atoi(++*argv);
X        break;
X
X      case 'l':         /* transmit port number */
X        l_port = atoi(++*argv);
X        break;
X
X      case 'b':		/* bufer size */
X        bufsiz = atoi(++*argv);
X        break;
X
X      default:
X        usage(name);
X        exit(1);
X    }
X  }
X
X  if (--argc == 0)
X    strcpy(host_name, *argv);
X  else
X  { usage(name);
X    exit (1);
X  }
X}
X
X
Xvoid set_defaults()
X{
X  host_name = (char *)malloc(HOST_NAME_SIZE);
X  bzero(host_name, HOST_NAME_SIZE);
X
X  r_port = RECEIVE_PORT;
X  t_port = TRANSMIT_PORT;
X  bufsiz = BUFFER_SIZE;
X  usetcp = 0;
X}
X
Xmain(argc, argv)
Xint argc;
Xchar *argv[];
X{
X  int r_fd;
X  int t_fd;
X  int nread;
X  struct sockaddr_in our_r_address;       /* Inet socket address  */
X  struct sockaddr_in their_r_address;	  /* ... see netinet/in.h */
X  struct sockaddr_in their_t_address;	  /* ... see netinet/in.h */
X
X  unsigned long inaddr;
X  struct hostent *host_info;               /* From gethostbyname   */
X                                           /* ... see netdb.h      */
X
X
X  /*
X   * Initialise data structures
X   */
X  bzero( (char *)&our_r_address, sizeof(our_r_address) );
X  bzero( (char *)&their_r_address, sizeof(their_r_address) );
X
X  set_defaults();
X  get_options(argc, argv);
X  buf = (char *)malloc(bufsiz);
X  bzero(buf, bufsiz);
X
X
X  /*
X   * Create a socket to receive on
X   */
X  if ( (r_fd = socket(AF_INET, (usetcp)?SOCK_STREAM:SOCK_DGRAM, 0)) < 0 )
X  { perror("Couldn't create the socket");
X    exit(1);
X  }
X
X  /*
X   * Now associate some information with it.
X   */
X  our_r_address.sin_family      = AF_INET;
X  our_r_address.sin_port        = htons(r_port);
X  our_r_address.sin_addr.s_addr = htonl(INADDR_ANY);
X
X  /* Bind the socket to us */
X  if ( bind(r_fd, &our_r_address, sizeof(our_r_address)) < 0)
X  { perror("Couldn't bind the socket");
X    exit(1);
X  }
X
X
X  /*
X   * Create a socket to transmit on
X   */
X  if ( (t_fd = socket(AF_INET, (usetcp)?SOCK_STREAM:SOCK_DGRAM, 0)) < 0 )
X  { perror("Couldn't create the socket");
X    exit(1);
X  }
X
X  /*
X   * Now associate some information with it.
X   */
X  their_r_address.sin_family = AF_INET;
X  their_r_address.sin_port   = htons(t_port);
X
X  if ( (inaddr = inet_addr(host_name)) != INADDR_NONE)
X  { /* it's dotted-decimal */
X    bcopy((char *)&inaddr, (char *)&their_r_address.sin_addr, sizeof(inaddr));
X  }
X  else
X  { if ( (host_info = gethostbyname(host_name)) == NULL)
X    { perror("Host name not found");
X      exit(1);
X     }
X
X    bcopy(host_info->h_addr,
X          (char *)&their_r_address.sin_addr,
X          host_info->h_length);
X  }
X
X
X  printf("Listening on port %d\n", r_port);
X  printf("Transmitting to machine %s, port %d\n", host_name, t_port);
X  printf("Bufersize = %d\n", bufsiz);
X
X  /*
X   * do connections setup stuff
X   */
X  if (usetcp) { 
X        int asize = sizeof(struct sockaddr_in);
X	if (listen(r_fd, 1) < 0) {
X		perror("listen");
X		exit(-1);
X	}
X	if ((r_fd = accept(r_fd, &their_t_address, &asize)) < 0) {
X		perror("accept");
X		exit(-1);
X	}
X	if (connect(t_fd, &their_r_address, sizeof(their_r_address)) < 0) {
X		perror("connect");
X		exit(-1);
X	}
X  }
X  
X  /*
X   * And bounce the input
X   */
X  do { 
X    int msg_len;
X
X    if (usetcp) {
X	    nread = read(r_fd, buf, bufsiz);
X	    write(t_fd, buf, nread);
X    } else {
X	    nread = recvfrom(r_fd, buf, bufsiz, 0, NULL, &msg_len);
X	    sendto(t_fd, buf, nread, 0, &their_r_address, sizeof(their_r_address));
X    } 
X  } while (nread > 0);
X
X  /*
X   * Finally, close the sockets.
X   */
X  close(r_fd);
X  close(t_fd);
X
X  exit(0);
X}
X
X
Xvoid usage(name)
Xchar *name;
X{
X  fprintf(stderr, "Usage %s: [-T] [-r <receive_port>] [-t <transmit_port>] [-l <local port>] [-b <bufer_size>] <transmit_to_host>\n", name);
X}
X
End of bounce/bounce.c
chmod u=rwx,g=xr,o=xr bounce/bounce.c

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 92 09:38:13 GMT
From:      uwe@abbins.Ladenburg.ABB.de (Uwe Hilkert)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: SLIP to SCO Unix SysV.3.2 - does it work?

In article <1992Feb18.011301.26434@usage.csd.unsw.OZ.AU> pwb@newt.phys.unsw.oz.au (Paul W. Brooks) writes:
>Since SCO don't seem to have their own newsgroup, except for one for
>Xenix, I have to try here. We are planning to hook PCs to a SCO SysV 3.2
>Unix server ('386/25) over direct serial lines running SLIP, through
>a multi-port serial board from Stallion Technologies. Does anyone have
>any tales to relate about setting up the SCO box to do SLIP? I know
>Interactive's implementation has a few problems (based on aa posting a
>month or so here) - is SCO's any better?
>

I don't know if it's better bcause I don't use ISC !

We're running up to two SLIP-lines from on ODT 1.1 BOX using Specialix cards.
Run's fine !

Some little troubles I know :

  1.    YOU can't start the second SLIP-Line by hand ( e.g. slattach .... )
	It won't run !
	It's ok if started during the standard TCP/IP Startup.

  2.    netstat -i gives wrong results ( especially on second port !!)


That's all I know !
GOOD LUCK !
--
  #   ###  ###  | Uwe Hilkert, Abteilung INS/GT, ABB  Installationen GmbH
 # #  #  # #  # | Wallstadter Strasse 59,  D-W-6802 Ladenburg
#   # ###  ###  | Phone....: +49 6203 71 2257,  Fax.......: +49 6203 3993
##### #  # #  # | E-Mail...: uwe@abbins.ladenburg.abb.de, uwe@abbins.uucp
#   # ###  ###  | Building automation ---> GA2000 <--- Gebaeudeautomation

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 92 12:00:59 GMT
From:      warren@itexjct.jct.ac.il (Warren Burstein)
To:        comp.protocols.tcp-ip
Subject:   nonstandard ftp servers - where to get?

Some sites (e.g. wuarchive.wustl.edu) print messages when you ftp to
them.  Others (e.g. uunet) won't talk to you if your IP number cannot
be reverse-mapped into a name.

Are these hacked ftpd's, or just newer versions?  How can one get
these?

-- 
/|/-\\/-\\          The entire world		Jerusalem
 |__/__/_/        is a very strange banana
 |warren@         But the monkey
/ itex.jct.ac.il  is not worried at all.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 1992 13:48:57 GMT
From:      chris@wuarchive.wustl.edu (Chris Myers)
To:        comp.protocols.tcp-ip
Subject:   Re: nonstandard ftp servers - where to get?

warren@itexjct.jct.ac.il (Warren Burstein) writes:

>Some sites (e.g. wuarchive.wustl.edu) print messages when you ftp to
>them.  Others (e.g. uunet) won't talk to you if your IP number cannot
>be reverse-mapped into a name.
>
>Are these hacked ftpd's, or just newer versions?  How can one get
>these?

The modified FTP server most commonly in use now is the one found on
wuarchive.wustl.edu.  You can get a copy of the server via anonymous
FTP from wuarchive.wustl.edu in /packages.  The filename is
ftpd.wuarchive.shar.  The file CHANGES describes the new features...

--
Chris Myers                                Internet: chris@wugate.wustl.edu
Software Engineer                           UUCP: ...!uunet!wuarchive!chris
Office of the Network Coordinator                BITNET: chris@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 935 7390

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 92 14:58:33 GMT
From:      cliffb@isavax.isa.com (cliff bedore*)
To:        comp.protocols.tcp-ip
Subject:   Wireless Bridges for ethernet

We are looking at linking our corporate office with one of our remote
offices ~ 5 miles away.  We can get a 56K link from the Phone company but
there are the recurring monthly charges to contend with.  It seems to me
that there must be some microwave links available that would let us bridge
two ethernets together so they thought they were one.

Does anyone have experience with anything like this?  Are any vendors
reading who want to send info?   Please e-mail and I'll summarize

Thanks for any thoughts you might have

Cliff

cliffb@isavax.isa.com
...!uunet!isavax!cliffb


-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 92 15:34:44 GMT
From:      dla@se05.wg2.waii.com (Doug Acker)
To:        comp.protocols.tcp-ip
Subject:   Which Routing protocol

Which is the best routing protocol to use on gateways from subnets
to a backbone?    How about when the subnet has two gateway
connections to the backbone?  I've been readign about RIP,HELLO, EGP
and gated ... but I haven't found anything that says they do loop
detection.

-- 
Douglas L. Acker

Western Geophysical Exploration Products
Systems Engineer

Email (internal):  acker                Phone:  713-964-6128
      (Internet):  acker@wg2.waii.com

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 1992 15:40:26 GMT
From:      tannerc@cu18.crl.aecl.ca (Chris Tanner)
To:        comp.protocols.tcp-ip
Subject:   named - lame delegation messages

Greetings all

I hope that this is the correct newsgroup for this question. 

We have our primary name server on a SGI 4D/210 which we recently
upgraded to IRIS 4.0.1 After this, I started seeing in the SYSLOG:
named: Lame delegation to  'domain' received from 'address' on query
 ---

Is this my problem or somebody else's problem? 

What is the correct news-group for name-server discussions?

Thanks for your help.

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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 1992 17:15:23 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   bind() what the heck does it do?

what the heck does bind really do?  What can and can't I do if I do or don't do a bind call?

All the manaul says is "bind assigns aname to an unnamed socket.  When a socket is created with socket it exists in a name space (address family) but has no name assigned.

What does that mean?


-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 1992 17:18:02 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   bandwidth documents

There are usually some posts about bandwith and what systems people are testing.Why dont we put together a list of bandwidth data and tests. With what is the fastest slowest best packet size etc.


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 1992 18:55:57 GMT
From:      kline@ux1.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: Which Routing protocol

dla@se05.wg2.waii.com (Doug Acker) writes:
>Which is the best routing protocol to use on gateways from subnets
>to a backbone?    How about when the subnet has two gateway
>connections to the backbone?  I've been readign about RIP,HELLO, EGP
>and gated ... but I haven't found anything that says they do loop
>detection.

You're doing sort of apple-and-oranges comparisons. gated is a PROGRAM
which implements several routing PROTOCOLS. Of the protocols you
mentioned,

RIP is an old, simple, but functional for small nets protocol which
derived from the Xerox XNS routing protocol.

HELLO was used on the original NSFnet backbone and as far as I know is
defunct now. Its only neat feature was true link delay measurement, so
to some extent it used dynamic route costing, but I don't think it
worked very well. I was kind of a sidelines player in the networking
world back then, so I probably don't have all my facts straight on
HELLO.

EGP is an EXTERNAL gateway protocol, used for passing routes between
your Autonomous System and the Internet. It is not appropriate for use
between subnets on your institutional network.

There is one you didn't mention, OSPF, which is fairly new, and so not
as widely available as RIP, but is a very well-thought-out protocol
which solves by design a lot of shortfalls of RIP. It is, however, a
MUCH more complicated protocol and requires a little more setup and
knowledge of what is going on than RIP.

In summary, and in my humble opinion, I would use OSPF if you can get
it for your routers, and you can make it work, and RIP otherwise. OSPF
is strongly recommended for larger nets (more than a couple dozen
subnets), where it will really outshine RIP. On a small net, both will
work fine.

Oh, and to answer your question, OSPF does loop avoidance by design.
RIP has an addition to it called poisoned reverse which will do loop
avoidance also.  I haven't heard of an implementation of RIP that
doesn't do poisoned reverse in a while, but there might still be some
out there.


--
Charley Kline, KF9FF, PP-ASEL                                 c-kline@uiuc.edu
UIUC Network Architect                                          (217) 333-3339
Univ. of Illinois Computing and Communication Services      AMPR: kf9ff@ka9mnx

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 92 19:24:22 GMT
From:      c506634@umcvmb.missouri.edu (Eric Edwards)
To:        comp.protocols.tcp-ip
Subject:   RFC's for Telnet options 36, 37, 38, 200

I'm trying to write a reasably robust telnet clienet.  In my tests I've
encountered options 36, 37, 38, and 200 from various servers.  Does anyone know
what these are?  My list of assigned telnet options only goes up to 35
(plus 255).  Pointers to RFC's would be very helpfull.
 
 
Eric Edwards:  c506634 @  "I say we take off and nuke the entire site
Inet: umcvmb.missouri.edu  from orbit.  It's the only way to be sure."
Bitnet: umcvmb.bitnet      -- Sigourney Weaver, _Aliens_

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Feb 1992 20:02:38 GMT
From:      ken@opusc.csd.scarolina.edu (Ken Sallenger)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP (again)

In <1992Feb20.181635.75544@watson.ibm.com>
 rubin@watson.ibm.com (Bill Rubin) writes:

=>I strongly recommend subscribing to the Bitnet LISTSERV list
=>IBMTCP-L@PUCC.PRINCETON.EDU (to subscribe, send a note to...

This list is also available in Usenet form as bit.listserv.tcpip-l.

			Ken
-- 
     Ken Sallenger / ken@bigbird.csd.scarolina.edu / Univ. of South Carolina
     Computer Services Division / 1244 Blossom ST / Columbia, SC 29208

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 01:50:53 GMT
From:      mike@harpy.labs.tek.com (Mike Witt)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Vendors of Gigabit range networks


Does anyone have a list of vendors of Gigabit (or at least 600Mbit and up)
range products.  Or, any experience with trying to buy high speed network
components "off the shelf".

Please email.

mike@sail.labs.tek.com

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1992 05:41:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: bind() what the heck does it do?

In article <1992Feb24.171523.29866@lmpsbbs.mot.com> vittallo@ssd.comm.mot.com (John Vittallo) writes:
>what the heck does bind really do?  What can and can't I do if I do or
>don't do a bind call?

In general, bind() is used by servers to inform the system of how clients
will connect to them.  If you don't bind(), client connections will not be
recognized, and will be rejected rather than being sent to your server
process.

>All the manaul says is "bind assigns aname to an unnamed socket.  When a
>socket is created with socket it exists in a name space (address family)
>but has no name assigned.

The reason for this convoluted description is that the specific behavior
depends on the domain and protocol family of the socket.  It's
easiest to describe bind's behavior with respect to particular protocol
families, but the generic man page has to be more general than this.

For PF_INET (TCP/IP) sockets, bind() is used to specify the IP address and
TCP/UDP port of the socket.

For PF_UNIX sockets, bind() is used to specify the pathname of the socket
special file.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 12:09:13 EST
From:      rees@qut.edu.au
To:        comp.protocols.tcp-ip
Subject:   TCP Problem (help!)

Calling all TCPIP guru-types, please help.

We at QUT have a fairly major problem with our student information system,
which currently runs on a HP3000 :-(. Access to said machine is via HP
DTCs (boxes which act as a protocol gateway from Telnet to AFCP, a HP OLTP
terminal protocol - the HP3000 only talks AFCP).

Now these DTCs seem to be doing a strangeish thing. After 5 mins of TCP
inactivity (4 minutes 58 seconds, to be precise), they get worried about
the connection, and send down a packet with no flags, and a single null
byte as data, hoping to elicit an ACK from the Telnet client. It does this
5 times, and then, if it has not received an ACK, it resets the connection
and the Telnet session is dropped.

Now some Telnet clients (eg. SUN) do respond to this null packet. Others
(such as NCSA on an IBM PC) seem to gratuitously send an ACK every couple
of minutes without solicitation, and so do not have the problem.

Other Telnet clients (notably Ultrix & Xyplex terminal servers/protocol
gateways, which invariably are about the only ways anybody gets into the
HP3000) do NOT respond with an ACK to the null packet. From these machines,
it effectively looks like a 5-minute timeout.

My question is, is this a 'done' thing in TCP or Telnet or is it just a
funny by HP, which happens to work on the majority of Telnet clients but
doesn't on others (I have had a quick read of the RFCs and also a couple
of TCPIP texts and can see no mention of any sort of 'keepalive' like this).
I expect the second explanation is the most likely, and will shortly contact
HP about it, but if anyone could tell me concretely that this is a 'bad'
thing it would help us lots. 


-------------------------------------------------------------------------------
| Darryl Rees                                                                 |
| Computing Services                                                          |
| Queensland University of Technology                                         |
| Australia.                                                                  |
-------------------------------------------------------------------------------

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 07:20:35 GMT
From:      icj@otto.bf.rmit.oz.au (Ian Johnson CMIM)
To:        comp.protocols.tcp-ip
Subject:   Modems on ANNEX II's

Hi,
	This posting only applies to people using the Xylogics Annex range of
terminal servers, but I could not find a more relevent newsgroup to post to.

Ok, what I am trying to do is the have several modems connected to an 
Annex II become available to all Unix hosts.  At the moment we are using
the rtelnet program provided with the Annex to create a link (pseudo tty) from
one host to one modem.  What we want is to have any host request a modem
when needed (from either tip; uucp or other programs) and have the Annex
provide one.  I believe this will involve setting up some rotaries and then
use some software to connect a pty to the rotary.  

Has anyone done this?  Have a made any sense? :-)  What is the latest version
of Annex software that will run on an Annex II?  We currently have 
ANNEX-II-UX R5.0.6

Thanks in advance

Ian Johnston				email: icj@otto.bf.rmit.oz.au
Colonial Mutual Aust.			phone: +61-3-6076448 fax:+61-3-6076198

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Feb 1992 18:41:30 -0500
From:      Shikhar Bajaj <sb7c+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   j.crowcroft@cs.ucl.ac.uk

Jon,

     Hello, I read your article in the Jan, 1992 edition of IEEE Network
magazine and I found it very interest.  I am involved in doing so
ATM lan measurements and I have been getting some interesting results
as well.  I have a few questions about you paper though.

1)  I am still a little unclear about the exact nature of the problem and
your solution to it.  I am just learning about the internet protocols and
so I don't understand all the subtlies yet.  I understand that the problem
is in the interface between sockets and TCP on the sender side but I
don't see how your code revision (Table 8) radically differs from Table(7).

2) This may relate back to question 1 but in Fig. 3, why is a 1 byte and
1022 byte packet sent out instead of a single 1023 byte packet?

3)  In table 5, there only seems to be a 1 usec delay between successive
1460 byte sends.  How is this possible?

4)  Is the glitch at the socket/TCP interface what is causing the delay
between when an ACK is received and when the next packet is sent by the
sender in tables 5 and 6.

5)  You mention that in the BSD Reno code, the problem is corrected through
use of the low water mark option in setsockopt(), is the idea that the
socket send buffer should not send any data to TCP until there is
some minimum amount of data.  If so, what happens when the last piece
of data in a message falls below your low water mark.  Does a timer
automatically flush the buffer after a certain interval?



Thanks for your help, clarification, and forebearance in answering these
"naive" questions.  Please email your response to bajaj@faline.bellcore.com.

Shikhar Bajaj
Bell Communications Research
bajaj@faline.bellcore.com
(201) 829-4541

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 12:14:09 GMT
From:      hooper@ccs.QueensU.CA (Andy Hooper)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP (again)

In article <1992Feb24.200238.10794@opusc.csd.scarolina.edu>,
 ken@opusc.csd.scarolina.edu (Ken Sallenger) writes:
 
| This list is also available in Usenet form as bit.listserv.tcpip-l.

Make that bit.listserv.ibmtcp-l.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Feb 1992 13:32:00 GMT
From:      dweissman@amarna.gsfc.nasa.gov (WiseGuy)
To:        comp.protocols.tcp-ip
Subject:   Domain Name Service


Are there recommended books or papers on Domain Name Service, it's
use, set-up, and theory?  


================================================================================
Dave Weissman - Broadband and FDDI LAN Operations Group

Snail mail:                       NeXTmail - weissman@trust.gsfc.nasa.gov
   Code 543.8                     Internet - dweissman@amarna.gsfc.nasa.gov
   Goddard Space Flight Center    SPRINTnet's X.400 -
   Greenbelt, Maryland 20771      (C:USA,A:TELEMAIL,P:GSFC,FN:DAVID,SN:WEISSMAN)

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Feb 1992 14:58:06 GMT
From:      khanna@thunder.cs.odu.edu (Sanjay Khanna)
To:        comp.protocols.tcp-ip
Subject:   DLPI specs

I am posting it for someone I know. He is somehow unable to post
himself. Kindly post all mail replies to him at -

sudheer%vigyan.ernet.in@iisc.ernet.in  

thanks
----------------------------------------------------------------

Subject: DLPI specs
To: comp.protocol.tcp-ip (TCP/IP Group)
Date: Tue, 25 Feb 92 14:30:03 PST
X-Mailer: ELM [version 2.3 PL0]

Hello,

	Can somebody tell me where I can get DLPI specifications. If
it is possible to access through 'ftp' kindly give me the details of
the node like the internet address and the directory in which it  is
kept.

Please try to post it at the earliest. I am in urgent need of it.

Thank you.

Sudheer

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Feb 1992 15:33:59 GMT
From:      ken@opusc.csd.scarolina.edu (Ken Sallenger)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP (again)


Mea culpa!

=>=>IBMTCP-L@PUCC.PRINCETON.EDU (to subscribe, send a note to...

In <1992Feb24.200238.10794@opusc.csd.scarolina.edu> I wrote:

=>This list is also available in Usenet form as bit.listserv.tcpip-l.

It's been kindly pointed out to me that there are _two_ BITNET lists:
TCPIP-L and IBMTCP-L.

I almost got it right:  IBMTCP-L (the list under discussion here) is
gatewayed to usenet as bit.listserv.ibmtcp-l
                                    ^^^^^^^^ not tcpip-l!
Apologies for my confusion.


-- 
     Ken Sallenger / ken@bigbird.csd.scarolina.edu / Univ. of South Carolina
     Computer Services Division / 1244 Blossom ST / Columbia, SC 29208

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 18:58:58 GMT
From:      system@eagle.navsses.navy.mil
To:        comp.protocols.tcp-ip
Subject:   A Subnetting Question

I have a question concerning subnets.  If I have a network (for example
155.155.0.0) and a subnet mask 0.0.240.0 are the subnets 155.155.240.0 and
155.155.0.0 usable? or am I restricted to subnet number that are not all ones
(155.155.240.0) and all zeros (155.155.0.0)?

Mike Jacobi
NAVSSES VAXcluster system manager
System@eagle.navsses.navy.mil
Jacobi@eagle.navsses.navy.mil

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 21:24:29 GMT
From:      davethomas@cix.compulink.co.uk (David Thomas)
To:        comp.protocols.tcp-ip
Subject:   Domain Name Servers

Anyone know where there's PD sources of a Domain Name Server (a la
'named')?

Thanks

Dave Thomas

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 21:25:09 GMT
From:      davethomas@cix.compulink.co.uk (David Thomas)
To:        comp.protocols.tcp-ip
Subject:   Looking for DNS

Anyone know of Public Domain sources for an RFC1034/5 Domain Name
System/Server (like 'named').

Many thanks

Dave Thomas

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1992 21:35:12 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Problem (help!)

In article <1992Feb25.120913.43062@qut.edu.au> rees@qut.edu.au writes:

[Description of Telnet-AFCP gateway, which sends keepalives on the Telnet
connection.]

>My question is, is this a 'done' thing in TCP or Telnet or is it just a
>funny by HP, which happens to work on the majority of Telnet clients but
>doesn't on others (I have had a quick read of the RFCs and also a couple
>of TCPIP texts and can see no mention of any sort of 'keepalive' like this).

See section 4.2.3.6, "TCP Keep-Alives", of RFC 1122.

>I expect the second explanation is the most likely, and will shortly contact
>HP about it, but if anyone could tell me concretely that this is a 'bad'
>thing it would help us lots. 

There's a strong difference of opinion in the community about keepalives.
My feeling is that timeouts on keepalives shouldn't cause the connection to
be closed, as that can be caused by temporary network problems.  However,
if the other end crashed and rebooted, the keepalive will result in a RST
segment, and the normal and appropriate result of this will be that the
connection is closed.

So, in your case, you may complain to HP about how it handles keepalive
timeouts, but they may not be very sympathetic.  However, you should also
complain to the vendors of the devices that don't respond to the
keepalives, as this sounds like a bug in their implementations.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 92 22:35:27 GMT
From:      rlk@VisiCom.COM (Bob Kitzberger)
To:        comp.protocols.tcp-ip
Subject:   Mapping listen() to TCP/IP?

I'm writing the glue code between BSD-like sockets and
an existing TCP/IP implementation, and have come across a bit of a 
stumper... what do I do about listen()?

As far as I can see, listen has two reasons for existing:

1. Prepare a socket to accept connections on a socket.  

   This is a bit odd -- I had thought that all programs that call
   listen will next call accept() to suspend the calling process
   until data is available on the socket.  What does listen()
   do that can't be done inside of accept()?  For a TCP/IP
   implementation of sockets, what should listen() do?

2. Set connection queueing depth.

   My reading of RFC793 section 2.7 "Connection Establishment and
   Clearing" says nothing about limiting the depth of queue depths
   for 'passive OPENs', which is what I assume the queueing depth
   would apply to.  Am I missing something?  The user gives me
   a queue depth via listen(), so what do I do with it??

Thanks for any help or pointers!!

	.Bob.

   
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121
			619-457-2111    FAX 619-457-0888

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Feb 1992 00:31:16 GMT
From:      manoj@hal.com (Manoj Betawar)
To:        comp.protocols.tcp-ip
Subject:   Security at LAN

Hi
	I looking for standardwhich will help me to implement security at TCP-IP level. This security will be other than normal passwd level. Some thing to do with DES algorithm and TCP-IP pkt encapsulation. Where I should get doc for this? and direction to serch. All comments are welcome.

Thanks for reply in advance

manoj@hal.com



-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Feb 1992 02:42:03 GMT
From:      peterd@tscc2.macarthur.uws.edu.au (Peter Degotardi)
To:        comp.sys.ibm.pc.rt,comp.protocols.tcp-ip
Subject:   slip connection ibm risc <--> ibm rt

the summary says it all.
has anyone succeeded in installing a slip connection between an ibm rt
and an ibm risc 6000. we're trying, and can't get it to work.

any suggestions, hints, tips, documentation etc. would be apprecitated.
(all the ibm doco mentions slip, and quickly mentions how to configure,
but I need more detail)

Thanks in advance.


--
Peter Degotardi ( p.degotardi@uws.edu.au ) | Disclaimer: Any opinions expressed 
University of Western Sydney, Macarthur    | are my own, and may not reflect
Teaching and Services Computing Centre     | those of my employer or anyone
Campbelltown, New South Wales, Australia ! | else. (In case you're interested.)

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Feb 1992 12:42:58 GMT
From:      a722756@pan.mc.ti.com (W. D. Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: netbios question


In article <1992Feb25.090222.1644@vixvax.mgi.com>, jlundell@vixvax.mgi.com (Jim Lundell) writes:
|> Hi, 
|> 
|> A week ago I saw a sheet that showed the "protocol suite" for TCP/IP and in
|> the top layers it showed NETB1OS. I was wondering if this was a misprint
|> for NETBIOS. 
|> 
|> In short, I was wondering if NETBIOS was part of the TCP/IP protocol. It would
|> surprise me if it was. Thanks in advance.
|> 
RFC1001 and 1002 describe NETBIOS transported over tcp/ip.  Partial
implementations are available from a number of vendors (DEC, 3COM, FTP etc.)
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Feb 1992 19:08:01 GMT
From:      guyw@knox.uswest.com (Guy Wells)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over Ethernet, how about 802.2/.3

Big question: Yes, TCP/IP over Enet has been around a while, however,
are there any vendor implementations that use TCP/IP over both 802.2 and
802.3, or are they strictly TCP/IP over 802.3 alone?

Further, what vendor products do in fact support the above? Any help
would be incredibly appreciated.

Please e-mail me at guyw@uswest.com.  Thanx!!
-- 
--
Guy M. Wells <guyw@uswest.com>  Disclaimer: My opinions are mine, no
U S WEST Advanced Technologies  one elses, and certainly not USWEST's!

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Feb 1992 21:35:33 GMT
From:      andy@uis.com (Andy Edwards)
To:        comp.protocols.tcp-ip
Subject:   using a one-to-many SLIP connection

I was wondering if there is any way to use SLIP in the following
environment:

I have a central site (call it A) that has two modems and several remote
sites (1 through 20) that each have one modem.  I would like to
set up a dial-up IP network (using SLIP, I guess) so that A could
call up to two of the remote sites at a time or two remote sites
could simultaneously call site A.

Can something like this be done?  Is there a better way, assuming
that all I have are dil up lines?

Any help would be appreciated.  Thanks in advance.

		--andy



-- 
-----------------------------------------------------------------
Andy Edwards   *   Unix Integration Services   *  Urbandale, Iowa
EMAIL: andy@uis.com                         PHONE: (515) 254-3074

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1992 22:01:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Mapping listen() to TCP/IP?

In article <165@visicom.com> rlk@VisiCom.COM (Bob Kitzberger) writes:
>I'm writing the glue code between BSD-like sockets and
>an existing TCP/IP implementation, and have come across a bit of a 
>stumper... what do I do about listen()?
>
>As far as I can see, listen has two reasons for existing:
>
>1. Prepare a socket to accept connections on a socket.  
>
>   This is a bit odd -- I had thought that all programs that call
>   listen will next call accept() to suspend the calling process
>   until data is available on the socket.  What does listen()
>   do that can't be done inside of accept()?  For a TCP/IP
>   implementation of sockets, what should listen() do?

Listen() tells the system to start accepting connections, i.e. to perform a
passive open.  This could be done by accept(), but then any SYN segments
that are received while the server isn't blocked in accept() will be
rejected.

Also, a socket that has been prepared by listen() can be waited for with
select().  When the SYN is received, select() will return, and *then* the
server will call accept().  This permits the server to wait for connections
on several sockets simultaneously (consider the implementation of inetd).

>2. Set connection queueing depth.
>
>   My reading of RFC793 section 2.7 "Connection Establishment and
>   Clearing" says nothing about limiting the depth of queue depths
>   for 'passive OPENs', which is what I assume the queueing depth
>   would apply to.  Am I missing something?  The user gives me
>   a queue depth via listen(), so what do I do with it??

This is purely a concession to a particular implementation technique.  If
SYN segments are received when the server isn't blocked in accept(), the
kernel has to buffer the information somewhere until the server calls
accept().  This tells the kernel how much buffering to provide for this
particular server.

If you provide unlimited buffering of not-yet-accepted connections you can
just ignore the queue length parameter.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Feb 1992 01:55:43 GMT
From:      oday@calspan.com (Abdi M. Oday)
To:        comp.protocols.tcp-ip
Subject:   RDP protocol WANTED

There is a protocol mentioned in Doug Comer's TCP/IP book.
RDP:  Reliable Datagram Protocol.

Does anybody know how I can get my hands on an implementation?
	
	Thanks in advance.

P.S.  Sorry if this is the wrong group to post this to.
-- 
-----------------------------------------------------------------------
     --  Abdi M. Oday          -- oday@calspan.com                   --
     --  Calspan Corp.         -- (716) 631-6848                     --
-----------------------------------------------------------------------

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1992 05:24:24 GMT
From:      sob@tmc.edu (Stan Barber)
To:        comp.periphs.printers,comp.protocols.tcp-ip
Subject:   Summary of boxes that do lpd (or link to unix printer subsystem)


Here is a summary of the commerical offerings I got in response to my
question about boxes that I could attach to printers so they could do
lpd.

Tektronix has something called the 4511 that is supposed to do it.
Call them at 1-800-835-6100 for more information. 

A company called AXIS manufactures something called the AX-5 which is 
also supposed to do the job. Send mail to les@axisinc.com or call 
1-508-777-7957.

FTP software supplies an lpd server with its OS/2 product. I am also
told that an lpd server is available that runs on the DOS stack. Both
turn a PC into a LPD server.

MiLAN and Multiplex confirm that their boxes do not do LPD. I have
a Multiplex box in for evaluation at this time. It was easy to setup
and it appears to work, but it does not do lpd.

More as I know more.
-- 
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: rutgers!bcm!sob             and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 92 11:14:01 GMT
From:      mike@datmuc.UUCP (Mike Zeiner)
To:        alt.sys.sun,bit.listserv.ibm-nets,biz.dec,comp.dcom.sys.cisco,comp.org.decus,comp.protocols.iso,comp.sys.att,comp.sys.dec,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   READ! - Survey on Networks and Transport Systems


                     Number five needs input!!!
                     ==========================
               (Survey and reposting of the results)

Hello there, all over the world!

I've got some questions to all the Network-Guru's working with
DEC, HP, IBM, SNI, UNISYS or other UNIX-Machines using ISO-based 
transport systems (like TLI, XTI ...).

For future decisions and for common interests I want to do a survey
where I want to know about the advantages/disadvantages
of the distributor specific implementations of the ISO-Stuff.
The results of the survey will be posted in a fortnight.

Therefore I *need* your experiences in administrating, programming
and working with your kind of ISO Networking-Software.

I would be especially pleased by getting some information about
former developments planned or almost done by your distributor if 
s.o. knows about.

As I'm not subscribed to all of the newsgroups I'm going to send this posting,
please answer via mail or E-mail to the following account:

 -----------------------------------------| Mike Zeiner                       |
 | E-mail: mike%datmuc.uucp@Germany.EU.net| DAT Informationssysteme GmbH      |
 | Phone: Germany - (0)89 67901-119       | Gustav-Heinemann-Ring 212         |
 -----------------------------------------| D-8000 Muenchen 83                |


To make answering easier let me do some structured questions:

To the Network Administrators:
==============================

  - which type of network do you have, on which hardware

  - which administration tools exist (Menu-Systems, automatic
    routines, Window-Support and so on)

  - how difficult is it to your opinion to build up a completely new
    network (LAN or WAN) with the machines and software you use

  - which problems exist in adding/deleting hosts to/from an existing network
  
  - how to configure and administrate the different Boards

  - what about online-help and manuals

  - what's your opinion about the whole thing (maybe in comparison to other
    concepts you know


To the Network Programmers:
===========================

  - which types of network do you use or have experience in

  - how to get local and remote addresses in a program

  - which special features besides establishing a connection
    and sending expedited data does your transport system support

  - how easy/difficult is it to create a working program

  - what do you think about the ease of use of the programming interface

  - what's your impression of the manuals and their usage

  - what's your opinion about the whole thing (maybe in comparison to other
    concepts you know


To the users of Network Applications:
=====================================

  - which types of network do you use or have experience in

  - tell me about your experiences with applications (speed, security,
    crashes etc.) Opinions please!

  - are there advantages/disadvantages you know of compared to other 
    Systems


To the Specialists:
===================

  - which types of network do you use or have experience in

  - what do you know about common interfaces of transport systems (for example
    to TCP-IP, XTI, TLI, ... applications) do they exist, are they planned?
    We have to integrate several systems with different network software, so
    we need to have several interfaces on the top of a transport system.
  
  - what about security aspects belonging to the networks you are dealing with
  
  - as we want to use different boards, does there already exist a common 
    interface between board-software and transport system, or do you know
    whether it's planned or not

  - which protokol types are supported by the transport system you know
    (ISO-LAN, X.21 X.25, ...)

  - could you give me any recommendations of which machine with which type
    of transport system we should buy or wait for, no matter the price
    It must be a UNIX-System!!!


Any answers are quite welcome and eagerly awaited.

Thanks in advance

	      /\__       /\__   /\__   /\__ /\__   /\__\__\__
		\__ \__\__ \__    \__    \__ \__     \__    /
		 \__   \__  \__    \__    \__\__      \__\__
		  \__   /    \__    \__    \__ \__     \__ /
		   \__        \__    \__    \__  \__    \__\__\__
		   /          /      /      /      /    /       /

-- 
 -----------------------------------------| Mike Zeiner                       |
 | E-mail: mike%datmuc.uucp@Germany.EU.net| DAT Informationssysteme GmbH      |
 | Phone: Germany - (0)89 67901-119       | Gustav-Heinemann-Ring 212         |
 -----------------------------------------| D-8000 Muenchen 83                |

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 92 11:22:44 GMT
From:      I.Wakeman@cs.ucl.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: RPC paper questions

Shikhar,
Jon has just passed this on to me to answer, coz I was the one that actually
wrote all the words down and supposedly know what they all mean, he's busy
and the other two work elsewhere.

 Shikhar Baja writes
 >
 >Jon,
 >
 >     Hello, I read your article in the Jan, 1992 edition of IEEE Network
 >magazine and I found it very interest.  I am involved in doing so
 >ATM lan measurements and I have been getting some interesting results
 >as well.  I have a few questions about you paper though.
 >
 >1)  I am still a little unclear about the exact nature of the problem and
 >your solution to it.  I am just learning about the internet protocols and
 >so I don't understand all the subtlies yet.  I understand that the problem
 >is in the interface between sockets and TCP on the sender side but I
 >don't see how your code revision (Table 8) radically differs from Table(7).
 >

Very subtly I suppose. The socket code and the tcp code communicate by a
fixed length queue. The problem we discovered was that when the queue was
nearly full, the code would fragment the user data that was to be delivered,
dump it in the queue and then go to sleep till it was woken up on an empty
queue. We added a check to make sure that there was sufficient space left in
the queue to place at least an mbufs worth of data to avoid splitting
buffers.

 >2) This may relate back to question 1 but in Fig. 3, why is a 1 byte and
 >1022 byte packet sent out instead of a single 1023 byte packet?
Because all the data in the queue upto and inlcuding the 1022 byte packet
would have been sent out as packets and would be waiting in the queue to be
acknowledged. The socket code would come along, see there is a a byte of
space left in the queue, dump a byte of user data in the queue then wait
unitl the queue emptied before dumping more data. So the byte of data would
be sent out probably after a packet came in (coz thats when the tcp code
would generally get its next look-in), the tcp code would see no more data
to send, and then pass control onto the socket code to dump more data in the
queue.

 >3)  In table 5, there only seems to be a 1 usec delay between successive
 >1460 byte sends.  How is this possible?
 >
Timings with tcpdump on the sun NIT device are not very precise - they're
not to be trusted beyond +-10 ms safely, but they're generally about +-1 ms.
If you want accurate timings, move to the BSD packet filter (which has more
efficient filtering code) and get a really accurate clock for your machine
(Jeff Mogul's paper on LAN traces in SIGCOMM91 is a nice place to start if
you're interested in accurate network measurements). We had measurements to
1 usec coz we were too lazy to edit the files that we output.

 >4)  Is the glitch at the socket/TCP interface what is causing the delay
 >between when an ACK is received and when the next packet is sent by the
 >sender in tables 5 and 6.

Yep.
 >
 5)  You mention that in the BSD Reno code, the problem is corrected through
 >use of the low water mark option in setsockopt(), is the idea that the
 >socket send buffer should not send any data to TCP until there is
 >some minimum amount of data.  If so, what happens when the last piece
 >of data in a message falls below your low water mark.  Does a timer
 >automatically flush the buffer after a certain interval?
 >
Umm, its not "minimum amount of data", its minimum amount of space. If there
is less space than the low water mark, then refrain from putting in more
data until there is more space. Because the TCP guarantees to eventually
empty the data and then kick the socket code alive, the data will all
eventually enter queue.

Basically, the problem we had was a little nasty boundary problem that was
apparent when using RPC. We wanted to say it affected X performance as well,
but we never got around to doing the measurements (we did the work in our
spare time over a week, including writing the paper, and we didn't expect to
get such a large circulation with it.) Standing on my soapbox, I still
reckon that layering should not be the only implementation model that people
use - focussing on the requirements of the application data are necessary as
well (in this case, non-time-critical data buffers, which nonetheless should
be delivered as quickly as possible). Perhaps there is a case for the design
stage to go through several phases where different implementation models are
emphasised, to refine the design to greater "efficiency" (whatever that
means).

Finally, the graphs and figures that should have been in the paper are to
be published in the February edition of IEEE Network. And a final word of
warning to anyone who has major corrections to a re-typeset copy of their
paper - demand to see what it looks like to check the changes are correct.

:-)

cheers
ian

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 92 14:29:49 GMT
From:      mbloch@sicsun.epfl.ch (Michael BLOCH)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Network-oriented programming


I'm currently looking for an environment to develop client-server
applications. These applications are prototypes for evaluating
theories in the field of distributed decision-support systems.

The operating system could be either MS-DOS, OS/2, Macintosh or UNIX.
The language could be either Pascal, C or something completely
different (like a specific network-oriented language).

What does really matter is the facilities that this environment
would provide to do network-oriented programming (i.e. message transfer
between processes running on different computers, message queues, support
for synchronization, ...)

Examples of low-levels environments : OS/2 or UNIX Named Pipes, Sockets, ...
I'd like to find higher-lever environments (that could also be libraries
oriented towards network-programming)

Any pointers would be greatly appreciated


-- 
Michael Bloch, Network Manager                  Internet : mbloch@ulys.unil.ch
University of Lausanne, Switzerland             BIX ID : astolfi

Life would be so much easier if you could look at the source code ...    

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 92 15:59:51 GMT
From:      dhuber@autelca.ascom.ch (Daniel Huber)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Wanted: Guideline for LAN emergencies

Hi netters,

I'm just wondering if there is somewhere a guideline for LAN
(Ethernet) emergencies available. It don't has to be in a
"IF-THEN-ELSE" format. Just it should give some hints what to do if
some events on the net occur...

Eg.

- Broadcast storm
- AppleTalk ZIP-Storms
- Bad performance
- ....
- and more....

And to each of these topics the following questions:

	-> What is that exactly?
	-> How do we recognize it?
	-  What will happen if we don't fix it?
	-> How should/can I fix it?
	-> What tools can I use to check this out?

What's about creating a FAQ for this? I bet that more network
administrators would appreciate something like this...

I hope to hear more ...


Daniel

-- 
Daniel Huber AP-KT2.6 / Ascom Autelca AG / CH-3073 Guemligen / Switzerland
SMTP: dhuber@autelca.ascom.ch / Voice: +41 31 529664 / Fax: +41 31 529751 
X.400: G=Daniel/S=Huber/OU=Autelca/O=Ascom/P=EUnet/A=Arcom/C=ch 

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 92 16:46:00 GMT
From:      bdt@sunbim.be (Bernard Detrembleur)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   IP subnet and hosts addresses manamagent

Hi all,

I am currently working on a project which aims to define and setup a 
method to distribute subnets addresses in a big organization.

The organization counts 20,000 people and the rate of moving is high.
They have 2 ( and in the future 3) class B network addresses and the
number of people in a subnet is from 20 to 1000.

As I don't want to reinvent the wheel, I have some questions:

Do you have defined in your organization (Universities, Private companies, 
Agencies,...) methods to distribute addresses to subnet managers? Do you 
have documents which describes these methods? If not, can you summarize me 
by email the method you follow?

Do you know software tools which allows to do that? Are you using some tools 
to help you in this job?

	e.g Implementation of RFC 1219 On the assignement of subnet numbers?


Do you know some software which allows to visualize on a printer or on a
graphical display the results of an addressing method? 


Thanks in advance for your help

All the bests

Bernard Detrembleur

EMAIL: bdt@sunbim.be


               +--------------------------------+
	       |	S.A. BIM N.V.           |
	       |	Kwikstraat 4            |
 	       |  B-3078 EVERBERG (Belgium)     |
               |                                |
	       |      Ph.  +32-2-7595925        |
	       |      Fax. +32-2-7594795        |
               |                                |
               +--------------------------------+

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Feb 92 19:22:08 GMT
From:      thall@isis.cs.du.edu (Timothy Hall)
To:        comp.sys.att,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Is Internet firewalling possible on an AT&T 3B2?


We are currently looking at firewalling our network from Internet.  Here is our
configuration:

                                     Various Other Machines
                                                 \
   _______            ________                    \  ________      ________
  /       \          /        \                    \/        \    /        \
  |Local  |__________|Gateway |_____________________|Concen- |____|Internet|
  |Network|  802.3   | Host   | 19.2K leased line   | trator |    |        |
  \_______/          \________/    running X.25    /\________/    \________/
                                                  / 
                                                 /
                                      Various Other Machines

Our gateway host is an AT&T 3B2/600G running Unix System V R3.2.3 and 3.2 of
Wollongong TCP/IP.  A standard NI card is used to interface with the
local network, and a SPSC (Special Purpose Synchronous Controller) card is
used for the leased line.  The version of the SPSC software is 3.1 Patch 1.0.  

We want to configure our gateway host to not forward certain incoming packets
from Internet to our local network.  The packets we wish to reject have the
following port numbers:
	23 (telnet)
	25 (SMTP email)
	21 (FTP)

However, outgoing packets with these port numbers from our local network 
to Internet must still be allowed through.  If you or someone you know
has successfully implemented this type of packet filtering on a 3B2, I
would love to hear from you.  Please respond via e-mail, my e-mail address is
thall@nyx.cs.du.edu.  I will summarize to the net if there is sufficient
interest.  Thanks in advance.

Tim C. Hall
thall@nyx.cs.du.edu

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Feb 1992 21:15:54 GMT
From:      rogers@ux1.cso.uiuc.edu (Bill Rogers)
To:        comp.protocols.tcp-ip
Subject:   Wd8003 + XT + 10Base-T = network failure?

We're new at 10Base-t and have a strange problem. We've tried to put 
a WD8003 8-bit card in an old PC with a 10Base-t tranceiver. Turn the
power on, the H-P ethertwist hub dies, the Cabletron hub for that
coax segment dies. And everything comes to screatching halt.

No network software running on the PC, just turned on.

The same thing happened on a turbo-XT, on a occoasional basis. more weird.

My gut feeling is too small a power supply. On the XT, 67 watts, and a hard
disk.

Has anyone else had this problem?
Bill

-- 
..............................................................................
Bill Rogers                             . Internet - rogers@ux1.cso.uiuc.edu
Asst. Director for Academic Computing   . Bitnet - ROGERS@UIUCVMD
Sangamon State University               . Voice - 217-786-6549

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Feb 1992 21:34:47 GMT
From:      mahmood@freedom.msfc.nasa.gov (Rafique Mahmood)
To:        comp.protocols.tcp-ip
Subject:   Advance class on TCP/IP

 Does anyone know of any good advance class on TCP UDP. 
How does it communicate with lower levels. How 'mbuf' and
other buffer has impact the throughput. How does ethernet
driver and tcp/ip interfaces.

Thanks,
Rafique Mahmood
205-544-6475
mahmood@freedom.msfc.nasa.gov


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 92 22:15:48 GMT
From:      pruttman@cerebus.cc.edu (Pete Ruttman)
To:        comp.protocols.tcp-ip
Subject:   SLIP for SUN workstation

Here is the readme for the slip program for a SUN workstation.  I have
some questions:


This is SLIP for SunOS 4.0.

Although the SLIP distribution is quite usable by itself for a simple direct
point-to-point link, you may want to install some programs that make dialout
SLIP convenient, or allows you to better integrate the point-to-point link
into your network.

To run SLIP, do the following:

1.	Add:

	os/tty_slip.c		optional slip

	to /sys/conf.common/files.cmn

2.	Copy tty_slip.c to /sys/os/tty_slip.c

3.	Add

	...
	#include "slip.h"
	...
	#if	NSLIP > 0
	extern struct streamtab slipinfo;
	#endif
	...
	#if	NSLIP > 0
		{ "slip",	&slipinfo },
	#endif
	...

	to /sys/sun/str_conf.c

4.	Add

	pseudo-device slip5

	to your CONFIG file.  If you want to preattach all the interfaces,
	use
	
	pseudo-device slip5 init slip_attach


^^^^^^^^^^^^^^^^^Where is this "CONFIG" file kept?

5.	Copy slip.h to /usr/include/sys/slip.h (and /sys/sys/slip.h)

^^^^^^^^^^^^^^^^^^Why two places?


6.	Configure your kernel and install and boot it

^^^^^^^^^^^^^^^^^^^^^Could someone explain this more completely?

7.	Compile and install the sliplogin program suid root.

^^^^^^^^^^^^^^^^^^^^Does this mean put the program in a bin and
							 set the S bit?




Thanks for any help,



Pete

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 04:05:34 GMT
From:      rsrasp@miavx1.acs.muohio.edu
To:        comp.protocols.tcp-ip
Subject:   Telnet 5250 for MACS

Does anyone know if there is a version of telnet that emulates
5250 for the Mac?  I want to be able to signon to an AS/400
from a Macintosh that is connected to our AS/400 via an
ethernet connection.  If there is such a product available, where
may I purchase it and how much does it cost?

Any information would be greatly appreciated! 

Thanks,

Randy Rasp

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 04:08:31 GMT
From:      leonid@netcom.com (Leonid Crossman)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   EISA Compaq + SCO UNIX network problem.

Does anybody experienced some problems with EISA Compaq + SCO UNIX combination?
For me, ftp transfer just dies ( computer is frozen, clock/keyboard do not work
etc.) The same board/driver works fine under SCO UNIX in any other computer
even if it is more fast EISA so problem seems to be speed unrelated.
Thanks in advance for any hints/tips/similar cases description.
                  Thanks again,    leonid@netcom.com

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Feb 1992 06:10:54 GMT
From:      cis4211@gsusgi2.gsu.edu (CIS 830 Student)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Token Ring

   I am part of a group working on a Lan proposal for an engineering group
that needs connectivity to a DEC, Unisys and IBM mainframe host.  There is
going to be a lot of data transfer from the hosts and for reasons of 
compatibility it looks as if we are going to go with a Token Ring setup.  
I am wondering however if there is a good TCP/IP package for what will be 
a bunch of PC servers and if this package can fit in 50K of ram?  Thanks


-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 11:12:26 EST
From:      ejones@desire.wright.edu
To:        comp.protocols.tcp-ip
Subject:   SLIP info wanted

	If I am directing this towards the wrong group, please direct me 
elsewhere. I am interested in establing a SLIP line from work to home. At
work I have a DECstation 5000 and at home I have a Macintosh. I have two
USR V.32bis modems that I would like to use. I know nothing about setting up 
a slip line or what equipment/software is required. Are there any
publications that explain what SLIP is, what equipment is required, and how
to set it up? Thanks.
	Ed Jones
	ejones@desire.wright.edu
	        or
	ejones@wsu.bitnet

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 07:33:32 GMT
From:      laude@nic.cerf.net (Michael Laude)
To:        comp.protocols.tcp-ip
Subject:   where are the 4.3bsd tahoe srcs?

This is probably a FAQ, but it seems to me that the 4.3bsd tahoe
sources for tcp/ip are available somewhere on the net.

I can't for the life of me remember where. Please help me.

Thanks in advance.


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 08:15:07 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Is PUSH provided in 4.3BSD socket interface?

Hi,
	Could anybody please tell me whether PUSH is provided in 4.3BSD TCP/IP
socket programming interface? According to my understanding, PUSH is NOT
provided in 4.3BSD socket. Does other vendors such as DEC or Sun TCP/IP 
socket interface supports the provision of setting the PUSH flag by 
application? The PUSH flag is not provided in HP TCP socket interface.
	Your help is very much appreciated. Thanks.

Regards,

 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgm2.sgp.hp.com   |
| Singapore 0410                      |            taybh@hpsgnlc.sgp.hp.com  |
| Republic of Singapore		      | HPDesk:    HP3200/67                 |
 ----------------------------------------------------------------------------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 13:53:12 GMT
From:      [NOT FOUND] (Bert Visscher PACS)
To:        comp.protocols.tcp-ip
Subject:   Characteristics round trip time using UDP/IP


I am trying to model communication using the UDP/IP protocol.
During this research I studied the round trip time of packets
with variable length between a sun sparc 2+ and an IBM os2
machine. To my supprise, the round trip time looked like this.         


Time |
     |
  ^  |
  |  |
     |
     |
     |         ***
     |        *   *
     |     ***     **                    ************
     |    *          *       ************
     | ***           ********
     |*
     |
     |
     --------------------------------------------------
                   500                    -> Packet Length

I think, the increased time which occurs step by step for small
packets is due to allocation of 'mbuf' buffers. What I cannot 
explain is the decreased round trip for packets larger than 515
bytesi, which increases gradually. 

Who knowns more about this phenomenon and can explain this,
or knowns some good literature about this subject in particular,
and studies of round trip times in general.

Thanks, Bert.

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 16:20:53 GMT
From:      happe@rei2.UUCP (Kevin Happe)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP sessions don't go away!!! HELP!!!


We are having a problem and need some help so please respond.

We are using Lan Workplace for dos on pcs as clients to unix servers.
What happens is that the pc will hang up or is booted and the session
remains active on the unix server side.

We are currently using 'SunOS {machine-name} 4.1.1 8 sun4c'.  We have
configured the kernel so the KEEPALIVE functionality should be started
about 2 minutes after no response.  Our applications on both the UNIX
side and PC side are both setting the sockopt to use KEEPALIVE.

How do we clear the session from the unix side without having to reboot
the PC???  We need a programatic method and are there any utilities on the
unix side to free the socket.  Any examples, related publications,etc. are
appreciated.


-- 
HAPPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPEHAPPE
Kevin Happe
Recognition Equipment Inc.       All It Takes Is JUST A Little Software
happe!rei2!uunet

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Feb 92 20:45:51 GMT
From:      davez@ibx.com (Dave Zarnoch)
To:        Comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   SLIP for Sun

We are attempting this scenario:

Sun IPCs or SS1+s (local swap and openwindows) at home w/ Telebit or a similar high speed modem.
We would like to dial out on a non-dedicated line to a like modem on the office side connected
to an Annex 3 and then into the ethernet. 
I have a file called "slip-4.1.shar.Z" from uunet. This looks like a solution, unfortunately
there is very little documentation included.
Any help or pointers to help (software, configured locations, documented configurations) would be 
appreciated.
If you need any more info on this subject, please call or email.

Thanx,

davez
davez@ibx.com
Dave Zarnoch
Independence Blue Cross
Philadelphia, PA
1(215)241-4173

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 21:53:27 GMT
From:      nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha)
To:        comp.protocols.tcp-ip
Subject:   TCP_NODELAY socket option

Can someone explain me whether setting/clearing of TCP_NODELAY flag
with setsockopt appies only for the specified socket, or for all the 
sockets of the given process.

If my process has two sockets and has TCP_NODELAY cleared, and the other
one has is set, can I really expect first socket to have better performance
for larger messages, and the latter to be much better for smaller messages.

Thnanks,

-- 
Nenad Nedeljkovic                        -------------------------------
   Internet: nedeljn@jasper.cs.orst.edu | Department of Computer Science  
   Phone:    (503) 737 - 5571 (office)  | Oregon State University           
             (503) 752 - 7632 (home) 	| Corvallis, OR 97331

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 22:23:32 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Problem (help!)

rees@qut.edu.au writes:

>Now these DTCs seem to be doing a strangeish thing. After 5 mins of TCP
>inactivity (4 minutes 58 seconds, to be precise), they get worried about
>the connection, and send down a packet with no flags, and a single null
>byte as data, hoping to elicit an ACK from the Telnet client. It does this
>5 times, and then, if it has not received an ACK, it resets the connection
>and the Telnet session is dropped.

As I read RFC 793, if a TCP receives a  segement without any flags set it 
should  ignore it. It seems to me that the HP is not behaving very well and
any implementation that responds is being very gracious.

Kurt Matthys
Unisys Corp.

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 92 22:33:24 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   Re: Mapping listen() to TCP/IP?

rlk@VisiCom.COM (Bob Kitzberger) writes:

>I'm writing the glue code between BSD-like sockets and
>an existing TCP/IP implementation, and have come across a bit of a 
>stumper... what do I do about listen()?
 
>As far as I can see, listen has two reasons for existing:
 
>1. Prepare a socket to accept connections on a socket.  
 
>   This is a bit odd -- I had thought that all programs that call
>   listen will next call accept() to suspend the calling process
>   until data is available on the socket.  What does listen()
>   do that can't be done inside of accept()?  For a TCP/IP
>   implementation of sockets, what should listen() do?
 
>2. Set connection queueing depth.
 
>   My reading of RFC793 section 2.7 "Connection Establishment and
>   Clearing" says nothing about limiting the depth of queue depths
>   for 'passive OPENs', which is what I assume the queueing depth
>   would apply to.  Am I missing something?  The user gives me
>   a queue depth via listen(), so what do I do with it??

1. As I remember, a process does not have to do the accept next. One of the
   interesting things about sockets, TLI, and XTI is that after doing a 
   send data call, if there is input, the process is returned a status of
   t_look. Then the process can tell what has arrived and supposedly look
   at all the received open requests before responding to any of them. This 
   allows the process to decide which ones to accept if any.

2. The queue depth is a sockets thing where the process that is going to
   read  all the inbound opens before accepting them can specify what the
   maximum number of opens that it will handle.

I am not a sockets expert by any means, but I thought that I would take a
shot at answering the questions.

Kurt Matthys
Unisys Corp.

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 92 03:55:41 GMT
From:      pushp@nic.cerf.net (Pushpendra Mohta)
To:        comp.protocols.tcp-ip
Subject:   Seeking a TCPDump for FDDI

Does such a beast exist for Sun Sparc Stations ?

--pushpendra


-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 92 04:38:05 GMT
From:      mef@klinzhai.rutgers.edu (Marc E. Fiuczynski)
To:        comp.sys.att,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Is Internet firewalling possible on an AT&T 3B2?

Hi,

You will want to read the Secure_Internet_Gateway.ps file on
research.att.com in /dist.  The author of the package was attempting
to get a software release throught the proper channels at AT&T, but I
don't know what the status is.  

Marc
-- 
_______________________________________________________________________________
Marc E. Fiuczynski		\\  school: (908) 878-2088 home: (609) 683-4416
mef@klinzhai.rutgers.edu  	//  UUCP: {backbone}!rutgers!cs.rutgers.edu!mef

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      29 Feb 92 10:00:56 GMT
From:      fradin@irisa.fr (Marc Fradin)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.protocols.tcp-ip.ibmpc,comp.sys.sun.wanted
Subject:   At Home With X11 Windows ???

I'm looking for a product which enable to work
"at home" with X11 windows on : Mac, PC, Sun station


(dialup at 2400/4800 baud rates)


I know that a Prototype exist for ATARI ST  (X11 server is connected
to a particular "X11/News Helper" via a "compressed" Reliable 
Async. Trans. Protocol) ,
but I don't know how/where to get it ! The author say that performances
were "good" for baud rates as low as 2400.

PS : I already worked whit SLIP/PPP at this speed  with a standard
X11 server (PC X, Mac X, X11 MIT on sun ...) but .... really I can't !


Thanks in advance !

END OF DOCUMENT