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 January 1992 (363 messages, 182752 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 92 03:43:40 GMT
From:      crum@finearts.utah.edu (Gary Crum)
To:        comp.protocols.tcp-ip,comp.arch,comp.graphics
Subject:   endianness, bit/byte/word order, references wanted

Does anyone know of articles about "endianness"?

I know about this one:

Cohen, Danny, "On holy wars and a plea for peace", Computer (an IEEE
publication), October 1981, p. 48-54.

I was wondering if there are other articles about endianness.  Here
are some topics that I am thinking of:  Endianness and...

- common microprocessor architectures.  (The Cohen article mentioned
DEC PDP-10, DEC PDP-11, MC68k and IBM 360).

- software design, e.g. graphics frame buffer organization and
algorithms.

- compiler design, e.g. bit field data types in C.

Thanks,

Gary

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 92 15:27:12 GMT
From:      sg3235@sw1sta.uucp (Stephen Gevers)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on slip

In article <6590@monmouth.edu> ben@monmouth.edu (Bennett Broder) writes:
|>
|>We are planning on setting up a SLIP connection between two SUN 3/60s at
|>different locations.  The connection would be via Telebit modem.  I would
|>like to set it up so that whenever a connection was needed, it would
|>automatically be established.  This could be for mail, ftp or telnet.
|>
|>Is it possible to do this with SLIP?  Any pointers would be appreciated.
|>Please respond by mail, I will summarize if there is interest.
|>
|>
|>-- 
|>
|>Bennett Broder               Monmouth College
|>                             Computer Services
|>ben@monmouth.edu             W. Long Branch, NJ 07764

I'm am very much interested in this.  I don't have a very good understanding
of SLIP and I would like as much information as possible on this subject.  I
am interested in getting pc's set up at home to use SLIP to connect to the
network here at the office.  But I really don't even have a clue to what SLIP
offers!

Stephen Gevers
sg3235@sw1sta.sbc.com

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Jan 1992 17:32:15 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: SLIP gateway on rs6000s with subnets

lpc@ddssuprs.uucp (Luis Caamano) writes:
>We have 3 ethernet segments but we have only one Class C address. We 
>have decided to use subnets.  ...mask 255.255.255.192

The TCP/IP standard precludes the use of subnet numbers of all zeros or
all ones.  Therefore your proposed network mask will only give you two
subnets, those beginning with host numbers 64 and 128 in the fourth octet.
You could use a mask of 255.255.255.224 and get 6 subnets, allowing for
only 30 host numbers on each (remember, host numbers of zero or all ones
are also precluded).

I've also been told by a number of people to avoid using any subnet mask
which divides up the fourth octet.  Many TCP/IP implementations contain
assumptions about network masks which don't allow maximum flexibility.
IBM has told me there was a related bug in their routing code in AIX but
I think it's been fixed; inquire with AIX support to learn more.

What I did was request additional Class C addresses for each subnet; we
now have ten.  Unfortunately the NIC has been down since October; I've heard
nothing back despite repeated email inquiries.

Is this the experience of other people?  Is it possible to obtain new
IP address assignments given the current state of the NIC?  How long is the
wait for a response?

-rich

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jan 1992 19:15:56 GMT
From:      jcook@bach.helios.nd.edu (john cook)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   HP vs IBM


Our college will be a making a final decision (HP vs IBM) in mid-January on a
central administrative computer system.   We will be purchasing a similar 
system from the same vendor for academic computing, but that is a different 
question and already has been posted on Usenet.

The configurations under consideration both have 128 MB RAM and 4 GB disk.
We wil be using Informix On-Line as our database system, using COBOL,
SQL and Wingz as application tools.

The two systems between which we are trying to decide are:
       an IBM Risc System/6000 Model 550
       or an HP 9000 Model 827S
             (FYI: both DEC and SUN submitted proposals which were 
              inappropriate or incomplete)

The primary issues are:
       reliability
       vendor support (hardware and software)
       performance (particularly multi-user - many async terminals and
             some Ethernet terminal sessions)
   
    We will be using another similar system for the programmers  (with
    another copy of Informix and network connectivity)  and for
    anyone else using X-terminals, so the central system will not be
    doing X-serving or graphics.
 
Our evaluation thus far puts these two systems neck and neck, so we are
in dire need of third-party comments.

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

          John L. Cook
          Director of Computer Services        (admin. and academic)
          Saint Mary's College
          Notre Dame, IN  46556   
          (219) 284-4610

          INTERNET:  jcook@bach.helios.nd.edu

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



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 92 19:22:48 GMT
From:      dem@fnhep5.fnal.gov (David E. Martin)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need 56Kbps Synchronous Board and PPP Software

I am setting up a work-at-home application using ISDN lines.  A PC at a
person's home will be used to call a Sun IPX.  On the Sun side I will be
using Brixton's or Morning Star's PPP hardware and software.

Can anyone help me locate the software and hardware for the PC.  All I can
find is PPP for use over analog modems.  I need a PC  board that will do
56/64Kbps synchronous and PPP software that can talk to it.

Please e-mail me and I will post a summary.

Thanks in advance,

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

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jan 1992 20:58:55 GMT
From:      jbotz@mtholyoke.edu (Jurgen Botz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP vs. OSI?

Could someone post a (very) brief summary of reasons why OSI protocols
are preferable (or not) over TCP/IP?  I'm about to hit the books on
OSI (I've studied Comer, so I know IP pretty well) and I thought having
an overview of the major differences would make the process easier...

TIA.
-- 
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 92 21:15:13 GMT
From:      dtaylor@ems.cdc.com (Dave Taylor)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: SLIP gateway on rs6000s with subnets

In article <1992Jan02.173215.16497@kronos.com>, richb@kronos.com (Rich Braun) writes:
|> lpc@ddssuprs.uucp (Luis Caamano) writes

... stuff deleted ...

|> 
|> What I did was request additional Class C addresses for each subnet; we
|> now have ten.  Unfortunately the NIC has been down since October; I've heard
|> nothing back despite repeated email inquiries.
|> 
|> Is this the experience of other people?  Is it possible to obtain new
|> IP address assignments given the current state of the NIC?  How long is the
|> wait for a response?
|> 
|> -rich

The NIC moved in November; are you sure you sent your request to the right place?

Dave Taylor
dtaylor@ems.cdc.com

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Jan 92 23:47:20 GMT
From:      hsteve@hydra.unm.edu ()
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Help on inetd server source

Does anyone know where I can get access to the inetd server source code.  Any
pointer, or comment will be greatly appreciated.

Thanks

--
    _---_     Steve  
   / o o \    hsteve@hydra.unm.edu, hsteve@carina.unm.edu
  | \___/ |   
           Just say NO to VMS!!

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 92 02:02:08 GMT
From:      davidi@deakin.OZ.AU (David Ivens    )
To:        comp.protocols.tcp-ip
Subject:   bootp & DOS 5.0 high not work

We have bootp chips in our PC-NFS v3.5c networked PCs and require more
conventional memory.

I tried DOS 5.0 and dos=high in config.sys but it hung just after the bootp
file was downloaded and with the drive a: light on.

Has anyone been able to do this?

It maybe clashing with the boot rom memory address or we need a later
version of bootp software.

Any advice geatly appreciated.


_______________________________________________________________________
David H. Ivens                                    Ph. 61-052-471508
Computing & Comms. Services,                      Fax 61-052-472010
Deakin University,                                
Geelong, Vic., Australia 3217                 email:davidi@deakin.OZ.AU
-----------------------------------------------------------------------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 92 04:36:32 GMT
From:      pyrros@braindamaged.cis.udel.edu (Christos T. Pyrros)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp & DOS 5.0 high not work

In article <davidi.4@deakin.OZ.AU?> davidi@deakin.OZ.AU (David Ivens    ) writes:
>I tried DOS 5.0 and dos=high in config.sys but it hung just after the bootp
>file was downloaded and with the drive a: light on.

I've noticed that in several computer configuratios, especially 286s, the 
dos=high line in config.sys causes the machine to hang.  By the way,
none of these machines that I've had this occur on are diskless.

Anyone know why?

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jan 1992 08:09:09 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

karn@chicago.qualcomm.com writes:
+---------------
| Note that the "MAC broadcast flag" should also be passed up by IP to
| the transport layer, so point-to-point protocols like TCP can ignore
| broadcasts.
+---------------

However, note also by contrast that some protocols, e.g. VMTP, support
a form of ARP-less bootstrapping by explicitly *allowing* "point-to-point"
transport connections to be established via broadcast MAC addresses --
even before the client system knows the server's IP address, or even
before it knows its *own* IP address!

[After the first couple of packets are exchanged using broadcast MAC
addresses, enough is known to switch to individual IP and MAC addresses.
The claim is that the total number of packets "to get going" is fewer
than with BOOTP/ARP/etc., since useful application data is sent with
the very first packet, and that the number of broadcasts sent is no
greater than with BOOTP/ARP/etc.]


-Rob

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



-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jan 1992 08:18:58 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

karn@chicago.qualcomm.com writes:
+---------------
| But most of these bogus packets will probably be TCP (simply because
| most of the traffic on the net is TCP) and by the rule I mentioned
| earlier, TCP would ignore packets received as MAC broadcasts. So bogus
| TCP packets could not create an ARP storm in any event.
+---------------

That's fine for now, but some of us are thinking about hacking XTP's stream
multicast into TCP, whereupon you *have* to allow MAC broadcast (since in
some environments you have to fake MAC multicast with MAC broadcast).

I think the better answer was one given previously:

1. IP should silently drop any packet that doesn't match one of its IP
   interface addresses, a currently-enabled IP multicast address, the IP
   broadcast address, or (maybe) the obsolete IP broadcast address (zero).

2. No packet received with a MAC-level broadcast *or multicast* should ever
   generate an ICMP error or redirect. [But *do* respond to ICMP echo!]

This will stop the storms without prohibiting some interesting uses of
multicast or broadcast.


-Rob

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



-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Jan 1992 16:36:06 GMT
From:      lpc@ddssuprs.uucp (Luis Caamano)
To:        comp.unix.aix,comp.protocols.tcp-ip,bit.listserv.aix-l
Subject:   Re: SLIP gateway on rs6000s with subnets

In article <1992Jan02.173215.16497@kronos.com> richb@kronos.com (Rich Braun) writes:
>lpc@ddssuprs.uucp (Luis Caamano) writes:
>>We have 3 ethernet segments but we have only one Class C address. We 
>>have decided to use subnets.  ...mask 255.255.255.192
>
>The TCP/IP standard precludes the use of subnet numbers of all zeros or
>all ones.  Therefore your proposed network mask will only give you two

In RFC 950, page 6 it says:
      Special Addresses:

         From the Assigned Numbers memo [9]:

            "In certain contexts, it is useful to have fixed addresses
            with functional significance rather than as identifiers of
            specific hosts.  When such usage is called for, the address
            zero is to be interpreted as meaning "this", as in "this
            network".  The address of all ones are to be interpreted as
            meaning "all", as in "all hosts".  For example, the address
            128.9.255.255 could be interpreted as meaning all hosts on
            the network 128.9.  Or, the address 0.0.0.37 could be
            interpreted as meaning host 37 on this network."

         It is useful to preserve and extend the interpretation of these
	       ~~~~~~
         special addresses in subnetted networks.  This means the values
         of all zeros and all ones in the subnet field should not be
						       ~~~~~~~~~~
         assigned to actual (physical) subnets.

It says useful, but does that mean it can NOT be used? I don't know
how it got implemented. Remember this is the RFC.

>all ones.  Therefore your proposed network mask will only give you two
>subnets, those beginning with host numbers 64 and 128 in the fourth octet.
>You could use a mask of 255.255.255.224 and get 6 subnets, allowing for
>only 30 host numbers on each (remember, host numbers of zero or all ones
>are also precluded).

What would happen if I have a segment on the 0 or 192 network. 
Will I violate the standard or what? It's been working with the 
255.255.255.192 subnet mask. I have a host with IP address 
192.9.200.3 than can telnet to the 192.9.200.130 which is in 
another segment. I get there through a SLIP connection which is 
in network 64. The routing tables work fine (see last paragraph).

Anyway, if the RFC is mandatory, even if it works on AIX, I guess that
means I can not use my proposed net mask to get 4 networks with 62
hosts as you stated. I just want to be sure before we ask for another 
IP address. So, is it mandatory because of convention or because it
will not work properly?

>
>I've also been told by a number of people to avoid using any subnet mask
>which divides up the fourth octet.  Many TCP/IP implementations contain
>assumptions about network masks which don't allow maximum flexibility.
>IBM has told me there was a related bug in their routing code in AIX but
>I think it's been fixed; inquire with AIX support to learn more.
>
I got this From: mengel@dcdmwm.uucp (Marc W. Mengel) on bit.listserv.aix-l

	The config database doesn't add subnetted addresses
	explicitly as network routes at boot, so they default to
	host routes. To work around this wierdness you have to add them 
	via /etc/route and explicitly say they are network addresses.  
	(i.e. /etc/route add net 192...)
			     ^^^
	Add them in /etc/rc.net where the static route commands
	are commented out, after flushing the bogus ones the 
	config database added; like:

		/etc/route -f	# clean out broken host routes
		/etc/route add net ether1 gw1s 2
	...

Thanks Rich for your reply. Since this is more tcpip than aix, I'm
adding a Followup-to comp.protocols.tcp-ip. I guess that's the right
place. We would have to cross-post to bit.listserv.aix-l anyway since
most people there don't have access to usenet.

-- 
---------------------------------------------------------------------------
Luis P. Caamano                    |         
Support Services Engineer          |         uunet!ddssuprs!lpc
Dickens Data Systems, Norcross GA  |         (404) 242-5991
---------------------------------------------------------------------------
If you think you know something, you'll stop learning. -myself

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jan 1992 19:37:49 GMT
From:      chris@rz.uni-karlsruhe.de (Christian Finger)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Help on inetd server source

In article <+t0f==q@lynx.unm.edu>, hsteve@hydra.unm.edu () writes:
] Does anyone know where I can get access to the inetd server source code.  Any

Yes, I do.

] pointer, or comment will be greatly appreciated.
] 
] Thanks

No problem :-)

] 
] --
]     _---_     Steve  
]    / o o \    hsteve@hydra.unm.edu, hsteve@carina.unm.edu
]   | \___/ |   
]               Just say NO to VMS!!

P.S: uunet.uu.net: packages/bsd-sources/usr.sbin/inetd/*

- --  ---   ----    -----     ------      -------       --------        --
  .     Christian Finger         |   SMTP:
 |||    Computer Center          |   finger@rz.uni-karlsruhe.de
\|||    University of Karlsruhe  |   X.400:
    /   D-7500 Karlsruhe 1       |   finger@rz.uni-karlsruhe.dbp.de

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 92 22:01:36 GMT
From:      aultj@caleb.its.rpi.edu (James Ault)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: ISO Country Codes for Baltic and new Russian Republics?


In article <q-crhsh@rpi.edu> aultj@jacob.its.rpi.edu (James Ault) writes:
>
>Does anyone know if ISO has designated two and three letter country
>codes for the Baltic Republics (Lithuania, Latvia and Estonia) and/or
>any of the new Republics (I don't remember their new names)?

In article <1992Jan2.170631.27084@magnus.acs.ohio-state.edu> pjd@magnus.acs.ohio-state.edu (Peter J Dotzauer) writes:

>  Ukraine (UA) and Belarus (BY) have long had ISO 3166 country
>  codes, since they were UN members as Soviet Republics.
 
>  ISO is working on a revision of the ISO 3166 standard, which will
>  include not only country codes, but also codes for the primary
>  subdivisions of all countries as well.

Thanks.  Where can I get a list of the current standard, or the new
standard when it is available?

I received several replies via email, one of which said this topic had
been discussed on comp.protocols.tcp-ip recently.  Could someone from
that group summarize what transpired there?

Specifically, I received this fragment of an article from someone, and
I wanted to ask a question about it:

In article <1991Oct2.225452.2935@corax.udac.uu.se>, andersa@Riga.DoCS.UU.SE (An
ders Andersson) writes:
|> (Following up on an earlier discussion in nordunet.general)
|> In case anyone wonders, ISO has recommended the following two-letter
|> country codes for the Baltic states:
|> 
|> EN - Estonia
|> LT - Latvia
|> LV - Lithuania

It seems logical that Lithuania should not be LV, because it has no V in it:
Latvia should be LV, and Lithuania therefore should be LT.

|> These will probably be formally adopted at the turn of the year.
|> Until then, they are only recommendations.
|> (Source: Svenska Dagbladet of 29-Sep-91)

Any clarifications on this or other recommendations that people are
aware of are welcome.  Followups are directed to comp.mail.misc.

Jim Ault, ITS Systems Programmer, aultj@rpi.edu, +1 518 276 2750    <><

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 92 22:47:29 GMT
From:      jskohl@PacBell.COM (Jeff Kohl)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Looking for XNS software for Sun, Vax, etc.

You might tell him I sent you but don't think that will get you a discount.

Jeff

---------------
I have no affiliation with MCS.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 92 02:08:26 GMT
From:      venki@cs.scarolina.edu (Venki Swaminathan)
To:        comp.protocols.nfs,comp.protocols.tcp
Subject:   RPC/TCP multicasts


I just saw a couple of references on multicast SunRPC on 
comp.protocols.nfs - does this mean people are implementing the
multicast in IP, or are they hacking it within the RPC?
And are there any PD versions of either/both available?

thanx.

-venki

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jan 1992 04:28:31 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.nfs,comp.protocols.tcp
Subject:   Re: RPC/TCP multicasts

In article <venki.694490906@fir.cs.scarolina.edu>, venki@cs.scarolina.edu (Venki Swaminathan) writes:
> 
> I just saw a couple of references on multicast SunRPC on 
> comp.protocols.nfs - does this mean people are implementing the
> multicast in IP, or are they hacking it within the RPC?
> And are there any PD versions of either/both available?


Silicon Graphics has been shipping IGMP support (IP multicasting) for
a long time.  Since people played dogfight at Interop90 using mrouted
tunneling forwarders, it must be years.  That Deering multicast
code is available somewhere.  At Stanford, maybe?  It was integrated
into source at Berkeley, but didn't make it into the right tree or
something for the last 4.3 release I was told about.


As Brendan wrote, SGI is perfectly willing to offer his extensions to YP
(oops) NIS to anyone interested.


Vernon Schryver,   vjs@sgi.com


-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jan 1992 20:44:53 GMT
From:      ayman@jaber.eecs.umich.edu (Ayman I. Kayssi)
To:        comp.protocols.tcp-ip
Subject:   Etherslip

I am looking for etherslip. I would like to know where I can ftp it from.
Thanks.

-- 
Ayman I. Kayssi                               |    ayman@eecs.umich.edu
Advanced Computer Architecture Laboratory     |   ayman@engin.umich.edu
EECS Department                               +------------------------
The University of Michigan                    |          (313) 764-8033

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jan 1992 22:45:33 GMT
From:      johnson@jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Etherslip

ayman@jaber.eecs.umich.edu (Ayman I. Kayssi) writes:

>I am looking for etherslip. I would like to know where I can ftp it from.
>Thanks.

owl.nstn.ns.ca in pub/pc-stuff/etherslip

-Steve

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jan 1992 02:03:31 GMT
From:      tli@fid.morgan.com (Thomas Y. Li - IBM)
To:        comp.protocols.tcp-ip
Subject:   Technical paper on IGRP

Does anyone know of any papers on IGRP?  I heard there is a paper written by
someone in Rugers U.

I need more technical information on IGRP.  Thanks.
Please RSVP via email.
-- 
---------------------------------------------------------------
Opinions are my own and does not reflect the opinions of IBM.
Thomas Y. Li                 Email: tli@nycvmic4.vnet.ibm.com
IBM Corporation                     tli@morgan.com

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1992 10:58:53 GMT
From:      korn@eris.berkeley.edu (Peter "Arrgh" Korn)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: How Do I Get A Macintosh Connected To Internet Via SLIP?

In <klei28INNs33@agate.berkeley.edu>, ribet@math.berkeley.edu (Kenneth A. Ribet) said:  
>
>There's a version of NCSA Telnet which apparently works with slip.
>...

While I don't use the SLIP features of InterCon's TCP/Connect II software
(house ethernet to a Sun 3/80 which runs the SLIP), their software will
happily talk SLIP.  I got it working once or twice, then moved to
the Sun configuration.

Their software isn't cheap, but comes with a bunch of features (mail,
news, and ftp).  They also have a variety of other TCP/IP-related
software for the Mac, like an NFS-client, and even an X-client (not
recommended for anything beyond a local ethernet; X over a SLIP line
is torture...).

InterCon can be reached at:
950 Herndon Park Way Suite 390
Herndon VA  22070
(703) 709-9890

Peter
-- 
--
Peter "Arrgh" Korn
korn@mica.Berkeley.EDU
{decvax,hplabs,sdcsvax,ulysses,usenix}!ucbvax!mica!korn

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 06:48:20 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: HP vs IBM

If I were you I would do a number of things, first and formost would be to 
see if a PC/Mac platform could do what you want. Why tie yourself into a
proprietary platform? Who are your users going to be and how much training
do you want to provide them? If you users are currently working on PC's/Mac's
and that capability is available - why go to a new O/S? If your users are
not using any type of personal computer - why teach them how to use a dumb
terminal? The current trend is to off-load centralized systems...... Do you
want to pay yaearly maint. costs on both software and hardware? Or do you
want to buy into a technology that only costs you for what you want to pay
for?

Steve

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 06:53:40 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

Industry has taken a very hard hit in the pocket book to get on the TCP/IP
bandwagon in the last two years. And most are not ready to switch to OSI,
dollars make the world go round. When there is a clear advantage to OSI
everyone will be there.....but at this point isn't TCP/IP and RIP the way
most things work?

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 14:12:09 GMT
From:      mailman@Atex.Kodak.COM (Paul Mailman)
To:        comp.protocols.tcp-ip,comp.sys.novell,comp.unix.xenix.sco
Subject:   Best way for TCP/IP & Novell & SCO to play together?

I am posting the following for a friend who is not yet on the Net.  I've
volunteered to act as intermediary until his UUCP connection is up.  I'd
appreciate responses by Email to me.
--------------------------------------------------------------------------
Howdy - I need some sage advice.

We have two 486s running SCO Unix and a Novell 3.1 network (using
arcnet).  I plan to add TCP/IP ethernet connections to the Unix
boxes, and would like to hook in the Novell file server as well.

The requirements, in order of importance:
  1. PCs connected to ethernet network need to do terminal emulation
     on Unix boxes, and need to access Novell server.
  2. We need to transfer files between SCO and Novell - directly
     through ethernet if possible, or passing through arcnet if
     need be.  We'd like to do this in one step, without having to
     create an interim copy on a local hard disk.
  3. (minimal import) We are using the Progress 4GL, and it would be
     helpful to be able to test it with a DOS client and a UNIX server.
     Progress indicates FTP/Hetnet/Excellan as the only supported
     software/hardware combinations.

The problems:  Portable Netware is a (performance) dog and we'd like to
avoid it at all costs.  And every other vendor we've spoken to says
item #2 is impossible.  I don't believe it ...  is it *really* true?
-------------------------------------------------------------------------

-- 
   ///////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
   \\ Paul Mailman                   ==  Internet: mailman@atex.kodak.com //
   // Atex, Inc. (A Kodak Company)   ==          or mailm@atex.kodak.com  \\
   \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////////

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 17:17:04 GMT
From:      cudcv@warwick.ac.uk (Rob McMahon)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: HP vs IBM

In article <19024@leadsv.UUCP> smiller@force.decnet.lockheed.com writes:
>If I were you I would do a number of things, first and formost would be to 
>see if a PC/Mac platform could do what you want. Why tie yourself into a
>proprietary platform?

Well, that's got to be the funniest posting of the year so far ...

Rob
-- 
UUCP:   ...!mcsun!uknet!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 17:39:54 GMT
From:      rah@sppy00.UUCP (MOORE ROBIN)
To:        comp.protocols.tcp-ip
Subject:   Re: PD FTP source?

(BTW, in my original post, I asked for pointers to example source code 
for an FTP server, since I am working on one to be used on a Tandem 
system running the Guardian OS.)

In article <18968@leadsv.UUCP> smiller@force.decnet.lockheed.com rants:
>Haven't people learned that the only way computing is going to really make
>inroads to bith business and academics is that it has to be an open
>architecture? Proprietary means death to the company that promotes it!!!!!

Whoa, there.  Down, big fella.
Your knee-jerk reaction of "proprietary means death" fails to take into
consideration a substantial number of real-world realities, such as:
* the staggering cost of replacing all existing systems with "open" ones,
* the substantial effort necessary to reimplement many years' worth
  of custom-developed software, and
* the necessity for retraining many development & operations staff members.

We are well aware of the benefits of standards and open systems, and
are working towards them in as many areas as we realistically can at this
time.  The project for which I asked assistance will help make some of 
our company's substantial prior investment (both in Tandem hardware and 
our own software developed for it) more accessible by the "open" systems 
of the world.  Rome was not built in a day, after all.

Robin  (rah@oclc.org)
-- 
[          h                           Robin A Hermance-Moore                 ]
[      rrr hhh === mmmmm      rah@oclc.org                (614) 764-6215      ]
[      r   h h     m m m         OCLC Online Computer Library Center          ]
[      r   h h     m m m          6565 Frantz Road, Dublin OH 43017           ]

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 19:33:47 GMT
From:      kline@ux1.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

netnews@leadsv.UUCP (Leads Network News, whoever that really is) writes:
>.....but at this point isn't TCP/IP and RIP the way most things work?

You keep mentioning RIP and IGRP. Haven't you ever heard of OSPF? It is
taking over local network routing from RIP very quickly because of its
better stability and faster response to network reconfiguration. And it's an
open standard too, so lots of vendors will be able to interoperate with OSPF
as they do now with RIP.

/cvk

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Jan 92 00:58:21 EST
From:      hutchir1@bluemoon.rn.com (Bob Hutchison)
To:        comp.protocols.tcp-ip,comp.sys.novell,comp.unix.xenix.sco
Subject:   Re: Best way for TCP/IP & Novell & SCO to play together?

mailman@Atex.Kodak.COM (Paul Mailman) writes:

> We have two 486s running SCO Unix and a Novell 3.1 network (using
> arcnet).  I plan to add TCP/IP ethernet connections to the Unix
> boxes, and would like to hook in the Novell file server as well.
> 
> The requirements, in order of importance:
>   1. PCs connected to ethernet network need to do terminal emulation
>      on Unix boxes, and need to access Novell server.
Novell's LanWorkplace, installed on your clients will give them telnet
and remote print capability plus more.
>   2. We need to transfer files between SCO and Novell - directly
>      through ethernet if possible, or passing through arcnet if
>      need be.  We'd like to do this in one step, without having to
>      create an interim copy on a local hard disk.
I can create files on a 3.11 Novell server's drive just like it was a
local drive on the SCO box, by running PCNFS on the SCO box.  Permissions
are screwey with Novell's way of thinking but it works.
>   3. (minimal import) We are using the Progress 4GL, and it would be
>      helpful to be able to test it with a DOS client and a UNIX server.
>      Progress indicates FTP/Hetnet/Excellan as the only supported
>      software/hardware combinations.
Don't know on this one.  But make sure SCO has the drivers for whatever
netwrok board you choose.  The SCO manuals say any 3COM EtherLink II
board.  But in truth no 10BaseT boards were supported.  Call SCO before
you buy anything, to make sure they can support it.  I use Oracle's
RDBMS on the SCO platform and have several simultaneous DOS clients
linked through SQL*NET over TCP/IP.  Also, be prepared to reconfigure
your SCO kernal's STREAM buffer parameters.
> 
> The problems:  Portable Netware is a (performance) dog and we'd like to
 BARK! BARK!
> avoid it at all costs.  And every other vendor we've spoken to says
> item #2 is impossible.  I don't believe it ...  is it *really* true?
> -------------------------------------------------------------------------
> 
> -- 
>    ///////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>    \\ Paul Mailman                   ==  Internet: mailman@atex.kodak.com //
>    // Atex, Inc. (A Kodak Company)   ==          or mailm@atex.kodak.com  \\
>    \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////////


>>>>>>>>>>>>>>>>>  What is UNIX?                  <<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>  UNIX is only a technical term, <<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>  without almost any vowels.     <<<<<<<<<<<<<<<<<<<<<<<

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 22:17:00 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <1992Jan6.193347.13972@ux1.cso.uiuc.edu>, kline@ux1.cso.uiuc.edu (Charley Kline) writes:
> netnews@leadsv.UUCP (Leads Network News, whoever that really is) writes:
> >.....but at this point isn't TCP/IP and RIP the way most things work?
> 
> You keep mentioning RIP and IGRP. Haven't you ever heard of OSPF? It is
> taking over local network routing from RIP very quickly because of its
> better stability and faster response to network reconfiguration. And it's an
> open standard too, so lots of vendors will be able to interoperate with OSPF
> as they do now with RIP.


Let's not get too carried away by the enthuisasm of the moment.
OSPF is great and wonderful, but I doubt it's displacing RIP anywhere.

RIP is just too available, simple, and robust for the networks which can
and already do use it.  Where RIP is popular, "enterprise" networks of as
many as several hundred IP networks (and, of course, XNS), there is no
immediate reason to switch.

OSPF is a replacement for EGP &co in networks which are or are thought to
be too complicated for RIP.  OSPF is called wonderful for wide area
networks.  The places which are switching to OSPF are those which have long
disdained RIP.

OSPF implementations are available, but they're not on every UNIX machine.
OSPF is available in precisely some of the places where EGP, IGP, and HELO
implemenations are also available.



Vernon Schryver,   vjs@sgi.com

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 22:47:34 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   Are TCP connection requests queued are stacked?

We are using Suns in our system and are using TCP stream sockets
for communication between our processors.
My question is "are connection requests queued (FIFO) or stacked (LIFO)
when the server process is not doing accepts".
I did the following test:
    server process:
        create a socket
        bind
        listen
        sleep 60 seconds           <---- this is important
        while forever 
            accept connection
            read msg from socket
            close socket
            echo msg to screen
        done

    client process:
        open socket to server process
        write msg to socket
        close

I ran the server process and then (while the server was sleeping)
ran the client process 10 times with a unique message each time.
When the server finished the sleep it processed each connection
but in LIFO order (reverse of the order I sent the msgs).
Is this normal and, if so, can the server socket or TCP be configured
so that the connection requests are handled in FIFO order (the order
that they are attempted)?

Please drop me a line and I will post useful responses.
thanks
Doug Toppin
uunet!melpar!toppin

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 92 22:53:26 GMT
From:      Jeff_Young@ALW.NIH.GOV
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

Excerpts from netnews.comp.protocols.tcp-ip: 6-Jan-92 Re: TCP/IP vs.
OSI? Charley Kline@ux1.cso.ui (473)

> netnews@leadsv.UUCP (Leads Network News, whoever that really is) writes:
> >.....but at this point isn't TCP/IP and RIP the way most things work?
 
> You keep mentioning RIP and IGRP. Haven't you ever heard of OSPF? It is
> taking over local network routing from RIP very quickly because of its
> better stability and faster response to network reconfiguration. And it's an
> open standard too, so lots of vendors will be able to interoperate with OSPF
> as they do now with RIP.
 
> /cvk

I know that OSPF has been touted for some time as the answer
to what ails, but just who has implemented it so far?
___________	
	jy
	young@heart.dcrt.nih.gov

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 00:49:16 GMT
From:      wjq@uts.amdahl.com (Bill Quigley)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   How do I tell if a socket is connected?

I am passing a socket descriptor to a function, and the function needs
to find out whether the socket is connected.  Is there some ioctl that
does this?  I looked in the man pages for socket, getsockopt, and
sockio with no results.



-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jan 1992 03:11:59 GMT
From:      jch@mitchell.cit.cornell.edu (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

> RIP is just too available, simple, and robust for the networks which
> can and already do use it.  Where RIP is popular, "enterprise"
> networks of as many as several hundred IP networks (and, of course,
> XNS), there is no immediate reason to switch.

I strongly disagree with the term "robust".  RIP has many shortcomings
and many implementations are leave much to be desired.  Some of RIP's
major shortcomings are:

 * Bandwidth.  For "several hundred" IP networks a router needs to
   send close to a dozen RIP packets every 30 seconds per interface.
   And process close to a dozen packets per router on each interface.
   Most of the contents of these packets are "reserved" bytes that are
   not used, but must be present.

   OSPF floods this information every thirty minutes, using much less
   bandwidth for the required information.

 * Dynamics.  It can take several minutes to propagate changes in
   topoplogy or to notice that a router is down.

   OSPF can propagate changes in topology in fractions of a second,
   and detect a router being down in less than a minute.

> OSPF is a replacement for EGP &co in networks which are or are
> thought to be too complicated for RIP.  OSPF is called wonderful for
> wide area networks.  The places which are switching to OSPF are
> those which have long disdained RIP.

OSPF is not a replacement for EGP, OSPF *is* a replacement for RIP.
BGP is a replacement for EGP.  It is wonderful for any network having
more than a handful of IP nets/subnets.

> OSPF implementations are available, but they're not on every UNIX machine.
> OSPF is available in precisely some of the places where EGP, IGP, and HELO
> implemenations are also available.

An alpha version of gated is available which runs on quite a wide
variety of Unix systems, contact gated@gated.cornell.edu if you are
interested.  Hopefully a beta or production version will be available
in a couple of months.

To be fully functional, a Unix system should have support for
local-wire IP multicasting and variable subnet masks, but it is
possible for a Unix system to run OSPF without these with some
restrictions in topology.

Jeff

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 05:13:44 GMT
From:      hedrick@dumas.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, tli@fid.morgan.com
Subject:   Re: Technical paper on IGRP

see athos.rutgers.edu:/pub/igrp.doc and .ps  (plain ASCII and
Postscript, respectively).

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 05:51:26 GMT
From:      pwickman@carroll1.cc.edu (Paul J. Wickman)
To:        comp.protocols.tcp-ip
Subject:   SCO TCP/IP error


	I am getting an error on my SCO Unix TCP/IP installation.
After I reboot it works fine for about a day, and then I get the
following error whenever I try a network application (telnet, etc.):

telnet: socket: out of stream resources

	Any ideas?  Please respond via email.

thanks

-- 
Paul J. Wickman - Systems/Network Administrator, Computer Science Dept.
Carroll College	 Waukesha, WI 53186
Internet: pwickman@carroll1.cc.edu	Phone: 414-524-7343

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jan 1992 07:27:54 GMT
From:      eajjs@cbnewsf.cb.att.com (john.sottile)
To:        comp.protocols.tcpip,comp.protocols.ppp,biz.comp.telebit
Subject:   Using NFS over dialup Lines (SLIP/PPP)

We have been experimenting with NFS over SLIP and PPP
using Telebit's NetBlazers with 2 t3000 modems.  Here are some
observations and NFS configurations that we used to optimize NFS.  It
may help some folks out there.


Equipment:
SUN Sparc 1, 1+, 2
SUN 4/390 File Server
4 t3000 Modems (2 on each end)
2 Telebit NetBlazers (2 port Serial Card on each)
    Telebit's 1.20 NetBlazer Software
We Run SLIP over these Dialups.


We tuned NFS via the /etc/fstab options to use a retrans=300,
rsize=4096,wsize=4096.

Read Size and Write Size = 4K  (we found that 2K per t3000 modem pair
works nicely)
Retransmission  = 300 tenths of a second (30 Seconds).  This is a bit
excessive, but our NFS File Server has 12 NFSD and rarely looses a
packet.  We will wind up backing this down to about 20-25 seconds if
the 30 second timeout is too long.

Since SUN's NFS uses RPC (which uses udp), you can use 
/usr/etc/nfsstat -c 
to find out how many packets are retransmitted.  Still further, 
you can read the 
MANAGING NFS and NIS from O'Reilly and associates; the Performance
Chapter to tune for the optimum performance for your dialup/slow speed
connection.

This book, along with almost every other O'Reilly Book, is fantastic
in helping to deal with day to day problems.  This is the best book on
NFS and NIS that I have seen yet (no, I am not associated with
O'Reilly).

Tuning the MTU and TCP Window Size on the NetBlazer s also help to
keep fragments down.  The 2K rsize per modem helps to keep the
NetBlazer's queue full.  With 2 pairs of modems (2 phone lines), 2K
per modem pair helps to keep both modems pushing data.  The MTU we use
is 1500 on the netBlazers (almost the same as Ethernet), the TCP
Window Size we use has varied from 4K to 8K.  This doesn't help NFS,
but it does help TCP/IP packets.  Using 4K for 2 modems causes the
NetBlazer to fragment the data and send the fragments over both
modems.  Telebit suggests 512 byte packets for SLIP, but the TCP/IP
traffic is high and the modem isn't kept as busy thus some lost
bandwidth.  The key here is the retrans.  NFS from SUN is implemented
with RPC and winds up being a farily synchronous implementation.
Therefore, with a large rsize (the rsize for SunOS is 8K, but this is
too large for dialup) and a large retrans, you can keep the modem
pretty busy.

With the default configuration of NFS, over a dialup we found 80%
duplication in packets.  This is mostly due to NFS being tuned on the
SUN for 10MB ethernet.  With the above options, we found less than 5%
duplicate (mostly in the 2% range) which is acceptable.  With the 2
port Serial card on the NetBlazers, asy00 + asy01 < 56Kbps.  This
holds true since we see between 4.5K/s and 5.3K/s transferred with NFS
over dialup.  Telebit's 1.40 netblazer OS will allow 56K per asy
allowing us even more performance.  The 8 Port "DIGI" Serial Card (NM8
from Telebit) allows 56K per asy onthe 1.20 version.

Anyone attepting to do NFS over SLIP/PPP could benefit from similar
improvements.  Most NFS implementations have these type of "tunables"
Even those doing NFS over 56K to T1 speed lines can benefit from
tuning NFS in a similar way.

Just some information for anyone interested.  Anyone else have any
further possibilities, drop me a line.


=============================
John Sottile                             "Home is where the Software Grows"
AT&T Creative Software                   #include <std/disclaimer/who-me?.h>
jjs@addams.att.com

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 08:22:28 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: HP vs IBM

I take it this came from someone that thinks only "BIG IRON" can do the 
job. As for proprietary platfroms - show me one that isn't. I believe
that PC's and MAC's can do 99% of what users need, the other 1% need "BIG
IRON" which is why there are VAX 9000's, CRAY's, and CONVEX's around.

Yeh - I really tried to be funny. It's called Requirements Analysis if you 
hadn't heard the term before.

smiller@force.decnet.lockheed.com
Steve


In article <#~|BN3^@csv.warwick.ac.uk>, cudcv@warwick.ac.uk (Rob McMahon) writes:
>In article <19024@leadsv.UUCP> smiller@force.decnet.lockheed.com writes:
>>If I were you I would do a number of things, first and formost would be to 
>>see if a PC/Mac platform could do what you want. Why tie yourself into a
>>proprietary platform?
>
>Well, that's got to be the funniest posting of the year so far ...
>
>Rob
>-- 
>UUCP:   ...!mcsun!uknet!warwick!cudcv	PHONE:  +44 203 523037
>JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
>Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 08:25:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <JCH.92Jan6221159@mitchell.cit.cornell.edu>, jch@mitchell.cit.cornell.edu (Jeffrey C Honig) writes:
> > RIP is just too available, simple, and robust for the networks which
> > can and already do use it.  Where RIP is popular, "enterprise"
> > networks of as many as several hundred IP networks (and, of course,
> > XNS), there is no immediate reason to switch.
> 
> I strongly disagree with the term "robust".  RIP has many shortcomings
> and many implementations are leave much to be desired.  Some of RIP's
> major shortcomings are:
> 
>  * Bandwidth.  For "several hundred" IP networks a router needs to
>    send close to a dozen RIP packets every 30 seconds per interface.
>    And process close to a dozen packets per router on each interface.
>    Most of the contents of these packets are "reserved" bytes that are
>    not used, but must be present.
> 
>    OSPF floods this information every thirty minutes, using much less
>    bandwidth for the required information.
 
My example of several hundred class-C networks using RIP was not
theoretical, tho it was an exaggeration.  `netstat -rn | wc -l` says 114
tonight at my work machine.  That traffic is noticable only when you get
the bursts over a SLIP link.

12 RIP packets/30 seconds * 3 interfaces is trivial on the ether and FDDI
nets around here.  It's more like 12 RIP packets/30 seconds per visible RIP
router per interface.  That's still trivial, <4 packets/sec.  Two people
playing dogfight 10 buildings away put 50 multicast packets/second
throughout this network.

OSPF is more economical, but in the most common inter-networks, a bunch of
LANs, that's irrelevant.  It is very relevant on wide area stuff.

>  * Dynamics.  It can take several minutes to propagate changes in
>    topoplogy or to notice that a router is down.
> 
>    OSPF can propagate changes in topology in fractions of a second,
>    and detect a router being down in less than a minute.

Several minutes is the worst case.  The common case is < 2.  This is not a
significant problem in Local Area InterNets.  Around here things such as
leaky TP drops and persistent black holes unrelated to routing protocols
make people complain, not the odd hiccup when a router is power cycled.
(Otherwise things are properly poisoned in recent BSD routed.)

> > OSPF is a replacement for EGP &co in networks which are or are
> > thought to be too complicated for RIP.  OSPF is called wonderful for
> > wide area networks.  The places which are switching to OSPF are
> > those which have long disdained RIP.
> 
> OSPF is not a replacement for EGP, OSPF *is* a replacement for RIP.
> BGP is a replacement for EGP.  It is wonderful for any network having
> more than a handful of IP nets/subnets.

Yes.  Do we disagree?

> > OSPF implementations are available, but they're not on every UNIX machine.
> > OSPF is available in precisely some of the places where EGP, IGP, and HELO
> > implemenations are also available.
> 
> An alpha version of gated is available which runs on quite a wide
> variety of Unix systems, contact gated@gated.cornell.edu if you are
> interested....

When OSPF has been in a couple of BSD releases, and perhaps appeared on a
Sun release tape and in the USL and OSF sources, OSPF will begin to replace
RIP as the default routing protocol.  Until then, the routing and
router-discovery protocol that is on when most customers take a computer
out of the box must be RIP.  Until gated with OSPF makes it into a BSD
source release, I'll have to continue to direct people to you, as I have
several times already this week.

You skipped the main reason to switch to OSPF.  Makers of dedicated routers
are promising multicast forwarding when OSPF finally arrives.  This is
important to those of us with certain multicast simulation applications.


Vernon Schryver,  vjs@sgi.com

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 12:09:24 GMT
From:      rh0083b@tin.psg.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   FTP for UUCP sites

I'm looking for a hosts that I can send mail to, in order to do FTP to
sites on the internet (aka BITFTP@PUCC for BITNET users). Our net is only
connected via UUCP :-(.

Is there such a service available. Any pointers are appreciated.

Regards,
-Roger

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 12:27:04 GMT
From:      Thomas.Tornblom@nexus.comm.se (Thomas Tornblom)
To:        comp.sources.wanted,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   CRC-32 in software


I'm looking for a fast SW implementation of CCITT CRC-32.

Regards,

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

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jan 92 13:49:22 GMT
From:      cliffb@isavax.isa.com (cliff bedore*)
To:        comp.protocols.tcp-ip
Subject:   Re: Best way for TCP/IP & Novell & SCO to play together?

In article <6115@atexnet.Atex.Kodak.COM> mailman@Atex.Kodak.COM (Paul Mailman) writes:
>I am posting the following for a friend who is not yet on the Net.  I've
>volunteered to act as intermediary until his UUCP connection is up.  I'd
>appreciate responses by Email to me.
>--------------------------------------------------------------------------
>Howdy - I need some sage advice.
>
>We have two 486s running SCO Unix and a Novell 3.1 network (using
>arcnet).  I plan to add TCP/IP ethernet connections to the Unix
>boxes, and would like to hook in the Novell file server as well.
>
>The requirements, in order of importance:
>  1. PCs connected to ethernet network need to do terminal emulation
>     on Unix boxes, and need to access Novell server.

Get the Clarkson Telnet and FTP programs with packet drivers.  We are using
them and are very pleased.

>  2. We need to transfer files between SCO and Novell - directly
>     through ethernet if possible, or passing through arcnet if
>     need be.  We'd like to do this in one step, without having to
>     create an interim copy on a local hard disk.


When in doubt, cheat.  get Pegasus Mail (by David Harris) for Novell.  Get the 
Charon Mail gateway (by Brad Clements) (both via anon ftp from Clarkson).  
Get my transfer programs** or just use uuencode.  Pegasus mail uses uuencode 
for file transfer and so you can mail files back and forth transparently to 
the user.  We are using this also and it works quite nicely.  (Obviously you 
really don't want to do 10Mbyte data files like this but up to 150-200k should 
work OK.)  For the really big files you can use ftp from the PC's (part of the 
Clarkson stuff).  We don't like to do this as a rule because of problems with 
shared password/security issues.


>  3. (minimal import) We are using the Progress 4GL, and it would be
>     helpful to be able to test it with a DOS client and a UNIX server.
>     Progress indicates FTP/Hetnet/Excellan as the only supported
>     software/hardware combinations.
>
>The problems:  Portable Netware is a (performance) dog and we'd like to
>avoid it at all costs.  And every other vendor we've spoken to says
>item #2 is impossible.  I don't believe it ...  is it *really* true?

Obviously we don't think so :^)

>-------------------------------------------------------------------------
>
>-- 
>   ///////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>   \\ Paul Mailman                   ==  Internet: mailman@atex.kodak.com //
>   // Atex, Inc. (A Kodak Company)   ==          or mailm@atex.kodak.com  \\
>   \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////////


**  Here is a short description of the programs I use to transfer files
among our various systems. They have been tested on Ultrix and Xenix and do
work with Pegasus mail/Charon on Novell.  The files take up ~25k and if people
want to try them, send me mail.  If I get enough requests, I'll post them.
(If not I'll mail to those who do request)


	We are a consulting firm using UNIX based systems for our
office automation functions.  We have a large number of non-
technical users who need to transfer binary files among
themselves.  Ftp worked but was cumbersome (Oh I forgot to set
the binary mode etc etc) and it caused some problems with
security and passwords.  In response to these requirements, I
developed a series of shell scripts that use uuencode and forward
files to transfer files between users.  They make use of "user-
friendly" (I hope) scripts to set up the transfer and notify
recipients that a file has been transferred.  It can be invoked
from a command line, i.e.

transfer filename username[@host]

or interactively and it will lead the user through the steps to
set up the transfer.


Cliff
cliffb@isavax.isa.com (work)
cliffb@cjbsys.bdb.com (home)


-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 14:33:55 GMT
From:      Jeff_Young@ALW.NIH.GOV
To:        comp.protocols.tcp-ip
Subject:   Re: Technical paper on IGRP

For anyone who has read the paper by Mr. Hedrick
on Fast IGRP, I'd be interested to compare notes.
We are running Fast IGRP on this campus.
___________	
	jy
	young@heart.dcrt.nih.gov

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 15:22:57 GMT
From:      dans@rehab2.UUCP (Dan Schein)
To:        comp.protocols.tcp-ip
Subject:   Re: Best way for TCP/IP & Novell & SCO to play together?

In article <6115@atexnet.Atex.Kodak.COM> mailman@Atex.Kodak.COM (Paul Mailman) writes:
>  1. PCs connected to ethernet network need to do terminal emulation
>     on Unix boxes, and need to access Novell server.

   We use Novell's "LAN Workplace for DOS" as the TCP/IP tool. Then
   applied BLAST (server version) for a terminal emulator. It seems
   to work real well (except for 1 known Novell bug).

>  2. We need to transfer files between SCO and Novell - directly
>     through ethernet if possible, or passing through arcnet if
>     need be.  We'd like to do this in one step, without having to
>     create an interim copy on a local hard disk.

   Again... LAN Workplace for DOS. It comes with a file copy utility
   (running under Windows) that works similar to File-Manager. For
   those who like a command line you can use FTP. All xfer requests
   must be done from a PC on the network (not from the pc server or
   unix box).
-- 
  Reading Rehabilitation Hospital        _/\_        Those who worked the
  Dan Schein - Information Systems      \    /      hardest, are the last
  RD 1 Box 250                          /_  _\      to surrender.
  Reading, PA 19607                       \/           -= Gary Ward =-

  dans@rehab2.UUCP   -or-   ....{uunet,rutgers}!cbmvax!rehab1!rehab2!dans

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 16:43:44 GMT
From:      bhk@locus.com (Brad Kemp)
To:        comp.protocols.tcp-ip
Subject:   Re: Are TCP connection requests queued are stacked?

In article <238@melpar.UUCP> toppin@melpar.UUCP (Doug Toppin) writes:
>We are using Suns in our system and are using TCP stream sockets
>for communication between our processors.
>My question is "are connection requests queued (FIFO) or stacked (LIFO)
>when the server process is not doing accepts".

In BSD 4.3 and previous based kernels, socket connections were queued in
LIFO ordering. In later kernels this is changed to a FIFO.
There is no way to change the way connections are queued.

Brad Kemp
Locus Computing Corp. 
bhk@locus.com

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jan 92 17:04:12 GMT
From:      rees@dabo.citi.umich.edu (Jim Rees)
To:        comp.protocols.tcpip,comp.protocols.ppp,biz.comp.telebit
Subject:   Re: Using NFS over dialup Lines (SLIP/PPP)

In article <1992Jan7.072754.10321@cbfsb.att.com>, eajjs@cbnewsf.cb.att.com (john.sottile) writes:

  We have been experimenting with NFS over SLIP and PPP
  using Telebit's NetBlazers with 2 t3000 modems.

Hard to believe anyone would try to run NFS over a slow link.  It doesn't do
any client-side caching, does it?  How do you deal with that?

We're running AFS over SLIP here and it seems to work pretty well (after
tuning rx a bit).  Our client caches are about 20 Mb and are persistent
across reboots.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 17:41:40 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP for UUCP sites

In article <1992Jan7.120924.3753@medtron.medtronic.com> rh0083b@tin.psg.medtronic.com (Roger Hunen) writes:

   I'm looking for a hosts that I can send mail to, in order to do FTP to
   sites on the internet (aka BITFTP@PUCC for BITNET users). Our net is only
   connected via UUCP :-(.

UUNET will FTP things for you, by hand I guess.  UUPSI has a new
service called UUFTP.  A UUPSI account costs $25/month, UUFTP costs
another $25/month.  Seems a little pricey, but if you need to FTP, you
need to FTP.

Other vendors may also provide similar services.

I think that some site at DEC has a free ftpmail service set up, but
it's deathly slow, by all reports.  I haven't used it.

Unfortunately, any free FTP service is going to get abused...

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

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 17:49:47 GMT
From:      garethh@sadss.UUCP (Gareth Howell )
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   3270 from VT220 over X.25 (and Unix!)

Hi all,
I wonder if someone can help me with this one.
One of the project groups here has a requirement to connect VT220 
terminals connected to Unix boxes via X25 to a 370 m/f via an Alcatel 8000
FEP. The application is D&B Millenium, which uses 3270 presentation.
Our corporate net is primarily OSI protocols, with quite a lot of tcp/ip;
but this is the first use of 3270.

Several options have been proposed:
1. a 3270 emulator, QLLC over X.25 into the FEP
2. a TN/3270 telnet emulator in the Unix box, TCP/IP over X.25 into the FEP;
which then gateways to 3270.
3. a Telnet over TCP/IP emulator in the Unix box, with a Telnet/3270 emulator
in the FEP.
4. 3270 emulator over ISO COTS to the FEP.

Option 4 is problematic as Alcatel doesn't appear to have COTS yet.
Option 3 gives echoplex across X.25!!!
Option 2 at least does block mode.
Option 1 depends on 3270/QLLC in a Unix environment.

Any other ideas, comments, bullets :-)
Gareth


 _______________________________________________________________________
|Gareth Howell: CAT AP Comms    | Information Technology Services Agency|
|garethh@sadss.uucp             | Department of Social Security         |
|sadss!garethh@eros.uknet.ac.uk | Lytham St Annes, England, FY8 1ZZ     |
|garethh@cix.compulink.co.uk    | +44 (253) 797846 (PSTN)               |
|70374,1267 (CI$)               |      427  64846  (GTN)                |
|_______________________________|_______________________________________|
Disclaimer: The above represents my opinion only. It does not 
necessarily represent the view of my employer.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 19:07:56 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   PSOS+ and PNA+ TCP throughput problems?

We are running PSOS+ on Motorola 147 cards and are adding
the PNA+ TCP/IP package.
With our testing so far it appears that we can achieve
a transmissions rate to a Sun of only about 5kb per second
on a open socket.
This is a lot slower than expected so we have probably done something wrong.
If there is anyone out there using PSOS+ and PNA+ please drop
me a line.
thanks
Doug Toppin
uunet!melpar!toppin

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 92 21:36:57 GMT
From:      covdy@cronos.metaphor.com (Ivan Covdy)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Public TCP/IP for MVS?

Hi there.
Since TCP/IP for MVS is pretty expensive, I'd like to know if 
there any public domain for it.

Thanks.  

-- 
Ivan Covdy   covdy@sargon.metaphor.com   Metaphor Computer System, CA
 *** People are looking for a Mind somewhere in the Universe,      ***
 *** because on the Earth they've been finding only the Stupidity. ***

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jan 92 22:53:48 GMT
From:      mcdowell@exloghou.exlog.com (Steve McDowell)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Disabling ICMP_MASKREQ

This one's for a friend, so please no flames on the setup.  

There is a group of machines on the same wire and a portion of 
the group is actually in a different domain from the rest of 
the group. 

Now, we have a diskless workstation running a BSD variant who,
as part of his boot-up, sends out an ICMP_MASKREQ. Some of 
the machines are subnetted with a different netmask, so that 
when they do their MASKREPLY it could be wrong for the poor
workstation who's trying to boot. As a result, the machine 
usually doesn't come up "network responsive". 

They are stuck with this configuration for the next few months.
Period. Can't change it. 

Now, is it possible to disable the ICMP_MASKREPLY on the machines
sending out the bad data without recompiling the kernel? Anyone
got a patch for that? Is that even necessary? Any other ideas? 

Thanks up front. 


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

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jan 92 05:21:50 GMT
From:      dpayne@isis.cs.du.edu (Dirk Payne)
To:        comp.protocols.tcp-ip
Subject:   Gated 2.0 and SLIP networks

(Before reading this, be aware that I'm really a novice at network admin and
am only trying to setup a workable route to my network at work.)

I have been attempting to set gated (2.0.1.?) to advertise a SLIP network on
my SPARC1 running standard vanilla SLIP. After several edits on the gated
configuration file, the best I can get is a low metric for the local SLIP
connect, but a high metric (16) for the net. Here is (what I think) is the
current configuration:

interface all passive ;

rip supplier {
	defaultmetric 1;
}

propagate rip {
	announce 192.9.223.0 metric 1;
}

The routed daemon (in.routed) simply supplies the local connect address, but
will not advertize the network as accessable. gated, on the otherhand, will
advertise a low hop count to the local host, but a high metric for the net.

If I try to configure the passive slip interface, the gated parser complains
about an unknown interface. The kernel IS initializing the SLIP stream
interface.

Obviously I'm missing something. Any help would be appreciated.

Dirk
--
===============================================================================
"If at first you don't succeed ... hack, hack again!!"    dpayne@isis.cs.du.edu
===============================================================================

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 05:32:02 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        biz.comp.telebit,comp.protocols.ppp,comp.protocols.tcpip
Subject:   Re: Using NFS over dialup Lines (SLIP/PPP)

In article <563c770a.cb12@dabo.citi.umich.edu>, rees@dabo.citi.umich.edu (Jim Rees) writes:
> In article <1992Jan7.072754.10321@cbfsb.att.com>, eajjs@cbnewsf.cb.att.com (john.sottile) writes:
> 
>   We have been experimenting with NFS over SLIP and PPP
>   using Telebit's NetBlazers with 2 t3000 modems.
> 
> Hard to believe anyone would try to run NFS over a slow link.  It doesn't do
> any client-side caching, does it?  How do you deal with that?
> ...

Just fine.

I don't remember the nature of the earliest Sun (internal) code I saw, but
I think it used client caching just like all reasonable NFS implementations
since Sun started lisensing and porting it to other flavors of UNIX.
Remember how NFS is stuck into the system.  It has (r)nodes just like any
other file system.  If your client does any local disk caching (what UNIX
system doesn't?), then your client will do NFS caching.

True, NFS client side caching is (generally but not universally) all in RAM
and not to the local disk.  That matters less today with $37/MB DRAM.  It
takes a long time to fill up your RAM with remote disk stuff at dial-up
speeds.  It takes so long that I'd wonder that the inefficiencies of most
cache-to-disk algorithms would be unacceptible--compared to manual rcp'ing
of what you, the human, really want.

NFS over SLIP over PEP works a little better than over v.32.  NFS mixed
with interactive traffic works fine over v.32.  I use it regularly,
including with SGI's normal, internal source tree maintenance tools which
like to do lots of NFS and TCP.  Yes, I said things about the sanity of
other people who tried it before I did.  Yes, it is slower.  If you copy
10MByte of data, you better expect to wait 3 or so hours.  Yes, even with
TOS queuing hacks, you don't want to use vi over the same link at the same
time as you are transfering a SV kernel source tree.

Does your (and P.Honeyman's?) improved AFS (2.0?) do a lot better?

Have you looked at AFS 3.0?


Vernon Schryver,  vjs@sgi.com

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 05:58:03 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Spray daemon

Could someone please give me a short rundown of how spray and sprayd work?
I.e. is the sprayed host just echoing packets and the spraying computer is
keeping count of the packets which made the round trip, or does sprayd
return the results as seen from the sprayed node? Moreover, what can be the
reason some connections drop up to 60% of short packets, while others drop
none (on the same simple bridged network)

I see some really mind-boggling spray numbers in a mixed Token Ring/E-net
environment, and I'd like to understand them... I should probably read the
relevant RFCs, but they are far away when your modem only does 2400 bps.
Thanks a lot in advance!
 
-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 07:01:24 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

jch@mitchell.cit.cornell.edu (Jeffrey C Honig) writes:
+---------------
| Some of RIP's major shortcomings are:
|  * Bandwidth.  For "several hundred" IP networks a router needs to
|    send close to a dozen RIP packets every 30 seconds per interface.
+---------------

Whoopee-do. Assuming MTU-sized packets, that's a whopping 0.048% (less
than 1/20th of 1%) of an Ethernet. Just running "timed" sucks up a lot
more than that...

+---------------
|    And process close to a dozen packets per router on each interface.
+---------------

If each router talks to three nets and each net has three routers, that's
still less than 1/2 of 1% of a single Ethernet's traffic load on the router.
(The load on each net itself is less: 1/6 of 1%.)


-Rob

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

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jan 1992 07:10:12 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: CRC-32 in software

Thomas.Tornblom@nexus.comm.se (Thomas Tornblom) writes:
+---------------
| I'm looking for a fast SW implementation of CCITT CRC-32.
+---------------

This should be YAFAQ for this list, but...

From a previous posting:

The following C code does CRC-32 in BigEndian/BigEndian byte/bit order.
That is, the data is sent most significant byte first, and each of the bits
within a byte is sent most significant bit first, as in FDDI. You will need
to twiddle with it to do Ethernet CRC, i.e., BigEndian/LittleEndian byte/bit
order. [Left as an exercise for the reader.]

The CRCs this code generates agree with the vendor-supplied Verilog models
of several of the popular FDDI "MAC" chips, so it's probably correct [modulo
any typos I made extracting/sanitizing it from the program that used it].


u_long  crc32_table[256];	/* Initialized first time "crc32()" is called.
				 * If you prefer, you can statically initialize
				 * it at compile time. [Another exercise.]
				 */

u_long crc32(u_char *buf, int len)
{
	u_char *p;
	u_long  crc;

	if (!crc32_table[1])	/* if not already done, */
		init_crc32();	/* build table */
	crc = 0xffffffff;	/* preload shift register, per CRC-32 spec */
	for (p = buf; len > 0; ++p, --len)
		crc = (crc << 8) ^ crc32_table[(crc >> 24) ^ *p];
	return ~crc;		/* transmit complement, per CRC-32 spec */
}

/*
 * Build auxiliary table for parallel byte-at-a-time CRC-32.
 */

#define CRC32_POLY 0x04c11db7     /* AUTODIN II, Ethernet, & FDDI */

init_crc32()
{
	int i, j;
	u_long c;

	for (i = 0; i < 256; ++i) {
		for (c = i << 24, j = 8; j > 0; --j)
			c = c & 0x80000000 ? (c << 1) ^ CRC32_POLY : (c << 1);
		crc32_table[i] = c;
	}
}


-Rob

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




-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 07:15:20 GMT
From:      keith@novell.com (Keith Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Best way for TCP/IP & Novell & SCO to play together?

In article <6115@atexnet.Atex.Kodak.COM> mailman@Atex.Kodak.COM (Paul Mailman) writes:
>
>The requirements, in order of importance:
>  1. PCs connected to ethernet network need to do terminal emulation
>     on Unix boxes, and need to access Novell server.

Our way of accomplishing this is to use the Novell LAN WorkPlace for
DOS product on the NetWare workstations. The LWP4DOS contains both a
Windows 3.0 and a non-Windows telnet clients capable of emulating VT52,
VT100 and VT220 terminals.  The Windows 3.0 telnet client (called Host
Presenter) has many wiz-bang features including a scripting language
similar to that which you find in async comms packages like Crosstalk
and Procomm.

>  2. We need to transfer files between SCO and Novell - directly
>     through ethernet if possible, or passing through arcnet if
>     need be.  We'd like to do this in one step, without having to
>     create an interim copy on a local hard disk.

No problem. The LWP4DOS contains both a character based and Windows 3.0
GUI based FTP clients. Both these can shunt files back and forth
between your UNIX boxes and the DOS NetWare clients. LAN WorkPlace
supports ARCNET so all you need do to wire your whole ARCNET NetWare
network to your Ethernet UNIX systems is drop an Ethernet board in the
3.11 server and set it up as an IP router between your Ethernet and
ARCNET segments. You don't need to fork out the cash to trash your
ARCNET cards and replace them with Ethernet cards in all the NetWare
clients. Good huh? This is what we had in mind when we put the
LWP4DOS/NetWare TCP/IP solution together. LAN WorkPlace TCP/IP supports
Ethernet, ARCNET and Token Ring. NetWare 3.11 TCP/IP supports Ethernet,
ARCNET and Token Ring. Notice a similarity? :-)


>  3. (minimal import) We are using the Progress 4GL, and it would be
>     helpful to be able to test it with a DOS client and a UNIX server.
>     Progress indicates FTP/Hetnet/Excellan as the only supported
>     software/hardware combinations.

In ancient times, I worked for a company called Excelan who got
purchased by Novell. The people who actively develop and market LAN
WorkPlace today are pretty much the same as the ones who developed it
and marketed back in the ancient times. Nothing has changed other than
the product has got even better (check out the review in this weeks
PC-Week) and we all fly the Novell banner.  The Progress Software after
which you lust should still work fine on todays LAN WorkPlace.  Our new
4.0 release required an ABI change that meant that apps written to the
old Excelan LAN WorkPlace (circas 3.2.2 thru 3.5) need to use a special
ABI converter TSR that is supplied with LWP4DOS 4.0. ALmost all apps
that I'm aware of now come in a flavour that use the LWP4DOS 4.0 TCP
transport directly (all the PC X Servers, all the major database
vendors, Oracle, Sybase, Gupta etc...).  Progress isn't one that I'm
aware of so best check with them before parting with the pennies.

LWP4DOS has its competitors by the way, who you should also check out
(in order to make a shrewd and well-informed purchasing decision :-)).
Wollongong, NetManage, the [somebody] River group (ICETCP), NRC and FTP
Software are but a few. There's also freebie stuff like NCSA Telnet,
CUTCP, WINQVT (uses CUTCP), KA9Q and others. Most of the freebies are
to be found on sun.soe.clarkson.edu if you want to have a poke. I don't
think any commercial apps support the freebies though, correct me if
I'm wrong somebody.....

Keith

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

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 09:55:56 GMT
From:      yozawa@isl.mei.co.jp (Takashi Yozawa)
To:        comp.protocols.tcp-ip
Subject:   Does free software of DHCP exist?


Does anyone know free software of DHCP(Dynamic Host Configuration Protocol)?
If any, which ftp site has it?
Thanks in advance.

------------------------------------------------------------
Takashi Yozawa                   E-mail:yozawa@isl.mei.co.jp
Information Systems Research Laboratory
Matsushita Electric Industrial Co.,Ltd.
Kadoma, Osaka 571, Japan
------------------------------------------------------------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 16:19:00 MDT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Best way for TCP/IP & Novell & SCO to play together?

In article <1992Jan8.071520.3945@novell.com>, keith@novell.com (Keith Brown) writes:
> In article <6115@atexnet.Atex.Kodak.COM> mailman@Atex.Kodak.COM (Paul Mailman) writes:
>>
>>The requirements, in order of importance:
> LWP4DOS has its competitors by the way, who you should also check out
> (in order to make a shrewd and well-informed purchasing decision :-)).
> Wollongong, NetManage, the [somebody] River group (ICETCP), NRC and FTP
> Software are but a few. There's also freebie stuff like NCSA Telnet,
> CUTCP, WINQVT (uses CUTCP), KA9Q and others. Most of the freebies are
> to be found on sun.soe.clarkson.edu if you want to have a poke. I don't
> think any commercial apps support the freebies though, correct me if
> I'm wrong somebody.....
> 
> Keith
> 
> -
> Keith Brown                                      Phone: (408) 473 8308
> Novell San Jose Development Centre               Fax:   (408) 433 0775
> 2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM
--------------
	James River Group for ICE programs.
	MS-DOS Kermit works with your products, by design (LWP v3.5 and 4), 
and runs in Windows, but does not do FTP (but does do Kermit protocol). It 
runs with FTP Inc products, as well as with it's own built-in TCP/IP stack.
	Joe D.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 14:47:55 GMT
From:      P88037@BARILVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   RLOGIN on VM/SP?

Question: is there a way to connect from a VM/SP system to a UNIX system
using the rlogin protocol?

would appreciate replies.

               Yair Elharrar
               Bar-Ilan university computing center
               P88037@BARILVM.BITNET or P88037@VM.BIU.AC.IL

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jan 1992 15:06:28 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Best way for TCP/IP & Novell & SCO to play together?

In article <1992Jan8.071520.3945@novell.com> keith@novell.com (Keith Brown) writes:

   LWP4DOS has its competitors by the way, who you should also check out
   (in order to make a shrewd and well-informed purchasing decision :-)).
   Wollongong, NetManage, the [somebody] River group (ICETCP), NRC and FTP
>>>                           James River Group
   Software are but a few.

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

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 16:23:09 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   CSLIP for SVR4?

I'm looking for cslip (or even slip) that will run on System V release 4
and Wollongong's TCP/IP that will dial and log inot a system.  Does
anyone know of just an animal?  Wollongong has slip and cslip included
but it doesn't dial out or do any of the other things I need it to do.

-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jan 1992 19:18:50 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

I agree with Rob Warnock -- OSPF is *wonderful* for large, complex
networks, but the vast majority of networks are small and simple.  RIP
works well enough in such cases that there's little incentive to
switch to something better.

Like it or not, RIP is here to stay for some time, along with the
practice of hosts eavesdropping on RIP broadcasts to learn about
gateways. This latter technique seems to be so politically incorrect
these days that new "router discovery" protocols are being invented to
do the same thing in a different manner.  But again, the present
technique works well enough in most networks that anything new is
likely to be seen as a gratuitous change and ignored. A lesson from
the OSI fiasco that one would expect IETF members to understand... :-)

Phil

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 19:29:02 GMT
From:      ram@lionet.Wesley.OZ.AU (Richard A. Muirden)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Can a socket number be mapped back to a pid or uid?

I am wondering if it is possible to take a socket number (such as
that given by netstat) and trace that back to a pid or uid.. The
obvious use of something like this need not be gone into. I am
not well versed in TCP/IP / UNIX sockets, etc and was wondering
if it is possible.

Any help would be greatly apprieciated!

-richard

------------------------------------------------------------------------------
Richard Muirden,                       | Also final year Computer Science
Systems Administrator (unpaid - gasp!) | Student, RMIT.
Wesley College, Prahran Campus,        | Star Trek fanatic on the side.
Melbourne, Australia.                  | mail: s892024@minyos.xx.rmit.OZ.AU
mail: ram@lionet.wesley.OZ.AU  IRC: GA | phone: +61 3 820 1429 (home)     
-----------------------------------------------------------------------------
     My opinions are my own, not even Spock could work them out!!

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 22:18:36 GMT
From:      slf@well.sf.ca.us (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   Users of NCR's Net Manager?


I guess this is kind of a long shot, but does anyone out there use NCR's
NetManager?  If so, please contact me.  Thanks!

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 23:07:03 GMT
From:      Dale_Semchishen@mindlink.bc.ca (Dale Semchishen)
To:        comp.protocols.tcp-ip
Subject:   Pro-proxy addressing

I am looking for the definition of pro-proxy addressing and reply.

I understand that for this type of addressing the /etc/hosts table
is not required.  Is this a form of the ARP?

Thankyou
--

--
Dale Semchishen              | Internet: Dale_Semchishen@mindlink.bc.ca
Personal Designs Inc.        | tel: (604) 590-0056
                             | Vancouver, BC, Canada

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 23:22:02 GMT
From:      Dale_Semchishen@mindlink.bc.ca (Dale Semchishen)
To:        comp.protocols.tcp-ip
Subject:   Interfacing HP3000/950 (NetIPC) to Standard TCP/IP

I have talked to a local HP rep about their product NetIPC
for the HP3000 Series 950.  It provides a virtual circuit
connection between other HP computers but unfortunately
it is not a standard TCP/IP.

I have the following questions:

1) Has anyone had experience interfacing the HP3000/950 to a non-HP
   platform using TCP/IP ?

2) How is HP's version of TCP/IP different ?

3) I have read from HP documentation that NetIPC only provides
   virtual circuits.  Are we contrained to using virtual circuits
   on the non-HP platform or can we use datagrams (UDP) on one end?

--

--
Dale Semchishen              | Internet: Dale_Semchishen@mindlink.bc.ca
Personal Designs Inc.        | tel: (604) 590-0056
                             | Vancouver, BC, Canada

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 92 23:59:51 GMT
From:      gday@cs.ubc.ca (Gordon Day)
To:        comp.protocols.tcp-ip
Subject:   IP implementation: RARP _and_ ICMP info request?


The question is, should an IP implementation in the real world expect
to need both RARP and the ICMP information request methods for
obtaining the interface's IP address?  In addition, is there an RFC or
other document which outlines basic implementation issues such as this
for a host (as opposed to a gateway) on an internet?

Responses gratefully accepted,

Gordon.

--
Gordon.

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 00:01:02 GMT
From:      LOGIN@bsts00.uucp
To:        comp.protocols.tcp-ip
Subject:   TCP-IP NET SECURITY


I would like to hear from anyone who has implemented (or is knowledgeable
about) the possibility of using a Gateway between 2
TCP-IP Networks to control what users & Nodes on (Net A) have acess to Net B
Nodes and resources or visa-versa.  Assume NFS, HP-UX and routers.  This
is a security issue where one group (Net B) wants to have complete control 
of what Net A can access in Net B.

Is ther any commercial software for this or can it be done by WellFleet routers
or just HP Network utilities and standard telnd.sec and /etc/.rhost type 
file control.

Thank's in advance.

Ron

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 01:21:44 GMT
From:      cws@ovro.ovro.caltech.edu (Curt Seeliger)
To:        comp.protocols.tcp-ip
Subject:   GGP vs EGP question.


I think this is the right conference to post this question to:

I'm going through Comer's TCP/IP book, and I'm struck by the similarity of
GGP and EGP functions.  What are the differences between them, save that
GGP is (so I read) outdated?  Why can't GGP be used instead of EGP?  They
seem to have a nearly identical use.

Thanks,
	curt seeliger
	cur@caltech.bitnet, cws@tioga.ovro.caltech.edu

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 02:41:48 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?


In another politically incorrect vein, what would you say about a
host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and using
the response to populate an ARP cache?  Instead of using ARP?  Only for
destinations on the local wire?
This idea, which I understand comes from VMTP and Cheriton, sounds good to
me.  It seems it should reduce the total traffic, not increase the total
number of broadcasts, and make the TCP handshake faster.  No pain except
the hassle of snagging MAC addresses in responses, which is an obviously
illegal violation of layering.


What about applying the same idea to request-response protocols built on
UDP?  NIS and NFS come to mind.


What about using it instead of a real router-discovery protocol?  If
routers were allowed to forward MAC-level broadcasts, and if hosts did the
right thing with the MAC addresses in responses, all should be great.
(Maybe use a multicast address to reach the router instead of simple
broadcast.)


I realize that the last version of the perversion is officially illegal,
and I think I know one or two reasons why.  However, what if you could
trust all of the stations on the wire to be doing the right thing when they
used it?  What about the other versions?


Vernon Schryver,  vjs@sgi.com


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 02:42:45 GMT
From:      ivar@ppc.ubc.ca (ivar jonsson)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   QNX / ARCNET connectivity


-- 

Is anybody familiar with the problem of connecting a QNX machine to a UNIX machine?
I need to transfer files from QNX to UNIX.
Best would be if I could do this directly through Ethernet.

Thanks for any hints or help,


Ivar Mar Jonsson			E-mail: ivar@ppc.ubc.ca
Pulp and Paper Centre			Tel:  (604) 822-8567
University of British Columbia

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jan 92 03:59:03 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

jch@mitchell.cit.cornell.edu (Jeffrey C Honig) writes:

>  * Bandwidth.  For "several hundred" IP networks a router needs to
>    send close to a dozen RIP packets every 30 seconds per interface.

This is less than 0.001 of the network bandwidth.  This isn't enough to
get excited about.

>  * Dynamics.  It can take several minutes to propagate changes in
>    topoplogy

Isn't this an effect of broken RIP implementations?  There's nothing about
RIP that prevents routers from broadcasting an immediate update whenever
its own tables change.

> or to notice that a router is down.

Granted.  But the main problem with RIP is the number of broken
implementations; hosts that don't do split-horizon route elimination, so
routes flail all over the place when routers disappear, plus plain bugs
that cause routing loops to appear during normal operation (like between
SCO and MIPS routed's, argh).

If we get as many broken OSPF implementations as there have been broken
RIP implementations, then OSPF will get a similarly bad reputation.

Vernon may have even understated his main point - it's immensely valuable
to have a protocol that is shipped with basically every machine you can buy,
so you can have a machine working as soon as you plug it in.  Having an
'alternative' protocol where....

> Hopefully a beta or production version will be available
> in a couple of months.

just isn't the same.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jan 92 04:24:54 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Two routed's create a routing loop

Since I just complained publicly about this, perhaps I should check to
see if anyone else has run into it.

We have a situation where 2 machines sit on 3 networks as routers (because
this is a lab environment where we're too cheap to buy real routers) and
when they're connected, their routed's immediately create a routing loop
between themselves.  The situation is this:

                                       ---------+---- lab net 1  192.58.226
                                      /         |
                             --------/       ---'----
 --- backbone 150.124.8 -----|  elf  |      | uplab |
                             --------\      ----,----
                                      \         |
                                       ---------+---- lab net 2  192.84.70

The backbone net is a subnetted class B net, with netmask 0xffffff00.  The
other two are non-subnetted class C's.

Elf is 3-ported and sits on all 3 networks.  Uplab straddles the two class
C's in the lab, and is the preferred router between the class C's.

When elf starts up, its routed broadcasts a route for 150.124.8.0 across
both of the class C net interfaces.  Uplab receives this on one of its
interfaces and, because it has no way of knowing that the class B address
is subnetted, interprets it as a route to the whole class B address,
150.124.0.0.  It broadcasts a route to this effect across its second
interface.  Elf receives this and, because it doesn't have a route to
150.124.0.0 already, adds it, pointing to uplab.

At this point, elf and uplab both have routes to 150.124.0.0, pointing at
each other.

Now, did elf's routed make a mistake in thinking that 150.124.0.0 was a
legal network number, and adding it into the routing table?  It's _almost_
legal, as subnet 0 of the class B address.

On top of that, does anyone know of any good way to keep uplab's routed
from announcing the route to 150.124.0.0, or to keep elf from trying to use
it?

What makes this a _real_ problem is that somehow packets are being injected
into the routing loop, and are causing as much damage as you'd expect.
This is still a complete unknown, except that it never happens when a
sniffer is connected to one of the nets.  This is a lab environment so
almost anything is possible.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 04:34:26 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <v4v7ddo@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> In another politically incorrect vein, what would you say about a
|> host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and using
|> the response to populate an ARP cache?  Instead of using ARP?  Only for
|> destinations on the local wire?

Ugh. I can see lots of reasons why this is a bad idea, so it's not
just "politically incorrect". First of all, any kind of response to a
broadcast packet will generate lots of simultaneous traffic on an
Ethernet, which means lots of opportunities for collisions (remember
rwhod on diskless suns?) If you allowed TCP to respond to broadcast
packets to serve the case of deliberately generating them to gather
MAC addresses, then they'd also be vulnerable to hosts generating
broadcast TCP packets unintentionally, which happens every so often.

Second, it is unnecessary. If you really want to pre-fill your ARP
cache to avoid having to broadcast ARP requests when you need a
certain address, just snoop on the ARP requests others are already
broadcasting. They contain the sender's IP and Ethernet address
information.  Chances are, the hosts you will want to talk to will be
the same ones everybody else is already talking to (your main routers
and servers) so you probably won't have to wait long to get what you
want.  If everybody does this, then everybody could learn everyone
else's Ethernet address after only one broadcast from each host (the
same as with broadcast TCP SYN) but NO additional, non-broadcast
traffic (unlike broadcast TCP SYN).

It's just a simple mod to the existing ARP code and is completely
passive -- you don't have to say anything on the net at all.  I did
something like this a few years back as a way of building a database
of hosts on a very large bridged network (I was mainly interested in
discovering new, unregistered hosts).  Worked like a charm.

Third, it could give wrong results. Suppose some misconfigured host is
routing its traffic to you through some gateway on your network and
ignoring its redirects. You would then associate that host's IP
address with the MAC address of the gateway, and you'd never know the
difference.

Phil

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 05:16:59 GMT
From:      kline@ux1.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In another politically incorrect vein, what would you say about a
>host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and using
>the response to populate an ARP cache?  Instead of using ARP?  Only for
>destinations on the local wire?
 
>This idea, which I understand comes from VMTP and Cheriton, sounds good to
>me.  It seems it should reduce the total traffic, not increase the total
>number of broadcasts, and make the TCP handshake faster.  No pain except
>the hassle of snagging MAC addresses in responses, which is an obviously
>illegal violation of layering.

But it violates the "principle of robustness," which says to be very
conservative in what you put on the media.

It wouldn't take many mistakes in protocol interpretation for a
badly-written IP to try forwarding the SYN since it wouldn't be for its
own layer-3 address, and send an ICMP redirect back to the originator.
Then you wind up with much more traffic than you intended and a
potential broadcast storm.

Also, this scheme forces IP on every machine on the net to get involved
whenever two machines establish a connection. I haven't looked at the
flow of control through ARP vs. IP lately, but I suspect you would be
forcing more work out of uninvolved machines.

Besides, this helps only when the connection establishment is attempted
when the destination machine isn't in the ARP cache. On a network in
stable operation, this doesn't happen very often. I would venture that
your suggested scheme is taking a big risk to interoperability for very
little realized benefit.

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

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 05:44:50 GMT
From:      kline@ux1.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Let's not get too carried away by the enthuisasm of the moment.
>OSPF is great and wonderful, but I doubt it's displacing RIP anywhere.

I'll take issue with that; we use OSPF exclusively on our network of
254 subnets and 170 routers to make routing decisions. We literally
leapt at the chance to use it when it became available to us. Of course
we still have RIP enabled on our routers too, but not to make routing
DECISIONS; only to communicate routing INFORMATION to end systems not
playing the IP routing game.

The reasons for this are precisely the ones the Mr. Schryver cites. Few
hosts implement OSPF; many of the workstations could run gated but are
usually managed by overworked graduate students who have much better
things to occupy their time. However, RIP is just too flappy to
maintain decent connectivity after reconfiguration or failure on a
network the size of ours. OSPF keeps routing tables stable enough that
we are going to actually generate SNMP traps when routes pop in and out
of the routers' tables, since this is invariably evidence that something
interesting has happened somewhere.

>RIP is just too available, simple, and robust for the networks which can
>and already do use it.  Where RIP is popular, "enterprise" networks of as
>many as several hundred IP networks (and, of course, XNS), there is no
>immediate reason to switch.

I would HARDLY call RIP robust. It is so simple that it is hard to
misimplement, but that doesn't make it a good performer on an even
moderate-sized network. RIP went through life being perenially confused
about the state of the network, basing everything it did on a vague
sense of what networks claim to be nearby and reconfiguring only after
long timeouts. I have always called it a "hearsay" protocol.

>OSPF is a replacement for EGP &co in networks which are or are thought to
>be too complicated for RIP.  OSPF is called wonderful for wide area
>networks.  The places which are switching to OSPF are those which have long
>disdained RIP.

No. OSPF is no replacement for EGP. OSPF is an IGP; EGP is, well, an
EGP. A wide area network could well use OSPF internally, but would
always use EGP or its successor, BGP, to communicate routing
information between the wide area network and its client networks.

Your posting had a somewhat defensive posture towards OSPF replacing
RIP, which I don't understand. OSPF is destined to replace RIP even on
those networks not too complicated for RIP, because someday they will
grow big enough to need a sophisticated routing protocol.

Certainly RIP is quite fine on a small network with one backbone and a
handful of client networks, or a bunch of client networks all
inter-routed. There's no point in bending over backwards in such a
situation to run OSPF everywhere when something simpler will work.  But
neither is there any point in having to live with a poorly architected
routing protocol from the 70's such as RIP when it's causing grief,
route flaps, and instabilities. OSPF is only very slightly more complex
to configure than RIP; if it is possible to use it, I don't see any
reason why one wouldn't want to.

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

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 13:59:45 CST
From:      tim@bvc.edu
To:        comp.protocols.tcp-ip
Subject:   SLIP with DECstation 2100's over Sytek lines

We have just purchased two DECstation 2100's and would like to connect them 
together. The two machines are located in different buildings. Is it 
possible to use SLIP over the current Sytek system we are running 
to allow ethernet connectivity??

Any info about SLIP in general would also be appreciated.


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 19:34:40
From:      jason@cnd.hp.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Interfacing HP3000/950 (NetIPC) to Standard TCP/IP

In article <9347@mindlink.bc.ca> Dale_Semchishen@mindlink.bc.ca (Dale Semchishen) writes:

   I have talked to a local HP rep about their product NetIPC
   for the HP3000 Series 950.  It provides a virtual circuit
   connection between other HP computers but unfortunately
   it is not a standard TCP/IP.

Standard TCP/IP, with UDP and all that stuff, has been available for MPE/XL,
the HP 3000 Series 900 OS, for quite a while now. (MPE/XL was recently
renamed MPE/ix. Adds POSIX support.)

Have another chat with your local rep; unless you need NetIPC for some
reason other than generic host-host communication, get the real TCP/IP stuff
instead.
--
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

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 92 15:46:29 GMT
From:      brown@swbatl.sbc.com (Mike Brown 5-7863)
To:        comp.protocols.tcp-ip
Subject:   Non-educational site connections to the "internet"


What are the options for commercial organizations that desire a connection
to the "internet"?  The intended use would be for e-mail and news, not
site interconnection.

What options are available to commercial organizations that want to
use an "internet" to interconnect corporate sites?

Regards,
Mike Brown	Southwestern Bell Telephone Co.
		Information Systems / Corporate Telecommunications
		One Bell Center, Rm. 24-V-5
		St. Louis, MO  63101
		314.235.7863

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 15:49:06 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.sys.ibm.pc.misc,biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Using two Ethernet cards under SCO Unix ?

In article <bhqpxa.ane@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>SCO works ok as a router, though it isn't a very fast one.  In fact, I
>don't know of any way to turn off routing in the kernel (though you can
>disable the routing daemon).  Even if the machine only has a single
>interface, if it gets a mis-addressed packet, SCO will attempt to route it.

In the next SCO TCP/IP release this will be controlled by kernel tunable
parameters.  In the meantime the following program can be used to turn routing
off.

At TCP startup time, as root, run
	kpatch ipforwarding 0
	kpatch ipsendredirects 0

This will disable forwarding of datagrams on systems that you don't want
to act as routers.

-- Steve

#--------------------------------CUT HERE-------------------------------------
#! /bin/sh
#
# This is a shell archive.  Save this into a file, edit it
# and delete all lines above this comment.  Then give this
# file to sh by executing the command "sh file".  The files
# will be extracted into the current directory owned by
# you with default permissions.
#
# The files contained herein are:
#
# -rw-r--r--  1 stevea       1297 Jan  9 09:46 kpatch.c
#
echo 'x - kpatch.c'
if test -f kpatch.c; then echo 'shar: not overwriting kpatch.c'; else
sed 's/^X//' << '________This_Is_The_END________' > kpatch.c
X/*
X * Kpatch -- poke values in the kernel address space
X * Only works for 32-bit values
X */
X#include <sys/types.h>
X#include <sys/fcntl.h>
X#include <sys/unistd.h>
X#include <stdio.h>
X#include <nlist.h>
X#include <errno.h>
X
Xmain(argc, argv)
X	int             argc;
X	char          **argv;
X{
X	struct nlist    nl[2];
X
X	int             r;
X	unsigned        val;
X	unsigned        oval;
X	int             k;
X
X	if (argc < 3) {
X		fprintf(stderr, "usage: kpatch addr val\n");
X		exit(1);
X	}
X	k = open("/dev/kmem", O_RDWR);
X	if (k < 0)
X		error("kmem");
X
X	val = atoi(argv[2]);
X
X	nl[0].n_name = argv[1];
X
X	nl[1].n_name = "";
X
X	nlist("/unix", nl);
X
X	r = lseek(k, nl[0].n_value, 0);
X	if (r == -1)
X		error("read seek");
X	r = read(k, &oval, sizeof(oval));
X	if (r < sizeof(oval))
X		error("read");
X
X	r = lseek(k, nl[0].n_value, 0);
X	if (r == -1)
X		error("write seek");
X	printf("addr of %s = %lx, old value = %d\n", nl[0].n_name, 
X		nl[0].n_value, oval);
X
X	r = write(k, &val, sizeof(val));
X
X	if (r < 0)
X		error("write");
X
X	r = lseek(k, nl[0].n_value, 0);
X	if (r == -1)
X		error("read seek 2");
X	r = read(k, &oval, sizeof(oval));
X	if (r < sizeof(oval))
X		error("read 2");
X
X	printf("addr of %s = %lx, new value = %d\n", nl[0].n_name, 
X		nl[0].n_value, oval);
X	exit(0);
X}
X
Xerror(s)
X	char           *s;
X{
X	perror(s);
X	exit(1);
X}
________This_Is_The_END________
if test `wc -l < kpatch.c` -ne 74; then
	echo 'shar: kpatch.c was damaged during transit (should have been 74 lines)'
fi
fi		; : end of overwriting check
exit 0
-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 17:09:07 GMT
From:      werme@alliant.com (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <v4v7ddo@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>In another politically incorrect vein, what would you say about a
>host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and using
>the response to populate an ARP cache?  Instead of using ARP?  Only for
>destinations on the local wire?

For every TCP connection, even rsh or others that can come thick and fast?

How about just examining broadcasts?  Everytime you get a arp or IP broadcast
that isn't for you, copy off the Ether/IP map before discarding it..

On the other hand, I thought part of ARP's implementation in BSD was to keep
the size of the database down to reduce memory and search time.  Of course,
now that memory really is cheap and computes come in nanoseconds maybe it's
time to stop caring.

>What about using it instead of a real router-discovery protocol?  If
>routers were allowed to forward MAC-level broadcasts, and if hosts did the
>right thing with the MAC addresses in responses, all should be great.
>(Maybe use a multicast address to reach the router instead of simple
>broadcast.)

Maybe the router could just build up it's own table and broadcast them
every so often.  The overhead of one big message is about the same as one
small message.

>I realize that the last version of the perversion is officially illegal,
>and I think I know one or two reasons why.

Hey, one of our people here has been looking at NFS4.1's utimes() and is
finding it boggles the stomach.  (It uses tv_usec == 1,000,000 to mean
something, I forget what.)  Maybe we need one perversion per protocol?
-- 

| A pride of lions              | Eric J Werme                   |
| A gaggle of geese             | uucp: mit-eddie!alliant!werme  |
| An odd lot of programmers     | Phone: 508-486-1214            |

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 17:17:06 GMT
From:      erikm@hardy.u.washington.edu (Erik Madsen)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   REALLY slow client


I'm running A/UX 3.0 on a Mac fx with an Asante Ethernet card.  I connect
to this server from another Mac cx (also with an Asante card) using TCP/IP
supported by NCSA Telnet (MacTCP ver.) software.

My problem is when I connect to my server, everything on my client (the CX)
seems to go REAL slow - for example, if I do a "man cc", the man page scrolls
like it's 1200 baud or something.  If I do the same command on the host
itself, it's fast and there doesn't seem to be any problem.

We have a pretty large network, but I've isolated these two machines on a
multiport box, and the same thing seems to happen.  FTP transfers don't seem
to be excruciatingly slow, that I can tell, but when doing a directory of
the host, it's very slow.  The same thing happens if you've got NCSA Telnet
set up on another Mac and have it available for FTP transfers (meaning just
a regular Mac, no A/UX on it or anything, set up to accept FTP from another
Mac also running NCSA Telnet).

Does this sound like a flaky driver problem, or ...? any suggestions?

Thanks
Erik


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 92 01:34:18 PST
From:      John_A_Pham@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   Where can I find the sofware of Stevens' TCP/IP book?

10 Months ago, I saw the software of Stevens' TCP/IP book at a ftp site.
However, I didn't keep that site address and now I need to find it again.
Does anyone know where I can ftp to?
 
 
JJohn

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 18:37:36 GMT
From:      omar@osf.org (Mark Marino)
To:        comp.protocols.tcp-ip
Subject:   Looking for SLIP and PPP for Ultrix and request for general info.

A desperate call for help echos throughout the net...
 
I'm setting up some dialup IP lines on a DECstation 5000 running Ultrix 4.2
and using a Telebit Netblazer with T2500 modems.  Problem is, I need to find
SLIP and/or PPP for this.   Can anyone please help me!   

I'm also trying to find any info on PPP/SLIP  (preferably for a non-expert)
Where can I find this stuff?????

Will summarize and post responses.


Thanks in advance,
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   |

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 18:38:17 GMT
From:      v026202a@stc-cards.cte.stortek.com (Hal Swanson)
To:        vmsnet.networks.tcp-ip.multinet,comp.protocols.tcp-ip,comp.os.vms
Subject:   EXOS LAN service for VMS source code

I've tried to pull the source for EXOS LAN service for VMS and it wasn't there.
Novell placed it in /pub/vms on their machine available for anonymous FTP
but somewhere along the line, most of the source has been deleted and they
aren't able to locate it on tape anywhere.

If anyone knows where I can pick up the source, please email me.

Thanks in advance.
-- 
Hal Swanson -  StorageTek (OIS Systems Support Group)
Internet: Hal_Swanson@Stortek.Com
USmail:	StorageTek / Louisville, CO / 80028-8110
Phone:	(303) 673-6063
FAX: (303) 673-5019

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 19:29:59 GMT
From:      dennis@CAnet.CA (Dennis Ferguson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <1992Jan8.191850.1447@qualcomm.com> karn@chicago.qualcomm.com writes:
>Like it or not, RIP is here to stay for some time, along with the
>practice of hosts eavesdropping on RIP broadcasts to learn about
>gateways. This latter technique seems to be so politically incorrect
>these days that new "router discovery" protocols are being invented to
>do the same thing in a different manner.  But again, the present
>technique works well enough in most networks that anything new is
>likely to be seen as a gratuitous change and ignored. A lesson from
>the OSI fiasco that one would expect IETF members to understand... :-)
>
>Phil

I always am suspicious when the "political correctness" argument is used
to justify a technical opinion, as was done above.  While I may or may
not agree with the above, I'd like to point out a technical justification
for working on a router discovery protocol rather than just assuming we'll
be able to depend on RIP for host routing forever.

(1) While OSPF might not be everyone's cup of tea, there will be networks
    which replace RIP (for routing, at least) with OSPF.  OSPF is a much
    better routing protocol, and may eventually support useful things like
    multicast routing which RIP doesn't.

(2) There will be other networks which might not care about OSPF, but
    want to route CLNP.  They will need to use IS-IS for the latter.
    Now, if you are already running IS-IS on all your routers for CLNP,
    it is silly to continue to run RIP to route IP since it doesn't
    cost much of anything to have IS-IS do the IP routing as well, and
    IS-IS is a much better routing protocol.

(3) In both the above cases it may be possible to continue to run RIP for
    the sake of the hosts.  On the other hand, it may not.  Both OSPF
    and IS-IS support variable-length subnet mask routing, and if this
    feature is taken advantage of RIP may become incapable of passing
    correct routing information to the hosts.

    I guess using addressing topologies which RIP can't support might be
    considered a "gratuitous change" as well.  Consider, however, that
    we are running out of IP address space.  Almost half the class B
    addresses have already been assigned, and at the current rate of
    growth they'll all be gone in another 2 years.  Now there is no
    shortage of ideas for extending the life of the address space, by
    reassigning space from other address classes and by demanding more
    efficient utilization of already-assigned addresses, but virtually
    all of the workable suggestions are predicated on the deployment and
    use of routing technology which supports variable-length mask routing.
    RIP just gets in the way.

(4) This doesn't mean RIP will go the way of the dodo, however, since there
    is always a place where a simple, easy-to-implement reachability (I
    hesitate to call it routing) protocol is important to have.  I suspect
    what will happen is we'll get a new version of RIP which also carries
    network masks, and hence which can carry information about the address
    topologies the other protocols can support.  This new version of RIP
    will certainly have no way to interoperate with the old version in
    general, obviously, since it will carry information the old version
    has no way to understand.

(5) So now we need a new host routing protocol to run on our hosts.  This
    could be the new version of RIP, I guess.  I note, however, that to
    make use of this each and every host would also need a kernel
    forwarder which understands variable-length subnets as well.  In effect,
    you'd need to change the kernel IP implementation in addition to the
    routing protocol application.  On the other hand a properly designed
    router discovery protocol should allow existing hosts to find working
    routers, and get the next hop right on active connections, without
    requiring IP changes.

I would likely agree with your opinion of "router discovery" protocols
versus RIP if nothing else were changing.  I think, however, that a lot
of us aren't going to be able to avoid variable-length-mask routing for
much longer, and I think this prospect is more than sufficient justification
for having a replacement for host-routing-via-RIP in the form of a
purpose-built protocol.

I don't think dismissing this view as "political correctness" does anything
to prove that it is incorrect.

Dennis Ferguson

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 19:57:49 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: 3270 from VT220 over X.25 (and Unix!)

In article <oT17DB2w164w@sadss.UUCP> garethh@sadss.UUCP (Gareth Howell ) writes:
>I wonder if someone can help me with this one.
>One of the project groups here has a requirement to connect VT220 
>terminals connected to Unix boxes via X25 to a 370 m/f via an Alcatel 8000
>FEP. The application is D&B Millenium, which uses 3270 presentation.
 
>but this is the first use of 3270.
   
   You have our sympathies....
>
>Several options have been proposed:
>1. a 3270 emulator, QLLC over X.25 into the FEP
   
      Talk to your Unix box vendor.  There are 3270 QLLC emulators
      on the market.  Nynex/SSI makes one.

      Question would be whether or not your specific box  supports
      this.

      You might also want to just use an async interface and an
      external async-to-3270 convertor.  Harris/Adacom makes one, I
      seem to recall IBM also had one, but can't recall the model
      number.



-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jan 92 19:59:22 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.sys.ibm.pc.misc,biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Using two Ethernet cards under SCO Unix ?

In <bhqpxa.ane@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
> 
> In fact, I
> don't know of any way to turn off routing in the kernel (though you can
> disable the routing daemon).  Even if the machine only has a single
> interface, if it gets a mis-addressed packet, SCO will attempt to route it.

This is a problem shared by many networking systems based on the BSD
4.3 code.  However forwarding will cease if the kernel variable
"ipforwarding" is set to 0.  This was not a configurable variable in
the base 4.3 source, and is also not easily configurable in TCP/IP
1.1.3.  However you can use _fst to zero the variable in
/etc/conf/pack/ip/Driver.o and after a rebuild forwarding should stop.

In order to conform to the network RFC that deals with compatibility
issues like this (I have forgotten the number), ipforwarding will be
configurable in future release of TCP/IP.  Also to conform to that
spec, forwarding will be disabled by default.

Enjoy.

---
Larry Philps,	 SCO Canada, Inc.
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM  or larryp%scocan@uunet.uu.net
UUCP:	  {uunet,utcsri,sco}!scocan!larryp
Phone:	  (416) 922-1937

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jan 92 20:20:47 GMT
From:      andrewk@sco.COM (Andrew Knutsen)
To:        comp.sys.ibm.pc.misc,biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Using two Ethernet cards under SCO Unix ?


fitz@wang.com (Tom Fitzgerald) writes:
>SCO works ok as a router, though it isn't a very fast one.  In fact, I
>don't know of any way to turn off routing in the kernel (though you can
>disable the routing daemon).  Even if the machine only has a single
>interface, if it gets a mis-addressed packet, SCO will attempt to route it.

	Old versions of TCP (up to 1.13) require the kernel variable
"ipforwarding" to be set to (long)0 to disable forwarding.  In new versions
(2.0 and above), it is 0 by default (as per HR) and you will be asked when
you add the second interface (using netconfig) whether you want to forward.

Andrew

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 21:02:32 GMT
From:      swan@pws.ma30.bull.com (Joel Swan)
To:        comp.sys.ibm.pc.misc,biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Using two Ethernet cards under SCO Unix ?

stevea@i88.isc.com (Steve Alexander) writes:

>In article <bhqpxa.ane@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>>SCO works ok as a router, though it isn't a very fast one.  In fact, I
>>don't know of any way to turn off routing in the kernel (though you can
>>disable the routing daemon).  Even if the machine only has a single
>>interface, if it gets a mis-addressed packet, SCO will attempt to route it.
 
>In the next SCO TCP/IP release this will be controlled by kernel tunable
>parameters.  In the meantime the following program can be used to turn routing
>off.
 
>At TCP startup time, as root, run
>	kpatch ipforwarding 0
>	kpatch ipsendredirects 0
 
>This will disable forwarding of datagrams on systems that you don't want
>to act as routers.

You can also perform a similiar operation on either the currently
built /unix file or on the /etc/conf/pack.d/ip/Driver.o file
via either adb (if you have the development system)
or /etc/_fst (if you do not have it).

If the /unix file is patched with adb or _fst, then it is not necessary
to change the two ip parameters when tcp/ip is started.  However, if the
kernel is relinked, then you would need to re-patch /unix.

If the Driver.o file is patched, then everytime the kernel is linked,
the patch is already in place.

Here is the steps to follow  (Comments in UPPER CASE):

1. Login as root.

2. # adb -w /unix
        or
   # etc/_fst -w /unix
        or
   # adb -w /etc/conf/pack.d/ip/Driver.o
        or
   # /etc/_fst -w /etc/conf/pack.d/ip/Driver.o

3. * ipforwarding/D          THIS WILL DISPLAY THE CURRENT SETTING

4. * ipforwarding/W 0        THIS SETS IT TO 0

5. * ipsendredirects/D       THIS WILL DISPLAY THE CURRENT SETTING

6. * ipsendredirects/W 0     THIS SETS IT TO 0

7. If the Driver.o file was modified, relink the kernel and reboot.
   If the /unix file was modified, just reboot.


-- 
   Joel M. Swan                                 Email:  Joel.Swan@bull.com
   Bull Worldwide Information Systems, Inc.     Phone:  +1 (508) 294-6096
   MA30-836A  300 Concord Road                    Fax:  +1 (508) 294-6109
   Billerica, MA 01821  

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 21:04:06 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: Two routed's create a routing loop

In article <bhqs9j.btm@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:

[...]
| When elf starts up, its routed broadcasts a route for 150.124.8.0 across
| both of the class C net interfaces.

	At one point, I added code to routed to ``externalize'' subnet
routes for a given logical interface if the interface on which the update
was sent was not part of said logical net.  Similarly, incoming routes
from nets which should not know about a given subnetting were recognized
and (I think) ignored.  All of this solved some problems but may have
created others and I don't believe it ever made it into a distribution,
though presumably one can configure gated to act this way.
	In the given example, elf would have considered itself to have
a route to the whole of 150.124.0.0 (a potentially bad assumption if
all subnets aren't communicating) for purposes of dealing with interfaces
not on 150.124.  So the initial route sent to uplab would be 150.124.0.0
which uplab would re-broadcast on its other interface at a higher metric.
Elf would then see this route and either reject it out-of-hand or let
the metric information take care of it; I forget which.
	I think newer versions of routed will at least not act as uplab but
instead treat 150.124.8.0 as host route.  I don't know if this helps much.

				Dan Lanciani
				ddl@harvard.*

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 21:09:43 GMT
From:      dps@cbnewsi.cb.att.com (prasad.s.dodrbala)
To:        comp.protocols.tcp-ip
Subject:   Question on Multiple IP address for a host


Has anyone heard of a host machine that responds to multiple IP addresses?
I heard some rumblings about this but can't verify the story>
			Thanx dean@qsun.att.com

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 21:49:54 GMT
From:      fwp@Jester.CC.MsState.Edu (Frank Peters)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on Multiple IP address for a host

In article <1992Jan9.210943.28848@cbnewsi.cb.att.com> dps@cbnewsi.cb.att.com (prasad.s.dodrbala) says:
> 
> Has anyone heard of a host machine that responds to multiple IP addresses?

The question is sort of ambiguous so I'll answer it two ways:

1) A single host can be connected to multiple networks.  In that case
   it has an IP address for each network its connected to.  The 
   most common case of this is a router.

2) Many hosts support a feature called proxy arp which allows them
   to be configured to reply to arp requests for a whole range of
   IP addresses.  This is mostly useful for supporting machines
   that won't subnet but are on a subnetted network.

Frank Peters

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 21:52:20 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In <1992Jan9.170907.7362@alliant.com> werme@alliant.com (Ric Werme) writes:

>Hey, one of our people here has been looking at NFS4.1's utimes() and is
>finding it boggles the stomach.  (It uses tv_usec == 1,000,000 to mean
>something, I forget what.)  Maybe we need one perversion per protocol?

Oh god yes, that's always been one of my favorite bugs.  Someone put
together a neat little protocol signal with an out-of-band value ...
and then forgot to put in the code to deal with that special case.
"So what if you change the timestamp of a file to the start of the
epoch, who cares?"  What a botch!

Rob T
--
Rob Thurlow, thurlow@convex.com
Recent poll results show that more Canadians believe that Elvis Presley
is alive than would vote for the current Prime Minister, Brian Mulroney.

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 21:52:40 GMT
From:      huntting@advtech.uswest.com (Brad Huntting)
To:        comp.protocols.tcp-ip
Subject:   Host_Unreachable doesn't deliver error to sockets in SYN_RECV state

Here is my situation:

     o	HOSTX can route packets to HERE

     o	but HERE cannot route back to HOSTX (some router along the way
	sends ICMP Host unreachable)

     o	HERE does socket()/bind()/listen(backlog=5) on port 25

     o	HOSTX trys to connect to HERE (port 25).

     o	The SYNC is recieved, and HERE send the ACKSYNC back.

     o	This causes an ICMP Host Unreachable from router Y.

     o	The error is apparently NOT delivered to the socket, and so the
	socket remains in the SYN_RCVD state!

     o	After a few more attempts by HOSTX to contact HERE/25, a
	netstat will show:

	Proto Recv-Q Send-Q  Local Address  Foreign Address  (state)
	tcp        0      0  HERE.25        HOSTX.3376       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3380       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3378       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3370       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3374       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3372       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3362       SYN_RCVD
	tcp        0      0  HERE.25        HOSTX.3361       SYN_RCVD

     o  At this point the queue length on the socket has been exceeded,
	and no more connections to HERE/25 will be accepted from
	ANYWHERE!

Essentially someone elses routing problems are shuting down my mail
hub!

I'm running SunOS4.1.1 on a sun3/260.  The daemon on port 25 is
sendmail-5.65+IDA1.4.4.  Relevant sections of code can be found in
daemon.c lines 143 through 211 (see end of message).  The accept() call
on line 209 never returns of course since no sockets ever finish the
handshake.  If it makes any difference, HOSTX is a 3b2 (SVR3/WIN).

If anyone as seen anything like this before _please_ write back with as
many details (type of machine, OS, tcp code derived from BSD4.?, etc).
If this is a known bug in BSD4.? is there a fix?  I have as yet been
unable to find anyone at Sun who grocks the situation.


brad
	huntting@advtech.uswest.com
	postmaster@uswat.uswest.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
sendmail-5.65c+IDA1.4.4 src/daemon.c lines 143 through 211:

	DaemonSocket = socket(AF_INET, SOCK_STREAM, 0);
	if (DaemonSocket < 0)
	{
		/* probably another daemon already */
		syserr("getrequests: can't create socket");
	  severe:
# ifdef LOG
		if (LogLevel > 0)
			syslog(LOG_ALERT, "cannot get connection");
# endif /* LOG */
		finis();
	}

	/* turn on network debugging? */
	if (tTd(15, 15))
		(void) setsockopt(DaemonSocket, SOL_SOCKET, SO_DEBUG, (char *)&
on, sizeof on);

	(void) setsockopt(DaemonSocket, SOL_SOCKET, SO_REUSEADDR, (char *)&on, 
sizeof on);
	(void) setsockopt(DaemonSocket, SOL_SOCKET, SO_KEEPALIVE, (char *)&on, 
sizeof on);

	if (bind(DaemonSocket,
	    (struct sockaddr *) &SendmailAddress, sizeof SendmailAddress) < 0)
	{
		syserr("getrequests: cannot bind");
		(void) close(DaemonSocket);
		goto severe;
	}
	if (listen(DaemonSocket, 10) < 0)
	{
		syserr("getrequests: cannot listen");
		(void) close(DaemonSocket);
		goto severe;
	}

# ifdef SIGCHLD
	(void) signal(SIGCHLD, reapchild);
# endif /* SIGCHLD */

	if (tTd(15, 1))
		printf("getrequests: %d\n", DaemonSocket);

# ifdef _PATH_SENDMAILPID
	(void) WritePid();
# endif /* _PATH_SENDMAILPID */

	for (;;)
	{
		register int pid;
		auto int lotherend;
		extern int RefuseLA;

		/*
		 * see if we are rejecting connections
		 */
		while ((la = getla()) > RefuseLA)
		{
			setproctitle("rejecting connections: load average: %.2f
", (double)la);
			Xsleep (5);
		}
		setproctitle("Waiting for connection");

		do
		{
			errno = 0;
			lotherend = sizeof RealHostAddr;
			t = accept(DaemonSocket,
			    (struct sockaddr *) &RealHostAddr, &lotherend);
		} while (t < 0 && errno == EINTR);

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 22:21:19 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <1992Jan9.043426.27144@qualcomm.com>, karn@qualcom.qualcomm.com (Phil Karn) writes:
> In article <v4v7ddo@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> |> In another politically incorrect vein, what would you say about a
> |> host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and using
> |> the response to populate an ARP cache?  Instead of using ARP?  Only for
> |> destinations on the local wire?
> 
> Ugh. I can see lots of reasons why this is a bad idea, so it's not
> just "politically incorrect". First of all, any kind of response to a
> broadcast packet will generate lots of simultaneous traffic on an
> Ethernet, which means lots of opportunities for collisions (remember
> rwhod on diskless suns?) If you allowed TCP to respond to broadcast
> packets to serve the case of deliberately generating them to gather
> MAC addresses, then they'd also be vulnerable to hosts generating
> broadcast TCP packets unintentionally, which happens every so often.

"responding to broadcast" is no more or less than what happens with normal
ARP.  Thus, having TCP resond to MAC broadcast cannot be any worse than
having ARP respond to broadcasts.  If more than one host reponds to a SYN
sent to a broadcast MAC, point-to-point IP address, then your net is dead
anyway.  You at least have multiple machines sharing a single IP address.

(You didn't mention subnetting, so I won't)

> Second, it is unnecessary. If you really want to pre-fill your ARP
> cache to avoid having to broadcast ARP requests when you need a
> certain address, just snoop on the ARP requests others are already
> broadcasting. They contain the sender's IP and Ethernet address
> information.  Chances are, the hosts you will want to talk to will be
> the same ones everybody else is already talking to (your main routers
> and servers) so you probably won't have to wait long to get what you
> want.  If everybody does this, then everybody could learn everyone
> else's Ethernet address after only one broadcast from each host (the
> same as with broadcast TCP SYN) but NO additional, non-broadcast
> traffic (unlike broadcast TCP SYN).

Yes, pre-filling your ARP cache is a good idea. 
No, it is not a substitute for this idea, any more than it replaces real ARP.

> It's just a simple mod to the existing ARP code and is completely
> passive -- you don't have to say anything on the net at all.  I did
> something like this a few years back as a way of building a database
> of hosts on a very large bridged network (I was mainly interested in
> discovering new, unregistered hosts).  Worked like a charm.

see above.

> Third, it could give wrong results. Suppose some misconfigured host is
> routing its traffic to you through some gateway on your network and
> ignoring its redirects. You would then associate that host's IP
> address with the MAC address of the gateway, and you'd never know the
> difference.

You'd never know the difference, and never care because you traffic would
get where it needed to go.


Would you still object if I rephrased the idea as "concatenate the ARP
request and the TCP SYN into a single ethernet packet, and let the
destination respond first with an ARP response, and second with a SYN/ACK?"
There are obvious variations of this phrasing, such as not letting the TCP
respond.  That latter varition clearly involves more traffic on the ether
and is identical with current practice, except for some "padding" at
the end of the ARP frame.



vjs


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 22:53:12 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <bhqr2f.ay2@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:
> jch@mitchell.cit.cornell.edu (Jeffrey C Honig) writes:
> 
> >  * Dynamics.  It can take several minutes to propagate changes in
> >    topoplogy
> 
> Isn't this an effect of broken RIP implementations?  There's nothing about
> RIP that prevents routers from broadcasting an immediate update whenever
> its own tables change.

Recent 4.3BSD routed has "flash update" code.

 
> Vernon may have even understated his main point - it's immensely valuable
> to have a protocol that is shipped with basically every machine you can buy,
> so you can have a machine working as soon as you plug it in.  Having an
> 'alternative' protocol where....
> 
> > Hopefully a beta or production version will be available
> > in a couple of months.
> 
> just isn't the same.


Unfortunately, it's not the same in two ways.  Practically all customers
demand something that just works "out of the box." Practically all readers
of comp.protocols (not to mention the mailing list) demand the lastest buzz
with the most knobs, buttons, and technical panache.

I know the guy who I've been told wrote the original routed (based on the
XNS stuff).  He refuses to talk me about my embellishments to it.  He seems
to consider it a simple tool, necessary and sufficient at the time.  His
attitude about routed seems similar to his attitude about some of his other
famous accomplishments.  Contrast that attitude with that of the system
administrators, implementors, and techno-enthusiasts here or at the IETF
demanding the latest and greatest.  With no one to build the buzz for RIP,
with its age, and with the pecuniary interests of certain router vendors in
in proprietary protocols, RIP has been unfairly condemned.  This is not to
say that OSPF is unlikely to prove better than RIP when it is as old and
well distributed, or that I'm not an enthusiast instead of like quiet Sam.


Vernon Schryver,  vjs@sgi.com


-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jan 1992 23:01:27 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <1992Jan9.051659.28303@ux1.cso.uiuc.edu>, kline@ux1.cso.uiuc.edu (Charley Kline) writes:
> >In another politically incorrect vein, what would you say about a
> >host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and using
> >the response to populate an ARP cache?  Instead of using ARP?  Only for
> >destinations on the local wire?
> ...
>                                                   I would venture that
> your suggested scheme is taking a big risk to interoperability for very
> little realized benefit.

I agree.  That's why I haven't pulled out the coding forms just yet.
Still, I've been toying with the idea as a nonstandard configuation switch
setting, to be used only on networks where you know all of the hosts have
high quality implementations, but are prepared to violate host requirements
in this respect.

I doubt the assertion that everyone's ARP cache is always full.  It is not
true of the networks and implemtations I see daily.  I wonder if it will be
even less true with the larger networks allowed by "switching hubs",
whether ethernet, FDDI, or ATM.  I think the assertion is really that most
machines do not talk to a wide community of other machines.  This is
certainly true of individual workstations.  I wonder about some kinds of
"servers."


Vernon Schryver,  vjs@sgi.com


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jan 92 23:12:25 GMT
From:      jrp@xtree.xtree.com (JIM PICKERING)
To:        comp.protocols.tcp-ip
Subject:   Commercial Internet Providers

We are looking at several commercial Internet providers, and I
would like your opinion of their services (value, reliability, etc.).
We are considering AlterNet, CERFnet, ANS, and PSINet.

Are there any others we should be considering?

jim
-- 
Jim Pickering			|	internet:  jrp@xtree.xtree.COM
XTree Company 			|       uucp:      ...!polyslo!xtree!jrp
4330 Santa Fe Road		|	voice:     (805) 541-0604 X 1807
San Luis Obispo, CA 93401	|	FAX:       (805) 541-8053

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 92 23:13:14 GMT
From:      dheeraj@cs.umd.edu (Dheeraj Sanghi)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Call for Papers: NETWORKS '92: Trivandrum, India.


                         CALL FOR PAPERS

                           NETWORKS 92
                      TRIVANDRUM      INDIA

An International Conference on Computer Networks, Architecture and
Applications.

                       26-28 October 1992

                      Jointly sponsored by
       International Federation for Information processing
                              and
                   Computer Society of India.

The conference provides an international forum for presentation of
recent results in the general area of Networks with special emphasis on
Applications, issues relating to Management, Security and Performance.
More specifically, the topics of interest include, but are not limited
to,

Protocol Related Issues: 

    Multimedia Applications.
    Distributed Applications.
    Distributed Information Management.
    Server-Client Models.
    Task Allocation and Load Balancing.
    Specification and verification of protocols.

Performance Related Issues:

    QOS Measurement.
    Management of QOS.
    Higher Layer Protocol related performance Issues.
    Workload Characterization of Multi Media Applications.

Technology Related Issues:

    Implementation Issues relating to Multi Media Applications.
    High Speed Networks Implementations.
    Wireless Network Implementation.
    Relevance to Developing Countries.

Prospective Authors are invited to submit full papers concerned with
both Theory and Practice.  The areas of interest for the conference
include, but not limited to topics mentioned above.

The conference is single-track.  Only papers of exceptional quality will
be accepted for presentation at the conference and inclusion in the
Proceedings.  There may be a few invited papers of immediate relevance
to the conference.

AUTHORS Please Note:

     * All submissions are refereed

     * Papers should be double spaced and should be less than 20
       pages and should have an abstract

     * There should be cover page giving Title, Authors, Complete
       Address and Affiliation, Telephone Numbers, Fax numbers and
       Electronic Mail Addresses.

     * Authors of accepted papers will be expected sign a copyright
       release form.

     * Participants copy of the proceedings will be preprinted and
       distributed during the conference.

     * Send in your INTENTION TO SUBMIT A PAPER information (Title,
       Authors, Address, Tel.No., Fax No., e-mail address) to
       NET92@shiva.ernet.in or the addresses below.

     * SUBMIT FIVE copies of each paper to the Program Chair in your
       region.


North America               Rest of the World        UK & Europe
USA & Canada          Asia, Japan, China, Aus & NZ

G.V. Bochmann               S.V. Raghavan           Guy Pujolle

Universite De Montreal      Dept. of Computer       Professor-Head,
Dept D'Informatique         Science & Engg.         Dept. of Computer Science
et Recherche                Indian Institute        Universite Pierra et
Operationnelle              of Technology           Marie Curie
Case Postale 6128,          Madras, INDIA.          Laboratoire MASI
Succursale A                                        4, Place Jussieu
MONTREAL (QUEBEC),                                  Paris Cedex 05,75252
H3C3J7, CANADA                                      FRANCE


Telephone :
(514) 343 2155(O)           +91-44-2352377(O)       (1) 39 02 0109(O)
                            +91-44-2350563(O)
                            +91-44-2350732(R)

Telex :
      -                     041-8969                UPMCSIX 200 145F

Fax :
(514) 343 2155              +91-44-2350509          33 1 30 21 19 83

Email :
bochmann@.iro.Umontreal.CA  raghavan@shiva.ernet.in   gp.@masi.ibp.fr


                         IMPORTANT DATES

Deadlines for Paper Submission                 30 April, 1992
Notification of Acceptance                     15 July, 1992
Camera Ready Paper Due                         15, September 1992

There will be FOUR TUTORIALS on current Topics on 25th Oct 1992.

                         PROGRAM COMMITTEE*

Bochmann G V           Univ of Montreal, Cananda       Co Chairman
Pujolle Guy            Univ of Paris VI, France        Co Chairman
Raghavan  S V          IIT Madras, India               Co Chairman

1.  Agrawala A K            University of Maryland        USA
2.  Danthine Andre          Univetsity de Liege           Belgium
3.  Anurag Kumar            IISC  Bangalore               India
4.  Casaca Augusto          INESC                         Portugal
5.  Boutmy Bert             Philips, Eindhoven            Netherlands
6.  Khakar Dipak            IB-ADB  Lund University       Sweden
7.  Kamoun Farouk           Centre National de I'Inf      Tunisia
8.  Haring Gunter           Univ of Vienna                Austria
9.  Harry Perros            NC State Univ.                USA
10. Rudin Harry             IBM Res.Lab                   Switzerland
11. Jain B N                IIT  Delhi                    India
12. Bennet John             Balgowlah NSW                 Australia
13. Puzman Josef            PTT Research Inst             Czechoslovakia
14. Kappel Kim              GIT  Atlanta                  USA
15. Boyanov Kiril           Bulgarian Academy of Sc       Bulgaria
16. Pouzin Louis            Theseus                       France
17. Mehindradatta S L       IIT  Bombay                   India
18. Martrikariner Olli      Telecom Finland               Finland
19. Spaniol Otto            University of Aachen          Germany
20. Ramakrishnan S          DoE, New Delhi                India
21. Ramani S                NCST  Bombay                  India
22. Uhlig Ronald            Northern  Telecom             USA
23. Tohme Samir             Networks Dept, ENST           France
24. Schicker P              Oberhoehe, Ringwil            Switzerland
25. Sobczak W               Tech Univesity of Gdansk      Norway
26. Srivatsan K R           IIT  Kanpur                   India
27. Takagi H                IBM                           Japan
28. Szentivanyi Tibor       Hungarian Telecom Comp        Hungary
29. Tripathi S K            University of Maryland        USA
30. Zimmer W                GMD-FIRST                     Germany
-- 
Dheeraj Sanghi			(h):301-474-3592	(o):301-405-2723
Internet: dheeraj@cs.umd.edu	UUCP: uunet!mimsy!dheeraj
If you want to judge the culture and civilization of a people you can find
that out by the status and conditions of the women of the country. - Nehru

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 1992 02:04:53 GMT
From:      rmtodd@servalan.servalan.com (Richard Todd)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client

erikm@hardy.u.washington.edu (Erik Madsen) writes:
>I'm running A/UX 3.0 on a Mac fx with an Asante Ethernet card.  I connect
>to this server from another Mac cx (also with an Asante card) using TCP/IP
>supported by NCSA Telnet (MacTCP ver.) software.

Much the same setup as is in use at a nearby University I happen to attend:
Mac SE/30s and IIsis running NCSA Telnet w. MacTCP connecting to various
Unix hosts.  

>My problem is when I connect to my server, everything on my client (the CX)
>seems to go REAL slow - for example, if I do a "man cc", the man page scrolls
>like it's 1200 baud or something.  If I do the same command on the host
>itself, it's fast and there doesn't seem to be any problem.

Yeah.  Happens all the time.  The problem is simply that NCSA Telnet is,
without a doubt, the *slowest* terminal emulator program I've seen in my life.
Period.  Even my TRS-80 Model I with my own homebrew terminal program could
put characters on the screen faster than that.  Alas, NCSA Telnet is the
only freeware telnet client I know of for the Mac, so you either learn to 
like slow displays or shell out the bucks for some commercial networking
package.  I note that xterm displays just fine on the MacX server, and does so
with what seems like blinding speed compared to NCSA, plus it also lets you
run GhostScript and other famous X Window goodies :-). 

>Does this sound like a flaky driver problem, or ...? any suggestions?

Hope that NCSA speeds up their code.  As I recall, some of the earlier 
releases were even slower...
--
Richard Todd	rmtodd@uokmax.ecn.uoknor.edu  rmtodd@chinet.chi.il.us
  rmtodd@servalan.uucp  New Improved Domain: rmtodd@servalan.servalan.com
"Elvis has left Bettendorf!"

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 03:43:24 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Telnet negotiation

I need to add some simple telnet negotiation to an application which we access
by telneting to a tcp/ip port.  Looking through a list of telnet option codes I
do not see one which puts telnet into character mode instead of line mode.

Is it tied to TELOPT_ECHO ?

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

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 1992 04:54:57 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

karn@chicago.qualcomm.com writes:
+---------------
| vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
| |> In another politically incorrect vein, what would you say about a
| |> host sending TCP SYN's and SYN/ACK's to broadcast MAC addreesses, and
| |> using the response to populate an ARP cache?  Instead of using ARP?
| 
| Ugh. I can see lots of reasons why this is a bad idea, so it's not
| just "politically incorrect". First of all, any kind of response to a
| broadcast packet will generate lots of simultaneous traffic on an Ethernet...
| If you allowed TCP to respond to broadcast packets to serve the case of
| deliberately generating them to gather MAC addresses, then they'd also
| be vulnerable to hosts generating broadcast TCP packets unintentionally...
+---------------

Phil, you missed the point of the scheme. (To be fair, Vernon wasn't totally
clear in presenting it.) The object isn't to "gather MAC addresses" per se,
or even to "populate the ARP cache", except for those IP addresses you would
have ARP'd (broadcast) for anyway.

Here's how it works: You send TCP "SYN" with a broadcast Ethernet address
but the correct *unicast* IP address for the destination you're trying to
talk to -- that's *one* broadcast packet, same as with ARP. Since the unicast
destination IP address inside the broadcast doesn't match, [hopefully] nobody
but the desired target host responds. The intended target *does* respond,
with a *unicast* TCP "SYN/ACK". On seeing *any* "SYN" (including the "SYN/ACK"
reply), "tcp_input()" reaches over into the ARP cache and installs the source's
MAC & IP addresses. Now everything proceeds from there as usual, since the
correct entry is now in the ARP cache.

[Note: Just as with ARP, it is important that the destination host installs
*your* address in his ARP cache -- based on seeing your "SYN" -- *before*
attempting to reply to the TCP connection request, so that when he does
reply he doesn't need to ARP for your IP address.]

Compared to the usual ARP Request, ARP Reply, TCP SYN, TCP SYN/ACK sequence,
this scheme causes exactly the same number of broadcasts (exactly one), but
generates two fewer packets (namely, you leave out the ARP packets).

Like Vernon said, this idea is not new. I first heard it from David Cheriton
in a talk on VMTP. He was talking about even higher levels of "self-locating"
services (my term). For example, when first trying to do a YP or X.500 lookup,
you may not know who the servers are. So you use a multicast IP destination
address, with a multicast Ethernet destination (or even broadcast, if the upper
layer doesn't map multicast to 48-bit as nicely as IP's Class E -- e.g.,
ISO TSAP). And then you cache the *unicast* source address(es) that come
back with the results.

Where you have a lot of hosts doing occasional request/response transactions
to a lot of different hosts, Cheriton's scheme can *save* significantly on
network traffic, by piggybacking the address resolution on the upper-level
query data.

If this had been widely enough understood early enough in the development
of LANs, we might not have needed to invent ARP at all...


-Rob

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



-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 1992 06:05:00 GMT
From:      richg@locus.com (Rich Greenberg)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: 3270 from VT220 over X.25 (and Unix!)

In article <oT17DB2w164w@sadss.UUCP> garethh@sadss.UUCP (Gareth Howell ) writes:

>One of the project groups here has a requirement to connect VT220 
>terminals connected to Unix boxes via X25 to a 370 m/f via an Alcatel 8000
>FEP. The application is D&B Millenium, which uses 3270 presentation.
>Our corporate net is primarily OSI protocols, with quite a lot of tcp/ip;
>but this is the first use of 3270.

Is the use of the FEP necessary?  If the 370 is running VM or MVS,
you can get IBM's excuse for TCP/IP and an 8232 or 3172 or other
370-ethernet adapter and tn3270 right to the 370.

-- 
Disclaimer: The above writings are the ramblings of one human being
        and have nothing what-so-ever to do with Locus Computing Corp.
   ---> Rich Greenberg,  richg@locus.com    TinsleTown, USA  310-337-5904
 Located in Inglewood, Ca, a small city completely contained within Los Angeles

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 08:05:07 GMT
From:      NAU_T@rzmain.rz.uni-ulm.de (NAU THOMAS)
To:        comp.protocols.tcp-ip
Subject:   Routing between 2 Interfaces on HP370

I do have problems with my HP370 under HP-UX 8.0.
There are two interface cards using the addresses 134.60.80.72
and 134.60.79.1. 
The problem is how to route packets from 134.60.79.xx to the other interface
which may access any host using the default gateway of the University.
The hosts on 134.60.79.1 are local.

Thanks for any idea (please remember the netmask)

Thomas

nau@expane.medizin.uni-ulm.de
root@expane.medizin.uni-ulm.de
nau_t@rzmain.rz.uni-ulm.de
nau@rzmol2.rz.uni-ulm.de

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 1992 10:11:39 GMT
From:      Olivier.Meirhaeghe@fifi.univ-lyon1.fr
To:        comp.protocols.tcp-ip
Subject:   Help on WHOIS Port ?


		HI.

	Does anybody knows if the TCP WHois Port is still used ? that is
	do a lot of machine run a whoisserver ? or only Finger ?

	

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 13:51:50 GMT
From:      fenyo@pegase.enst.fr (Alexandre Fenyo)
To:        comp.protocols.tcp-ip
Subject:   Question about how networks analyse ports in which datas are transfered

Perhaps I am wrong, but I think that networks have to know which port a datagram is sent to. But they are scattered in the IP-level and its header only contains the internet address of the destination computer. The destination port is in the TCP-header. So, how can a network know which destination port is relative with the datas that it is to transport (for instance datas destinated to a port 25 need less priority than datas destinated to a port 23).

Many thanks.

Alexandre FENYO
Telecom Paris
Email address : fenyo@inf.enst.fr

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 1992 15:19:19 GMT
From:      mike%jim.uucp@wupost.wustl.edu (Mike Suter)
To:        comp.sys.ibm.pc.misc,biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Using two Ethernet cards under SCO Unix ?

stevea@i88.isc.com (Steve Alexander) writes:

>In the next SCO TCP/IP release this will be controlled by kernel tunable
>parameters. [...]

Does anyone know when the new release of SCO TCP/IP will be out?  We are
having some problems with hangs resulting from TCP/IP conflicting with
another streams driver, and a new version might help (fingers crossed...)
Thanks!

					mike suter
					mike%jim.uucp@wupost.wustl.edu


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 15:45:38 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find the sofware of Stevens' TCP/IP book?

ftp.uu.net (137.39.1.9): published/stevens.netprog.tar.Z

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 16:00:44 GMT
From:      elsen@imec.be (Marc  Elsen)
To:        comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   Does convex systems have buggy tcp/ip software ?




  Sometimes our VAX 3900 (Ultrix 4.2)  crashes if someone
  does an rlogin to our Convex system.
  Analysis (tcpdump) has shown that the convex is sometimes
  sending packets which are 4 bytes short at the IP level ?!

  Has someone else seen this problem too ?

  (crash syndrome : panic : trap type 14)

					  Marc (elsen@imec.be)

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 17:25:02 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Help on WHOIS Port ?

In article <1992Jan10.101139.6120@fifi.univ-lyon1.fr>, Olivier.Meirhaeghe@fifi.univ-lyon1.fr writes:

> 	Does anybody knows if the TCP WHois Port is still used ? that is
> 	do a lot of machine run a whoisserver ? or only Finger ?

Many sites use whois for access to X.500 data on employees. Try
whois -h llnl.gov oberman. I know some organization has benn collecting
information on Internet whois servers and will be releaseing a list of them in
the near future.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman1@llnl.gov		(510) 422-6955

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

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 18:12:25 GMT
From:      matthews@nethawk.uswest.com (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Secure SLIP Implementations?

Does anyone know if there are any terminal servers or other software
that allow secure SLIP connections.  When I say secure I mostly mean
can the implementation check the source address of every packet coming
through the serial line making sure it matches the one assigned to the user
that was originally authenticated?  I think cisco might be able to do a little
bit of what I'm asking for but I don't think they can be dynamic.  By that,
I mean that I don't think their access-lists can move from port to port as
is needed in dialup situations.  This mechanism would SORT-OF prevent any
non-registered traffic from showing up on the network.  I do realize the
usefulness of being able to setup SLIP links for connecting another network
versus just a host.  We have needs for both.
				Thanks in advance,
					John Matthews
					matthews@uswat.uswest.com

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 1992 18:13:11 GMT
From:      boyd@cs.unca.edu (Mark Boyd)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client

Gee, NCSA telbin has always been very fast at our site, even on 8088
macines and MACs. Perhaps you have hardware problems or configuration
problems. The NCSA software is some of the best I've seen, and I've
spent a lot of time poking around in its innards. Good code. 

	Mark

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jan 92 19:04:18 GMT
From:      pete@wlbr.imsd.contel.com (Pete Lyall)
To:        comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware,comp.sys.ibm.pc.software,comp.os.msdos.misc,comp.protocol.tcp-ip
Subject:   SLIP for IBM PC's?


I'm posting this question for an associate in Tampa without direct net
access. I'll be happy to forward any replies.

Thanks!

Pete Lyall
========================================================================
Posted: Thu, Jan  9, 1992   4:32 PM EST              Msg: CGJC-4292-2423
From:   D.KANDZ
To:     lan.xnet
CC:     p.lyall
Subj:   sl/ip (tcp/ip over serial lines)

I'm attempting to provide access to unix hosts from remote PCs and
Macintosh's and would like multiple sessions and file transfer capability.

If I could find a sl/ip implementation (ip over a serial link), then
telnet and ftp would fill the bill.

Does anyone know of a PC and/or Macintosh implementation of the tcp/ip
"slip" protocol?

Thanks!
Dave Kandz
GTEDS
813-978-6447

========================================================================
-- 
Pete Lyall [GTE]   Compuserve: 76703,4230   Internet: pete@wlbr.imsd.contel.com
                UUCP: {hacgate,jplgodo,voder}!wlbr!pete 
"... So I picked up my pride from beneath the pay phone, and combed his breath 
right outta my hair. And sometimes, it's not so easy ..." J. Hendrix/My Friend

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 19:15:53 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <1992Jan8.191850.1447@qualcomm.com> karn@chicago.qualcomm.com writes:
>>          This latter technique seems to be so politically incorrect
>>these days that new "router discovery" protocols are being invented to
>>do the same thing in a different manner.

In article <1992Jan9.192959.8318@gpu.utcs.utoronto.ca>
   dennis@CAnet.CA (Dennis Ferguson) writes:
>(5) So now we need a new host routing protocol to run on our hosts.  This
>    could be the new version of RIP, I guess.  I note, however, that to
>    make use of this each and every host would also need a kernel
>    forwarder which understands variable-length subnets as well.  In effect,
>    you'd need to change the kernel IP implementation in addition to the
>    routing protocol application.  On the other hand a properly designed
>    router discovery protocol should allow existing hosts to find working
>    routers, and get the next hop right on active connections, without
>    requiring IP changes.

From a practical implementation standpoint, it does not matter whether
it is called a "host routing protocol" or a "gateway discovery
protocol".

If the "gateway discovery protocol" is an ICMP extension, it needs to go
into the kernel. The difference between a kernel change to IP and a
kernel change to ICMP does not seem to be great. In any case, the
EXISTING hosts will not benefit from the change without an update to
kernel software.

Hosts that have IP kernel routing tables without per-route netmasks are
not going to be full-featured hosts in the brave new network world.
Perhaps the kindest thing we can do for them is to put them on a subnet
behind a gateway with IP address translation .... but most sites should
just give them their "coup de grace".
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 20:08:08 GMT
From:      erikm@hardy.u.washington.edu (Erik Madsen)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client

In article <1992Jan10.181311.27528@rock.concert.net> boyd@cs.unca.edu (Mark Boyd) writes:
>Gee, NCSA telbin has always been very fast at our site, even on 8088
>macines and MACs. Perhaps you have hardware problems or configuration
>problems. The NCSA software is some of the best I've seen, and I've
>spent a lot of time poking around in its innards. Good code. 
>
>	Mark

Yes, from what I recall, when I worked at Boeing, we used NCSA Telnet on
our Macs, and it was always very fast... but the difference was, is that we
didn't have to use the MacTCP version of NCSA.  Now I'm noticing this
dog-slow problem, and I wonder if the different versions have something to
do with it... or Apple's MacTCP driver might be the problem (wouldn't 
surprise me that much, either).

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 92 20:58:44 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   PD user space TCP/IP



  I am interested in a user-space PD TCP/IP implementation for 
UNIX(Sun). I would guess that such an animal is possible over 
the streams NIT interface. Does such a thing exist? If not than
are there any serious reasons why it couldn't be built?
  

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jan 92 05:56:58 GMT
From:      robo@quantum.on.ca (Rob Oakley)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: QNX / ARCNET connectivity

A Quantum Software TCP/IP product exists (on Ethernet) that
would fit your needs.

Call (613) 591-0934 for more information, or e-mail if you prefer.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jan 1992 06:26:52 GMT
From:      jchapman@polaris.cv.nrao.edu (John Chapman)
To:        comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware,comp.sys.ibm.pc.software,comp.os.msdos.misc,comp.protocol.tcp-ip
Subject:   Re: SLIP for IBM PC's?

	If you have internet access, you can get a package of packet
drivers by anonymous ftp from  sun.soe.clarkson.edu . The file is
named drivers.zip and is in  /pub/ka9q/ . The SLIP driver is named
SLIP8250. I have not tried it.
--
	-------------------------------------------------------
	| Disclaimer: Corporate Management is not responsible.|
	|     -------------------------------------------     |
	| John Chapman         jchapman@polaris.cv.nrao.edu   |
	-------------------------------------------------------

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jan 92 07:47:29 GMT
From:      robo@quantum.on.ca (Rob Oakley)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.tcp-ip.ibm-pc
Subject:   Re: QNX / ARCNET connectivity

Or voice at (613) 591-0931

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 92 12:17:18 GMT
From:      freiss@peun33.sni.de (Martin Freiss)
To:        comp.protocols.tcp-ip
Subject:   TCP connection startup - 2 questions

Hi,
some colleagues here have some interoperability trouble between different
TCP implementations. The 2 scenarios described below happen:

1. Machine A sends a SYN to machine B, and immediately starts spewing
   out data packets (ACK) without waiting for the SYN_ACK from machine B.
   Is this legal? Methinks not, as machine A at this time has no knowledge
   about the window size of machine B. Comments?

2. Machine C 'piggybacks' data on the SYN_ACK packet. Is this legal?

I think both scenarious heavily violate the "be conservative in what you
send" maxim, but I would appreciate comments from the net if these are
correct implementations.

Thanks,
Martin
--
Siemens-Nixdorf Information Systems
Martin Freiss, freiss.pad@sni-usa.com

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 92 22:34:44 GMT
From:      crum@fcom.cc.utah.edu (Gary Crum)
To:        comp.arch,comp.protocols.tcp-ip,comp.graphics
Subject:   endianness, followup to my query, with recent reference

About a week ago I posted to these groups asking for references to
in-depth articles about endianness.  Thanks to everyone who replied.

Here is an article on this topic which, along with its references list,
nicely satisfied my query by discussing recent processor architectures
and by software with respect to endianness:

James, David V., "Multiplexed Buses: The Endian Wars Continue", IEEE Micro,
June 1990, pp. 9-21.

That article mentioned Futurebus+, and a reply I received mentioned
that the upcoming February 1992 issue of IEEE Micro will contain an
article about IEEE 1596, Scalable Coherenet Interface (SCI).  Those
bus specifications explicitly address endianness issues.

I'm all for casual discussion of topics in USENET groups -- but let's not
leave out the references to nicely archived publications!

I posted the USENET query because my quick library search (using INSPEC
at Stanford) revealed only the 1981 Cohen article.  I'm happy to see
USENET come through once again, and especially happy to receive
replies from people who spend a lot of time on the topic I asked
about, e.g. those who are involved with IEEE committees.

Gary

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 92 00:59:46 GMT
From:      mike@gordian.com (Michael Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet negotiation

In article <9359@mindlink.bc.ca>, Frank@mindlink.bc.ca (Frank I. Reiter) writes:
|> I need to add some simple telnet negotiation to an application which we access
|> by telneting to a tcp/ip port.  Looking through a list of telnet option codes I
|> do not see one which puts telnet into character mode instead of line mode.
|> 
|> Is it tied to TELOPT_ECHO ?

   Sort of, line mode is really an amalgomation of a few things on both
client and server. When telnet goes into line mode it does two things
(in essense):
   1) Tells the remote telnetd to stop echoing using the ECHO negotiation
   2) Turns cooked IO mode on (or emulates it locally) on the local
      telnet and sends lines at a time.


-- 


		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Jan 92 01:19:24 GMT
From:      zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: PD user space TCP/IP

>  I am interested in a user-space PD TCP/IP implementation for 
>UNIX(Sun). I would guess that such an animal is possible over 

You can use the tunnel driver to get packets into user space and then run
some versions of ka9q for its tcp/ip support.  Sorry, I don't know where
the sources are.

-- 
Jon Zeeff (NIC handle JZ)	 zeeff@console.ais.org

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Jan 1992 06:22:35 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: PD user space TCP/IP

In article <TDFJ7K#@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
   You can use the tunnel driver to get packets into user space and
   then run some versions of ka9q for its tcp/ip support.  Sorry, I
   don't know where the sources are.

See faui43.informatik.uni-erlangen.de:portal/x25/tunnel-new.tar.Z.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 92 12:28:01 GMT
From:      aw2t+@andrew.cmu.edu (Alex R.N. Wetmore)
To:        comp.protocols.tcp-ip
Subject:   mitsubishi 386 and ibm tr

Has anyone out there had any luck getting an original IBM Token Ring
card working in a Mitsubishi 386/16?  I have 6 megs of memory, but don't
seem to have any memory conflicts with the card (I have nothing loaded
high).  When I run diagnostics I get a 166A0 error (error reading or
writing).  I have every reason to believe that the card is perfectly
fine, becuase it worked earlier in a Sperry IT (Mitsubishi 286).

The bus speed of the computer is 8 mHz, which is what the 286 was set
to.  The only difference that I can see is that the old computer had one
wait state and this computer has 0?  Could that be the source of my
problems, and will I have to buy a newer TR card to get the thing
working?

thanks,
alex wetmore (aw2t@andrew.cmu.edu)

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 15:27:42
From:      gday@cs.ubc.ca (Gordon Day)
To:        comp.protocols.tcp-ip
Subject:   FAQ? Public domain IP implementation wanted


I haven't seen a FAQ for this newsgroup yet, so here's the question.
I am interested in getting a PD IP implementation (no strings
attached) to hack up.  Does anybody know the whereabouts of such a
beastie?

Ta,

Gordon.
--
Gordon.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 15:17:31 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection startup - 2 questions

freiss@peun33.sni.de (Martin Freiss) writes:

>Hi,
>some colleagues here have some interoperability trouble between different
>TCP implementations. The 2 scenarios described below happen:
 
>1. Machine A sends a SYN to machine B, and immediately starts spewing
>   out data packets (ACK) without waiting for the SYN_ACK from machine B.
>   Is this legal? Methinks not, as machine A at this time has no knowledge
>   about the window size of machine B. Comments?
 
>2. Machine C 'piggybacks' data on the SYN_ACK packet. Is this legal?

1. This is not legal. One problem is that the sender does not have the 
correct (or any) ACK number in the segments.  Second, since establishing a TCP
connection involves a three way handshake and the sending side here is not 
doing that, it is not following the protocol. 

2. This is legal. Page 30 of RFC 793 states "Several examples of connection     initialization follow. Although these examples do not show connection 
synchronization using data-carrying segments, this is perfectly legitimate,
so long as the receiving TCP doesn't deliver the data to the user until it is
clear the data is valid ...."

Kurt Matthys
Unisys Corp.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 15:45:03 GMT
From:      rh0083b@tin.psg.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Named under SunOS 3.5

I am trying to get named running under SunOS 3.5. I created named.boot and
named.hosts files, but named won't run: it exits immediately. I guess I am
doing something wrong. Any pointers? What exactly should be in the named.
boot file?

Regards,
-Roger

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 18:10:38 GMT
From:      dxe@cassidy (Dan Ellsweig - Network Software)
To:        comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   SNA over IP - additional overhead


Greetings


I am looking for information regarding additional bandwidth requirements
when encapsulating SNA over my IP network. I am wondering if anyone out
there has any detailed information they could share with me.

Please contact me directly vi E-mail directly or by telephone




thanx




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

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 18:42:37 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection startup - 2 questions

In article <freiss.695132238@peun33> freiss@peun33.sni.de (Martin Freiss) writes:
>Hi,
>some colleagues here have some interoperability trouble between different
>TCP implementations. The 2 scenarios described below happen:
>
>1. Machine A sends a SYN to machine B, and immediately starts spewing
>   out data packets (ACK) without waiting for the SYN_ACK from machine B.
>   Is this legal? Methinks not, as machine A at this time has no knowledge
>   about the window size of machine B. Comments?

More to the point, I think, is that machine A cannot produce valid ACK
segments since it does not yet know machine B's initial sequence number.
It might be sending data segments with no ACK, but this is
definitely illegal, and implementations are required to throw them
away on receipt.  Note, though, that it is quite legal for A to send
data along with the SYN.

>
>2. Machine C 'piggybacks' data on the SYN_ACK packet. Is this legal?
>

Yes.

I wondered at one time whether TCP could be used as a reliable
transaction/RPC protocol, using the following:


Machine A				Machine B

send SYN + data + FIN

				send SYN + response + FIN +
					ACK of A's FIN

send ACK of B's FIN


It turns out to be unachievable, as well as unconventional,
mainly because there is no state corresponding to "FIN sent but SYN not
yet received" for A to enter.
There is, additionally, one other interesting snag:

A can send data to B along with the SYN, and B may accept it (i.e., may
include it in the ACK of its SYN+ACK segment), but B may not deliver the
data to its application until completion of the three-way handshake,
that is, until its own SYN has been ACKed.  This is because it is only
at that point that B can be sure that A's SYN segment was not delayed
or duplicate or otherwise invalid.  So, it is legal for B to include
data in its SYN+ACK, but it can't really be a "response" because it can't
legally depend on the data received from A.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 19:07:45 GMT
From:      mjm@sabal.cis.ufl.edu (Michael Murphy)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client


In article <1992Jan10.200808.12978@milton.u.washington.edu> erikm@hardy.u.washington.edu (Erik Madsen) writes:

   Yes, from what I recall, when I worked at Boeing, we used NCSA Telnet on
   our Macs, and it was always very fast... but the difference was, is that we
   didn't have to use the MacTCP version of NCSA.  Now I'm noticing this
   dog-slow problem, and I wonder if the different versions have something to
   do with it... or Apple's MacTCP driver might be the problem (wouldn't 
   surprise me that much, either).

Hmm... well, i've got NCSA Telnet 2.4.01-MacTCP, and MacTCP 1.1, and it
doesn't seem that slow to me.  It's not blindingly fast, but it's ok.  I only
have one A/UX machine, and i haven't tried using NCSA Telnet on it to telnet
OUT, since there's Berkeley telnet.  But telnetting or FTPing INTO the A/UX
machine (IIci, 20 Megs, by the way) from another Mac with NCSA Telnet seems
to give me the same speed as between two regular Macs, or from one regular Mac 
to the A/UX Mac, or from a Mac to our Sequent running unix, or between the
Sequent and A/UX (either direction)...

Sequent running Unix

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 19:10:06 GMT
From:      mjm@sabal.cis.ufl.edu (Michael Murphy)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client



In article <1992Jan10.200808.12978@milton.u.washington.edu> erikm@hardy.u.washington.edu (Erik Madsen) writes:

   Yes, from what I recall, when I worked at Boeing, we used NCSA Telnet on
   our Macs, and it was always very fast... but the difference was, is that we
   didn't have to use the MacTCP version of NCSA.  Now I'm noticing this
   dog-slow problem, and I wonder if the different versions have something to
   do with it... or Apple's MacTCP driver might be the problem (wouldn't 
   surprise me that much, either).

Hmm... well, i've got NCSA Telnet 2.4.01-MacTCP, and MacTCP 1.1, and it
doesn't seem that slow to me.  It's not blindingly fast, but it's ok.  I only
have one A/UX machine, and i haven't tried using NCSA Telnet on it to telnet
OUT, since there's Berkeley telnet.  But telnetting or FTPing INTO the A/UX
machine (IIci, 20 Megs, by the way) from another Mac with NCSA Telnet seems
to give me the same speed as between two regular Macs, or from one regular Mac 
to the A/UX Mac, or from a Mac to our Sequent running unix, or between the
Sequent and A/UX (either direction)...

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 20:25:10 GMT
From:      mjm@sabal.cis.ufl.edu (Michael Murphy)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client


Urgh!  Sorry for the triple post, my newsreader software was giving me a 
hard time.


-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 92 22:51:38 GMT
From:      aek@Apple.COM (Al Kossow)
To:        comp.protocols.tcp-ip
Subject:   Looking for Bridge Communications manual

I'm trying to debug a Bridge CS/100 terminal server and 3Com (the company
that bought Bridge) appears to have lost all of Bridge's documentation..

What I need is the debug UART extender, the Software Technical Reference
Manual, and the Program Interface Service diskette. The schematics for the
main board would be very helpful too, but i'm not very hopeful that anyone
still has them.

-- 

Al Kossow @ Apple Computer, Inc., Cupertino, CA
Internet: aek@apple.com
Phone: (408) 974-5136

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 01:19:00 GMT
From:      randyt@fireball.key.amdahl.com (Randy Taylor)
To:        comp.protocols.tcp-ip
Subject:   Has the OSPF protocol been implemented anywhere?


Is anyone aware of an implementation, either commercial or academic, 
of the OSPF prtocol?  I have the RFC and it is substantial.
    Randy Taylor

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jan 1992 04:17:37 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <v7rd1cg@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
|> Where you have a lot of hosts doing occasional request/response transactions
|> to a lot of different hosts, Cheriton's scheme can *save* significantly on
|> network traffic, by piggybacking the address resolution on the upper-level
|> query data.

Ah ha. Now I understand. It does seem like a good idea in theory, but
I wonder whether the savings would ever really be "significant" enough
to be worth the trouble in most environments.

Phil

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jan 1992 04:20:55 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <v74ave0@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> Would you still object if I rephrased the idea as "concatenate the ARP
|> request and the TCP SYN into a single ethernet packet, and let the
|> destination respond first with an ARP response, and second with a SYN/ACK?"

No, because this is quite different from my initial understanding of
what you were trying to describe. As long as you can guarantee that
only one host will respond to the broadcast, fine.  But as I just said
in another note, I'm not sure the savings would be worth the trouble.
And you would have to provide a similar mechanism for protocols other
than TCP.

Phil

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jan 1992 04:30:58 GMT
From:      karn@qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure SLIP Implementations?

In article <1992Jan10.181225.1450@cherokee.uswest.com>, matthews@nethawk.uswest.com (John Matthews) writes:
|> Does anyone know if there are any terminal servers or other software
|> that allow secure SLIP connections. When I say secure I mostly mean
|> can the implementation check the source address of every packet coming
|> through the serial line making sure it matches the one assigned to the user
|> that was originally authenticated? I think cisco might be able to do a little
|> bit of what I'm asking for but I don't think they can be dynamic. By that,
|> I mean that I don't think their access-lists can move from port to port as
|> is needed in dialup situations. This mechanism would SORT-OF prevent any
|> non-registered traffic from showing up on the network. I do realize the
|> usefulness of being able to setup SLIP links for connecting another network
|> versus just a host. We have needs for both.

If I understand what you are looking for (a way to disallow third
party IP packet forwarding), then I have already implemented a feature
in my KA9Q NOS code for the PC that can readily defeat it. It's
called "IP encapsulation", aka "tunneling". It allows you to
establish a router that encapsulates packets from other hosts inside
packets that appear, to the outside network, to originate from the
router itself. The sending router simply prepends another IP header
with its own address in the source field, the the destination address
of a cooperating "de-encapsulating" router somewhere else on the
Internet, and a protocol field of 94 (meaning "IP inside IP"). The
de-encapsulation router receives the datagram, removes the second
(outer) IP header, and routes the IP datagram contained inside.

I did it to allow the Internet to be used to construct "wormholes"
(virtual links) in the amateur packet radio Internet. TCP/IP activity
on amateur packet radio consists of isolated islands of activity all
over the world. Furthermore, the Class-A network address we use
(network 44) is not advertised in the core EGP tables. So being able
to use the "real" Internet to connect these islands transparently has
proven to be an extremely useful and popular feature. You can think of
it as a special form of source routing that can be used by routers.

If you implement a filter in your router that accepts traffic from
only one IP address, then all I have to do is to set up that specific
host as an encapsulating router and find a cooperative site anywhere
on the internet that is willing to de-encapsulate my outbound traffic
and inject it back into the Internet. Assuming that you filter both
ways, i.e., you'll send me traffic for only one IP address, then I
simply make the encapsulation configuration symmetric and allocate IP
addresses to my "hidden" hosts from the network where the remote
router is located. As far as the Internet is concerned, my "hidden"
hosts would appear to be on that remote network.

You could, of course, specifically block IP datagrams with protocol
94. But then I would just pick another IP protocol field that isn't
blocked, and possibly encrypt everything past the (outer) IP header to
prevent anyone from figuring out what I'm doing. (My source code is
freely available, so anyone could make this change too.)

So in other words, unless your intent is to protect against
*inadvertently* sending datagrams with the "wrong" source address,
filtering the user's traffic is likely to be ineffective.

Phil


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 04:42:08 GMT
From:      eastick@ramsey.cs.laurentian.ca (Doug Eastick)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   TCP/IP, UTP, and interference

Sometime in the next 6 months I'll be installing an etherwire to our shop
floor so our CNC office can have access to our fileserver in the office,
via NFS.  Currently, there is an unused twisted-pair phone cable (installed
2 years ago by Bell when the building was wired for IBDN). 

I read (Byte?) that it is recommended to use coax in an industrial
environment because UTP is very suseptable (sp?) to electrical
interference.  In the shop we have lathes, milling machines, and welding
equipment; the latter is approx 100 ft. away in another bay.

Anyone have any experience to share with UTP in industrial environs?
-- 
Doug Eastick -- Sudbury, Ontario

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 06:01:00 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <1992Jan14.042055.5672@qualcomm.com>, karn@qualcom.qualcomm.com (Phil Karn) writes:
> In article <v74ave0@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> |> Would you still object if I rephrased the idea as "concatenate the ARP
> |> request and the TCP SYN into a single ethernet packet, and let the
> |> destination respond first with an ARP response, and second with a SYN/ACK?"
> 
> No, because this is quite different from my initial understanding of
> what you were trying to describe. As long as you can guarantee that
>...

	Bletch! I sure do object! It's an awful mixing of unrelated layers.
TCP shouldn't presume there *is* physical addressing, let alone know about
physical broadcast addresses.
	And nothing at that layer should be dipping into what is supposed to
be opaque data and seeing if it's TCP and has the SYN bit set. [shudder]
	It's an awful idea. It sacrifices layering (and thus modularity and
portability) for very limited savings.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jan 92 14:38:01 PST
From:      dgardner@cup.portal.com (Raster Graphics Inc)
To:        comp.protocols.tcp-ip
Subject:   lpd protocol - same for all mfgrs and DECNET??

I'm trying to develop firmware for a peripheral device (printer) that
will connect directly to ethernet/tcp-ip networks. I'm rather a novice:
if I implement the lpd protocol in my peripheral as described in RFC 1179,
will my peripheral work with workstations made by popular vendors (e.g. Sun,
HP, SGI, IBM)? What about DEC - does DECNET use this lpd protocol? Hope this
doesn't sound too naive - thanks in advance for any help you can give me.
------------------------------
Deane Gardner  <dgardner@cup.portal.com>

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 08:19:38 GMT
From:      efb@slced1.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Help CSLIP Beta Sun4 (4.1.1)

Have a distrib of cslipbeta.  There is a top directory which 
contains ( Pre Sun 4 ) INSTALLATION and SunOS 4 README parts
(Down below).  In trying to resolve the inconsistencies, I would
appreciate a word from someone who remembers building this code
successfully for a Sun4.  

What is somewhat unclear to me is whether these if_{sl,slvar}.[ch]
and slcompress.[ch] go one place or two places and into which files
they should be edited ?
  /sys/conf/files (REALLY /sys/`arch-k`/conf/files, I believe) ?
  /sys/conf.common/files.cmn ?
  both ?

  Do I rightly assume I need the slattach whether I call out or in ?

  Where did you build it ?  .. I get libraries not found.

  What is the diff in the kernel if I add init to the pseudo-dev
    line ?
  
As I read thru the two sets of Info Pre-SunOS-4 and sunos4, I get
the feeling there has been some interim releases and thus the
conflicting references .. I am trying to put this now on a Sun 4/75
( when I tried it on an SLC 4/20 ) I had run away mbufs and the Sun
patch was of no help .. 

Thanks for any tips .. /Ev/

# -----------------------------------
#  Pre Sun 4 Part ( INSTALLATION )
# -----------------------------------
# if_slvar.h            INSTALLATION            Makefile        
# sl.h                  slattach.c              
# README                slcompress.c            slcompress.h
# if_sl.c               slstats.c
# 
# Installing this code in your kernel
# -----------------------------------
# 
# (1) copy if_sl.c, if_slvar.h, slcompress.[ch] from this directory to
#     /sys/net.
# 
# (2) edit /sys/conf/files and add the lines:
#       net/if_sl.c             optional sl
#       net/slcompress.c        optional sl
# 
# (4) Add a 
#       pseudo-device   slN
#     line to your kernel config file.  'N' should be the number of
#     slip lines your plan to run.  E.g., "sl2" lets you run slip on
#     two serial lines simultaneously.  For Sun OS 3, use the line:
#       pseudo-device   slN init slattach
#

# (7) Built and install slattach (it usually goes in /etc) and slstats
#     (debugging a broken kernel might be easier if it's in /etc but
		 #     it can go anywhere).
# 
# (8) Boot up the new kernel, slattach a slip line and see if it works.
# 

# ----------------------------
#  The SunOS 4 part .. 
# ----------------------------
# 
# /home/slced1/efb/OSYS/nosc/sunos4:
#       README          slip_var.h      tty_slip.c
# 
# Berkeley, CA,  Sun Dec 31 08:54:07 PST 1989
# 
# This directory contains as slip driver that seems to work
# with Sun OS 4.0 on Sun-3s and Sun-4s.  This driver consists
# of the minimal modifications we could make to the "streams"
# 
# Then follow their directions but,
# 
#  - in step 1, also add the line
#       os/slcompress.c         optional slip
#    to /sys/conf.common/files.cmn and copy ../slcompress.[ch] to /sys/os.
# 
#  - in step 5, change slip.h to slip_var.h.
# 
#  - in step 7, if you compile their sliplogin.c, you'll need to
#    change the "#include <sys/slip.h>" to <sys/slip_var.h>.

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

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 15:17:13 GMT
From:      sra@idx.com
To:        comp.protocols.tcp-ip
Subject:   Any local-use socket Numbers?

Can anyone tell me if tcp/ip has set aside any socket # for "local" objects?
I'd like to set a few up but don't want to clash..

tnx, steve

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

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jan 92 15:42:02 GMT
From:      vax_hamm@spike.psc.scarolina.edu (Kurt Hamm)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet and Tektronics Emulation

Hello,

	Anyone out there know of a package I can use with NCSA telnet for
Macintosh that will allow me to do Tektronics emulation.  I am probably not
giving enough information because I was tasked to look for this package and
I do not know much about NCSA telnet for Mac or Tektronics.  Any help or
advice would be greatly appreciated.

	Kurt R. Hamm
	Univ. of South Carolina

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 16:14:10 GMT
From:      rh0083b@tin.psg.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   KA9Q

Where can I find the sources of the latest (best?) version of KA9Q. I need
them to compare some algorithms with the sources of other telnet I have.

I prefer a mail server, but can do FTP if necessary.

aTdHvAaNnKcSe,
-Roger

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 16:33:14 GMT
From:      nc00@eurotherm.co.uk (Neil Corlett)
To:        comp.protocols.tcp-ip,comp.realtime
Subject:   TCP/IP implementation for embedded system wanted


We need to implement TCP/IP on a bespoke realtime embedded system,
Motorola 68000 series based. We are willing to buy in an implementation but
we don't know what is out there on the market. Suggestions will be
gratefully received.

Thanks,
Neil
--
ncorlett@eurotherm.co.uk
Eurotherm Limited on +44 903 268500

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 18:12:13 GMT
From:      rachelw@spider.co.uk (Rachel Willmer)
To:        comp.protocols.tcp-ip
Subject:   How to gateway between a SMTP host and a MHS server?


Posting for a friend - please reply by email. I'll summarise if
there's any interest.

This is what he's looking for:

	> What I am trying to do is to get a gateway between a single
	> MHS server) and a single SMTP host which both exist on the same
	> ethernet network.  (MHS is a PC mail router).  If someone out there
	> has such a thing at a sensible price then great.  Otherwise I have
	> most of what I need to build it myself, but what I don't have is a
	> means of establishing a TCP session from the PC to a well-known
	> socket address on the unix host.  Likewise I need to be able to
	> "receive" a session on the PC from the host.  I don't need any
	> support for internetting, since both machines are on the same
	> network.
 
	> The latest idea I had come up with was to try to obtain the
	> appropriate parts of NCSA telnet source, since that is in the public
	> domain.  I know that this can be got via anonymous ftp from
	> ftp.ncsa.uiuc.edu (141.142.20.50); a file called README.FIRST
	> explains the directory layout etc.  However I suspect that this may
	> be far too time-consuming (and expensive?) to ask you to do.  They
	> have an archive server too, but it has been down for 6 months or so!

Thanks for any pointers.
Rachel

--

Rachel Willmer                             Spider Systems 
rachelw@spider.co.uk                       Spider Park, Stanwell Street
+44 31 554 9424                            Edinburgh, Scotland

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 18:50:38 GMT
From:      louis@nrcsp1.iar.nrc.ca (Louis Bolduc)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.unix.xenix.sco
Subject:   Why can't statd talk to statd? ... anyone ??

We have three machines running SCO ODT1.1 mounting a few partitions from an
SGI Iris 4D/320. Everything is working just fine but a few months ago, the
following message started showing up on the console of one of the machines:

	clnttcp_create: RPC: Program not registered.
	statd: cannot talk to statd at fvgx320

fvgx320 is the name of the 4D/320 exporting the directories.

Just yesterday, a second machine started printing that message. (I should
mention that the message flashes every 4 or 5 seconds, so you can't consi-
der using the console to do any kind of work).

Aside from this annoyance, everything seems to be working normally.

Can anyone point me in the right direction to fix this?

                                                 Louis Bolduc
                                                 (613) 998-9780
                                                 louis@nrcsp1.iar.nrc.ca

+---- National Research Council - Conseil national de recherches Canada ------+
|   Institute for Aerospace Research - Institut de recherche aerospatiale     |
|                                                                             |
+-- Flight Recorder Playback Centre    (613) 998-3505    (613) 998-3070 ------+

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 19:06:52 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

In article <31058@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
|> 	Bletch! I sure do object! It's an awful mixing of unrelated layers.
|> TCP shouldn't presume there *is* physical addressing, let alone know about
|> physical broadcast addresses.
|> 	And nothing at that layer should be dipping into what is supposed to
|> be opaque data and seeing if it's TCP and has the SYN bit set. [shudder]
|> 	It's an awful idea. It sacrifices layering (and thus modularity and
|> portability) for very limited savings.

I don't actually dispute your conclusion, but you could probably
figure out a way to concatenate the ARP and TCP SYN packets at the MAC
layer without mixing layers too badly. Just come up with a new flavor
of ARP that allows you to append an IP datagram to an ARP request or
response.  When a router or host doesn't have the MAC address needed
to relay a datagram, instead of discarding the datagram or holding
onto it pending address resolution, it just prepends the ARP header to
the datagram and sends it as a MAC broadcast. The receiver's ARP would
then pass the incoming datagram to its routing layer IFF the target IP
address in the ARP packet is the IP address of the receiver. Otherwise
the IP datagram would be discarded. The ARP reply could also be
combined with the higher level response, but this would probably
require some timers to do it without too much layer munging. (Yes, you
would have to worry about the case of the ARP+IP packets exceeding the
MAC frame length limits, but this would seem rare enough that simply
falling back to the existing ARP method would be OK.)

I do agree that the savings would probably be minimal and not worth
the effort, especially given the severe backward compatibility
problems that would result. E.g., how would you know if the host
you're seeking supports the new flavor of ARP or not? It would be just
like the Ethernet vs 802.3 encapsulation fiasco.

If people are *really* worried about ARP broadcast overhead (which I
consider to be a non-issue, by and large), then the following steps
are, IMHO, likely to be far more effective without compromising
backward compatibility.

1. Place strict limits on the rate at which ARP requests to broken or
nonexistent hosts can be retransmitted. This is the single largest
cause of heavy broadcast loads on many large networks.

2. Increase the ARP timeout from 15 minutes to something larger.
Detecting hardware address changes is not really a problem. If you
need to replace the Ethernet board in your host, just have it
broadcast an ARP request (for anything) when it comes up. This will
update the entries that all hosts on the net had for your host.

3. "Eavesdrop" on the sender info fields in ARP requests sent to other
hosts so you'll have the info in case you need it later.

Phil

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 21:24:10 GMT
From:      eajjs@cbnewsf.cb.att.com (john.sottile)
To:        comp.protocols.tcpip,comp.protocols.ppp,biz.comp.telebit
Subject:   Re: Using NFS over dialup Lines (SLIP/PPP)

>
>We tuned NFS via the /etc/fstab options to use a retrans=300,
>rsize=4096,wsize=4096.
>

it should be timeo=

Sorry about that.

=============================
John Sottile                             "Home is where the Software Grows"
AT&T Creative Software                   #include <std/disclaimer/who-me?.h>
jjs@addams.att.com

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jan 1992 21:34:25 GMT
From:      ole@Csli.Stanford.EDU (Ole Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Call for Papers

Call for Papers: ConneXions--The Interoperability Report
--------------------------------------------------------

ConneXions--The Interoperability Report seeks technical articles
on all aspects of computer networking, interoperability and distributed
computing. Topics include, but are not limited to:

* Protocol Implementation Issues

* Network/Systems Management

* Security

* Performance

* Distributed databases

* Monitoring, analysis and simulation of networks

* Routing

* Conformance and Interoperability Testing

* Applications of computer networking: User Case studies, etc.

* Book Reviews on relevant books

* Standardization updates

* Network media issues

ConneXions is published monthly, and the lead time is usually a couple
of months. In May 1992, ConneXions will celebrate its 5th anniversary,
so a "retrospective" style article would also be appropriate. Send your
articles via e-mail to ole@csli.stanford.edu or ole@interop.com.


-- 
Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040,
Phone: (415) 962-2515  FAX: (415) 949-1779  Email: ole@csli.stanford.edu

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 22:36:52 GMT
From:      kotula@eniac.seas.upenn.edu (Greg Kotula)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for VMS

Our college, PCT&S, is developing a networking plan for our facilities 
which include a DEC VAX 6410 and an 8250, as well a a Novell LAN and an
AT&T StarGROUP LAN.  We're interested in finding out where we can locate
TCP/IP packages for the VAX systems.  I've heard a rumor that Carnegie-
Mellon has some sort of package, but I'm not sure.  If anyone knows how 
to find such software, please email me at your earliest convenience.
Thanks in advance!  :-)
>>>>>>>>>>>>>>>>>>>>>>>>>Gregory J. Kotula<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 22:42:51 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure SLIP Implementations?

In article <1992Jan14.043058.6569@qualcomm.com>, karn@qualcomm.com (Phil Karn) writes:
> 
> If I understand what you are looking for (a way to disallow third
> party IP packet forwarding), then I have already implemented a feature
> in my KA9Q NOS code for the PC that can readily defeat it....


There is some UNIX code called "gateway" floating around which seems to
do much the same thing.


Vernon Schryver,   vjs@sgi.com

Disclaimer:  I've seen neither KA9Q nor "gateway" source.  People have been
running it arround here to bypass restrictive gateways.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 92 23:16:51 GMT
From:      slf@well.sf.ca.us (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   Internet Society


I'm looking for members of the Internet Society who would be willing to talk
to me for a story I'm doing for Communications Week.  Nothing big; I'm just
trying to find out what they're doing and what users expect to get out of
membership.  Thanks!

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jan 1992 01:11:22 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.unix.xenix.sco
Subject:   Re: Why can't statd talk to statd? ... anyone ??

In article <1992Jan14.185038.25373@nrcnet0.nrc.ca>
	louis@nrcsp1.iar.nrc.ca (Louis Bolduc) writes:
>	clnttcp_create: RPC: Program not registered.
>	statd: cannot talk to statd at fvgx320

Wow -- this is slick.  I didn't know anybody has ported RPC to SCO
XENIX.  Some of us comp.unix.xenix.sco readers would like to know
where we can get a copy.  Thanks.

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

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jan 1992 05:05:46 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Combining ARP & IP in one packet (was Re: TCP/IP vs. OSI?)

In article <1992Jan14.190652.3250@qualcomm.com>, karn@qualcom.qualcomm.com (Phil Karn) writes:
> In article <31058@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
> |> 	Bletch! I sure do object! It's an awful mixing of unrelated layers.
> |> TCP shouldn't presume there *is* physical addressing, let alone know about
> |> physical broadcast addresses.
> |> 	And nothing at that layer should be dipping into what is supposed to
> |> be opaque data and seeing if it's TCP and has the SYN bit set. [shudder]
> |> 	It's an awful idea. It sacrifices layering (and thus modularity and
> |> portability) for very limited savings.
> 
> If people are *really* worried about ARP broadcast overhead (which I
> consider to be a non-issue, by and large), then the following steps
> are, IMHO, likely to be far more effective without compromising
> backward compatibility.
> 
> 1. Place strict limits on the rate at which ARP requests to broken or
> nonexistent hosts can be retransmitted. This is the single largest
> cause of heavy broadcast loads on many large networks.

ARP itself should limit the ARP requests sent for a specific host to no
more than one per second (RFC1122 Requirements for Internet Hosts),
preferrably over all connections being attempted, not 1/sec for each
connection being attempted. The exponential backoff of the most common
higher protocols (esp. TCP) should then ensure that even this rate is
not sent for long. My view (and my implementation) sends only one ARP
request for each packet that comes down from IP for an unknown address,
and only if the last one was sent more than one second ago. Some
implementations I've looked at start sending one ARP per second for up
to 30 seconds before returning with a time-out indication - very
antisocial IMHO.
> 
> 2. Increase the ARP timeout from 15 minutes to something larger.
> Detecting hardware address changes is not really a problem. If you
> need to replace the Ethernet board in your host, just have it
> broadcast an ARP request (for anything) when it comes up. This will
> update the entries that all hosts on the net had for your host.

Preferably, ARP for your own IP number on startup. This will refresh
everybody else's ARP cache if they are doing things right, and if you
get a reply you can report immediately that someone else is using the
same IP number. You should at least check that the MAC-layer address
of the sender is different from your own, to guard against MAC-layer
implementations that receive their own broadcasts, and faulty
bridges/routers that re-send packets down the same segment they arrived
from!.
> 
> 3. "Eavesdrop" on the sender info fields in ARP requests sent to other
> hosts so you'll have the info in case you need it later.

Everybody implements ARP this way - don't we :-)
> 
> Phil


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. 

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jan 1992 05:51:32 GMT
From:      merlin@sulaco.Lonestar.ORG (David Hayes)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.dcom.lan
Subject:   Re: Need Router "Shoot-Out" Results

Well, the magic of Usenet has once again come forth, supplying copious
quantities of informed responses to my mailbox. My thanks to:

Mike Moore <mmoore@hpcc34.corp.hp.com>
sob@hsdndev.harvard.edu (Scott Bradner)
"J. Scott Marcus" <smarcus@BBN.COM>
Wayne Clark <wclark@cisco.com>
emv@msen.com (Edward Vielmetti)
"Bill Donnellan @TAY" <donnellan.bill@a1_cthq3.lkgmts.tay.MTS.dec.com>

The tests are conducted by sob@hsdndev.harvard.edu (Scott Bradner), who
wrote to inform me that the results are available for anonymous FTP at
hsdndev.harvard.edu in pub/rtests/10.91. Wayne Clark also mentioned that
some results were published in the Feburary 1991 issue of Data
Communications magazine.

Remember, send in your questions to the Usenet, and then look for Ed McMahon
on TV. You can't win if you don't enter.

	David Hayes		merlin@sulaco.lonestar.org

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jan 92 06:18:55 GMT
From:      raistlin@solwarra.gbrmpa.gov.au (Wayne Amisano)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Want mailer for PC that is PC-NFS compatible


Hi,

   My organisation is interested in finding a Mail package to use on
a PC.  We have several UNIX boxes running an ethernet using ComPex 10baseT
Western Digital clone ethernet cards.  What we want primarily is to be able
to send mail to Mac users running Quickmail on an appletalk network using
Caps.

  We will probably be installing Gatormail-Q as the SMTP client to
send mail to the unix boxes, from the Macs!  We therefore need a mail
package to run on the PC's that is compatible with PC-NFS that will allow us
to send mail between the two machines.  The package should be easy to
use as we have users, that are not (and don't want to be), very computer
literate!

  Any help would be appreciated, tnx in advance!

cul 73's de Wayne!


-- 
Wayne Amisano - Programmer
Great Barrier Reef Marine Park Authority - Townsville, QLD Australia
raistlin@gbrmpa.gov.au			 -   Internet
vk4kt@vk4afs.#nq.qld.aus.oc	   	 -   Packet Radio

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 92 08:34:09 GMT
From:      yoram@FibHaifa.com (Yoram Rimoni)
To:        comp.protocols.tcp-ip
Subject:   Re: Has the OSPF protocol been implemented anywhere?


You can find OSPF software in the following public domain:

		computer: gated.cornell.edu
                file    : /pub/gated/gated-alpha.tar.Z

I hope this will help you.

---
--- Yoram Rimoni                                                      ---
--- Fibronics Ltd., Advanced Technology Center, Haifa 31905, Israel   ---
--- Phone : +972-4-313665        Fax: +972-4-550266                   ---
--- E-mail: yoram@FibHaifa.com   or  yoram@fibronics.UUCP             ---
-- 
--- Yoram Rimoni                                                      ---
--- Fibronics Ltd., Advanced Technology Center, Haifa 31905, Israel   ---
--- Phone : +972-4-313665        Fax: +972-4-550266                   ---
--- E-mail: yoram@FibHaifa.com   or  yoram@fibronics.UUCP             ---

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 92 13:13:55 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Link Provider Interface (LPI) Protocol Spec. Anyone?

In the Interactive Unix 2.2 manual page for LLC(7) they reference the
Link Provider Interface (LPI) spec.  Is this an open specification,
and, if so, how can I get a copy?  I believe this is the specification
for the interface between upper layers (e.g., IP) and the data link
layer (e.g., a driver for a network board).

Thanks.

--
Adnan Yaqub (adnan@sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860


-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 92 15:45:20 GMT
From:      NIBMSCM@NDSUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   TCP packet structure

Hmmm...  Any help you can provide would be appreciated.

Having a little trouble getting data to pass correctly from a Windows 3.0
socket based client program and a Sun server running a TLI server application.
The sockets connect OK and I even get the correct number of bytes sent and
received on both ends.  However, when I attempt to pull the data from the
packet buffer, I don't get anything.  Also have used etherfind and found that
the packet does indeed include the data I expect.

Can't seem to find a data structure defining the format of the internet
packet - want to see if the area I'm pulling data from is indeed the
correct area.  Any suggestions (a specific include filename would be great).

Thanks in advance...

 ___________
|           |   Regards,
| ND  ----> *c      Steve Malme    -->steve@fbsdata.com<--
|____________|      FBS Data Systems
Nike - "Just do it"

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jan 1992 00:31:45 GMT
From:      pae@netwise.com (Phil Earnhardt)
To:        comp.protocols.tcp-ip
Subject:   Getting out of FIN-WAIT-2

How does a TCP host get a connection out of the FIN-WAIT-2 state, assuming
that the remote endpoint has gone away?

(where "gone away" means the remote end is a DOS box that crashed and
has not been rebooted.)

Phil Earnhardt          pae@netwise.com
Netwise, Inc.           Boulder, CO  (303) 442-8280


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 92 00:48:40 GMT
From:      mike@sail.LABS.TEK.COM (Mike Witt)
To:        comp.protocols.tcp-ip
Subject:   Where to find NREN report

Could someone tell me if the report entitled: 

"Grand Challenges: High-Performance Computing and Communications"
from the Office of Science and Technology Policy

is available on line somewhere.

-mike@sail.labs.tek.com

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jan 1992 00:54:15 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.sys.amiga.misc
Subject:   TCP/IP - SLIP for AmigaOS, with handler interface

Is there a SL/IP implementation for the Amiga that uses a handler type
of interface? The last version of KA9Q for the Amiga I saw used the same
single-tasking interface as the IBM-PC version. Is there something better,
or a newer version?
-- 
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 92 01:48:49 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan16.003145.19963@netwise.com>, pae@netwise.com (Phil Earnhardt) writes:
|> How does a TCP host get a connection out of the FIN-WAIT-2 state, assuming
|> that the remote endpoint has gone away?
|> 
|> (where "gone away" means the remote end is a DOS box that crashed and
|> has not been rebooted.)

You can't -- not without risking the clearing of a connection that
appears to be dead, but is still alive because of a temporary network
outage.  FIN-WAIT-2 is just like ESTABLISHED state, except that the
connection is only half open. Both are stable states, and they should
be allowed to exist indefinitely (unless cleared by a RST from a host
that has since rebooted).

Something tells me that the "keepalive wars" are about to start again...

Phil

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 92 14:33:14 GMT
From:      lyman@anduril.network.com (John R. Lyman)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan16.014849.13737@qualcomm.com> karn@chicago.qualcomm.com writes:
>In article <1992Jan16.003145.19963@netwise.com>, pae@netwise.com (Phil Earnhardt) writes:
>|> How does a TCP host get a connection out of the FIN-WAIT-2 state, assuming
>|> that the remote endpoint has gone away?
>|> 
>|> (where "gone away" means the remote end is a DOS box that crashed and
>|> has not been rebooted.)
>
>You can't -- not without risking the clearing of a connection that
>appears to be dead, but is still alive because of a temporary network
>outage.  FIN-WAIT-2 is just like ESTABLISHED state, except that the
>connection is only half open. Both are stable states, and they should
>be allowed to exist indefinitely (unless cleared by a RST from a host
>that has since rebooted).
>
>Something tells me that the "keepalive wars" are about to start again...
>
>Phil

This is a very real problem.  There are a couple approaches that I've used
in the past.  Telnet can avoid this problem by sending the NOP command
whenever the connection has been idle in both directions for 10 minutes
(or whatever you feel is appropriate).  Unfortunatly, Telnet is only one
of many ULPs above TCP!  In practice the only other ULP that seems to
cause any problem is FTP.  I was never able to come up with a scheme
where FTP could keepalive connections to avoid the FIN-WAIT-2 problem.

This leaves us with two choices (IMHO), a straight timeout approach (which
is not allowed by the standard, but might still be used), and of course, 
the keepalive.  IMHO keepalives are great when used correctly, but lets
not start the wars (again).

The bottom line is that PC (and workstation) users turn off or reboot 
their machines without closing their connections.  This can cause host
resources to be lost, until the host is rebooted.  There needs to be
a way to timeout TCP connections, and these are the only ways I've 
been able to come up with.

------------------------------------------------------------------------
John R. Lyman III              Network System Corp.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 92 19:18:35 GMT
From:      mcb@xwin.eng.hou.compaq.com (Michael Busby)
To:        comp.protocols.tcp-ip
Subject:   Kerberized Telnet and FTP wanted

We are looking for source for Telnet and FTP that have Kerberos authentication
for version 4 in place.  This will be implemented on SunOS4.0.3 and 4.1.1.
Are there any PD versions out there or is anyone willing to share their source
with us?  I would gladly post a followup.  A post to the comp.protocols.kerberos
news group has produced no replys.  This is to be used for an internal project
using Kerberos authentication.

Your help would be appreciated.

Thanks,

Michael C. Busby - Systems Engineer
----------------------------------------------------------------------
Compaq Computer Corporation        |  Internet: mcb@compaq.com        
P.O. Box 692000 m/s 050701         |  Uunet:    uunet!cpqhou!michaelb 
Houston, Texas, USA 77269-2000     |  Phone:    713-374-5638          
----------------------------------------------------------------------
All views and opinions expressed are my own and do not represent the
views and opinions of Compaq Computer Corporation.

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jan 1992 23:40:10 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan16.143314.5610@ns.network.com> lyman@anduril.network.com (John R. Lyman) writes:
>This is a very real problem.  There are a couple approaches that I've used
>in the past.  Telnet can avoid this problem by sending the NOP command
>whenever the connection has been idle in both directions for 10 minutes...

Oops!  Can't send a NOP in FIN-WAIT-2: you've already closed the
connection for output.

Applications which don't want to waste resources for extended periods are
free to timeout an idle connection even if it's confirmed up and
functional.  Heck, an application could even abort an active connection if
it felt it had something better to do with the resources.  The treatment
of FIN-WAIT-2 connections is just a special case: even applications that
don't care how long an ESTABLISHED connection is idle may want to get
impatient with idle FIN-WAIT-2 connections and blow them away, since
there's no way to confirm from the application level whether they're still
valid.  That all seems real obvious from the application's point of view.

The real problem, of course, is that in the BSD socket interface,
FIN-WAIT-2 connections are typically not attached to the application any
longer.  Normally a socket application issues a close and forgets about
the connection and its handle.  Only later will the connection get into
FIN-WAIT-2.  In this case, an application level solution isn't possible.
Perhaps performing a special "FIN keepalive" might be a good idea.

>I was never able to come up with a scheme
>where FTP could keepalive connections to avoid the FIN-WAIT-2 problem.

Since the FTP command connection runs over TELNET, theoretically you
should be able to send the same NOP.  I don't know how many FTP client
programs would choke on it, though....
						don provan
						donp@novell.com

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 92 01:43:57 GMT
From:      zhangz@athena.ecs.csus.edu (Zhihong Zhang)
To:        comp.protocols.tcp-ip
Subject:   Internet Address

I work for a commercial organization. We are setting up an Unix network.
We have plans to connect to Internet in near future. Is there any way
we can get a Class C address without connecting to Internet? This way we
don't have to change addresses once we are on Internet.

I want to find out who to contact and how much it's going to cost us.

Thanks

Zhihong Zhang
__________________________________________________________________________
3559 Rio Rosa Way    | 916-920-5841 (H) | UUCP: ...!ucdavis!csusac!zhangz
Sacramento, CA 95834 | 916-921-6629 (W) | Internet: zhangz@athena.csus.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 1992 01:44:29 GMT
From:      benc@ipc1.exicom.oz.au (Ben Choo)
To:        comp.protocols.tcp-ip
Subject:   How to get ethernet addresses for newly made boards?


1) Does any one out there know how can I get a group of ethernet
   address for some newly developed boards?

2) Do I need to pay any fee to any organisation for implementing
   TCP/IP, UDP, BOOTP and other related protocol in a commercial product?

Any information is very much appreciated. Please email benc@ipc1.exicom.au

Thanks a lot in advance.












-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 92 02:28:04 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. OSI?

karn@qualcom.qualcomm.com (Phil Karn) writes:

> you could probably
> figure out a way to concatenate the ARP and TCP SYN packets at the MAC
> layer without mixing layers too badly.

RFC 1122 section 3.3.6 says that a host SHOULD discard any IP packet sent
to a MAC broadcast addressed but an IP unicast address.  Clearly you'd have
to violate this.  In any environment where proxy-ARPing was going on, you'd
have to be very, very careful.

Another problem is that, by RFC1122 sect 3.2.2, a host MUST NOT send an
ICMP error message as the result of a MAC layer broadcast.  (This
requirement is a very good thing.)  If the combined ARP/SYN packet is
perfectly useable and well-received, then there's no problem, but if
there's something wrong with it the receiver may be forced to silently
endure the stream of retransmissions until the sender gives up.

It might be possible to return an ARP response and throw away the TCP part,
wait for the sender TCP to retransmit (unicast) and then ICMP it.  Perhaps
the 'new ARP' response could have a flag mentioning that all non-ARP data
was discarded - that would at least speed the retransmission.  This all
sounds like a lot of code to write for very little return.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 03:44:16 GMT
From:      dennis@longs.LANCE.ColoState.Edu
To:        comp.protocols.tcp-ip
Subject:   SLIP for AT&T WIN/386

I am in the process of searching for a version of SLIP that will
run under AT&T system V, Release 3.2, with Enhanced WIN/386 TCP/IP.
I presently have this version of TCP/IP working on a network
consisting of SUNS, DOS-PC's, and 386 UNIX systems.  However, I
do have a need for serial line communications via a modem to other
tcp/ip lans.  If someone can direct me to an ftp site with the
proper source code, I would appreciate it.

Thanks again.

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

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 1992 05:42:59 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.dcom.lans.ethernet,comp.unix.aux,comp.protocols.tcp-ip
Subject:   ARP mystery

I've just been bitten hard by a somewhat unusual combination of factors 
which might be of interest to others (as will be pointed out, people in 
a similar situation might be experiencing the same problem without even 
knowing it!)

My special thanks go to William Rogers (liam@dcs.qmw.ac.uk) who, being 
several thousand miles away, managed to be persuasive enough to make me 
focus on ARP and nothing but...

Besides, I spent about 3 weeks tracking it down, so I feel like sharing 
the conclusions with someone :-)  It has to do with Token Ring/Ethernet 
bridging and the Ethernet v.2/802.3 mess; hit 'n' if this doesn't sound 
like your cup of tea. Please forgive the length of the posting. 
Followups, if any, should go to comp.dcom.lans.ethernet, I guess.

----------
OVERVIEW
The problem occurred on a relatively new network of token rings, 
Ethernets and LocalTalk; several RS/6000s, VAXes, Suns, one Hitachi (IBM 
3090 clone), Macs, PCs, some Novell servers, FastPaths, what have you. 

I chased a lot of ghosts, but in retrospect the only part of the setup 
that matters is this: I was trying to connect a new Mac IIsi - call it 
spider - running A/UX (on Ethernet, Asante card) to an RS/6000 - call it 
rs6000 - on token ring, separated by an IBM 8209 bridge.

----------
SYMPTOMS
For a while all went fine; I was fooling around with A/UX, learning 
Unix, testing outside mail etc. This, as will be clear later, made the 
whole thing behave as it should at first. But soon I saw that it is 
sometimes impossible to ping spider from the rs6000. Reliable connection 
between these machines is vital for me.

Spider had no trouble whatever reaching any host on the Internet. The 
rs6000 could contact everything else, too, except spider at times. I 
concentrated on this problem and did almost nothing else with spider. 
The obvious thing to do was to try and discover a time pattern. I set up 
a cron script on the rs6000 which was sending two ping requests to the 
spider every 10 minutes for hours on end, saving the results in a file. 
No apparent regularity. It seemed to grow worse - only one ping out of 
20 or 30 was successful.

Other nodes on my Ethernet, a Sun and an EtherRoute gateway, could be 
pinged from the rs6000 at will. But - even stranger - when I telneted to 
the spider from one of the VAXes (on a remote Ethernet via token ring), 
it almost always worked; just after that, rs6000 had no trouble pinging 
spider... for a short while at least.

I've waded through a sea of details, discovering all kinds of mess on 
our network. Most people who helpfully responded to my earlier questions 
suggested duplicate IP numbers, routing problems, etc. Some felt that 
arp is somehow at fault (and they were right, in a way), but my 
description wasn't clear enough for anyone to really pin it down.

I've since installed and learned to use Netwatch from MIT, and it 
provided the necessary clues. As always, it sounds simple after the 
fact. Here's what was happening (or at least my theory).

----------
EXPLANATION
We start from scratch. The rs6000 wants to ping spider, but finds no 
hardware address in its arp cache. It sends out an arp request, which 
gets forwarded by the 8209 to my Ethernet as a v.2 ARP packet. Spider 
catches it, replies. The rs6000 remembers its address, while the 8209 
records it as a v.2 node. Everything works.

After a few minutes (2 or 3) ping succeeds again: the rs6000 sees the 
hardware address for spider in its cache, doesn't need to arp, and sends 
an ICMP echo request directly to spider. 8209 translates the token ring 
frame into Ethernet 2, and spider replies.

Now we wait 5 minutes or so. The rs6000 still has spider in its cache, 
so it again sends the echo request without ARP. But in the meantime the 
8209's tables expired, and even though it knows that spider is on its 
other side, it translates the packet to 802.3! (this is apparently its 
default). Trouble is, the Mac doesn't know 802.3 from a hole in the 
wall! It just ignores it. Ping fails.

We wait some more - 30 minutes, shall we say? The arp cache on the 
rs6000 managed to expire, so ping is preceded by ARP which the 8209 
treats the right way, and we're back to normal: spider replies, the 8209 
again knows it should speak v.2, and all is well again.

For those 3 weeks I simply didn't give the rs6000 enough time to expire 
its arp cache: the ping attempts were 10 minutes apart. Once in a great 
while, it succeeded, because the spider has just sent (say) a mail 
message to root, and in the process queried the outside world for routes 
- and in the process the 8209 heard that spider was a v.2 node.

When I tried pinging or telneting to spider from other hosts, and it 
worked, it was because I didn't do it too often: they almost never found 
spider in their tables, and hence almost always issued an ARP query.

My EtherRoute gateway on the same Ethernet could be pinged because it's 
smart enough to understand 802.3 requests, and responds to them. The 
Sun, whether it knows 802.3 or not, never has any problem, because every 
3 minutes it broadcasts an rwho packet, so the 8209 always talks to it 
the "right" way.

----------
WORD OF CAUTION
Note that the above couldn't happen with a node which (a) understands 
802.3, or (b) is either very isolated (rs6000 arp cache would time out) 
or very active (8209's tables wouldn't). That's the reason why I suspect 
quite a few sites which use the 8209 and v.2-only devices might suffer 
from this, but only sporadically (if this happened to me once or twice a 
day, I probably wouldn't investigate it very vigorously). In particular, 
some of the reports I saw of POP clients connecting to A/UX servers and 
timing out might be accounted for by all this. I have no idea what 
algorithm other T/R-Ethernet bridges use, so I don't know if the 8209 
must be present for this to happen.

----------
ONE MORE THEORY - FREE OF CHARGE
In the very beginning, the rs6000 could find spider most of the time. 
Later, things deteriorated. I observed the same behavior on two other 
RS/6000's, both on remote Ethernets this time. How can that be? I 
suspect that the RS/6000's arp module tries to be smart: it first sets 
the timeout to a relatively low value (a few minutes). But after I 
started pinging the spider from it like crazy, it thought: "aha, in the 
last 3 hours that host was contacted almost 20 times - let's be more 
efficient and keep his arp entry for, say, 20 minutes"... I have no idea 
if that's the way it works, but it seems reasonable, no?

----------
HOW TO FIX IT ???
Plea for help: of course, the fix would be to make my A/UX Mac IIsi 
respond to 802.3 packets. Can it be done?

Failing that, one could probably set the arp timeouts on other machines 
to a low value; that is clearly an undesirable kludge, involving effort 
on the part of several sysops.

The 8209 reportedly could be made to broadcast everything in 802.3 *and* 
v.2; not elegant at all, waste of bandwidth...

Finally, if there are no other options, what is the safest and 
"cheapest" way to make a Unix host advertise its presence every 2-3 
minutes?

Needless to say, all corrections, explanations, advice etc. are 
extremely welcome!

-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 09:53:00 GMT
From:      joerg@iiasa.AT (Joerg MESSER )
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Packet drivers and PC-NFS


  Has anyone managed to get PC-NFS working with Sun's unsupported
'pktd.sys' driver?  I'm trying to get PC-NFS to use a packet driver so
that I can run a PC newsreader.  If anyone has tackled this problem
before, I would very much appreciate a hand. Thanks.


                    Joerg Messer  |
         International Institute  |
     for Applied System Analysis  |  Email: joerg@iiasa.iiasa.ac.at
                A-2361 Laxenburg  |  Phone: +43 02236 71 5210
                         Austria  |    Fax: +43 02236 71 313

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 92 12:32:21 +1300
From:      chens@stargate.elec.canterbury.ac.nz (S. Chen)
To:        comp.sys.dec,comp.sys.dec.micro,comp.binaries.ibm.pc.wanted,comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wanted: ODI drivers for the DECpc 433 Workstation.

world,

Does anybody know where I can obtain ODI (Open Data-link Interface)
drivers for the DEPCA ethernet card in the DECpc 433 Workstations?
I need the driver for Novell's LAN Workplace for DOS toolkit.

I tried the local Novell product support: they said hard luck.
I tried DEC: ODI drivers ... hmm....

Please reply via email.  Thank you.

chens@stargate.elec.canterbuty.ac.nz

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 1992 11:05:03 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: How to get ethernet addresses for newly made boards?

benc@ipc1.exicom.oz.au (Ben Choo) writes:

>1) Does any one out there know how can I get a group of ethernet
>   address for some newly developed boards?

You talk to IEEE who administer the address (number) space.
They charge something around $1K (US) which gets you a
manufacturer code (24 bits) - you assign numbers from teh
rest of the 48 bit space (ie: you get 16M numbers to assign)..

>2) Do I need to pay any fee to any organisation for implementing
>   TCP/IP, UDP, BOOTP and other related protocol in a commercial product?

No.   Or not unless you start from a non freely-available implementation,
in which case its up to you to negotiate with its owner.

kre

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 1992 11:17:45 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

karn@qualcom.qualcomm.com (Phil Karn) writes:

>Something tells me that the "keepalive wars" are about to start again...

If they do, could contributers possibly separate the issue from the
mechanism?

Debating whether the way BSD times out connections is right or not
has its uses, but isn't what is mostly at issue.

The real debate is between users of connections that can break without
the end points dying, who want connections to be able to stay alive,
pending, through potentially very long network outages, and those more
concerned with resource utilization in (usually server) hosts, who
prefer to get rid of connections that are useless as soon as possible,
and surmise that most connections with no reachable other end are
likely to never return, so want to get rid of those.

Note: it really makes no difference at all whether the implementation
of "dead connection detection" is done in the applications, or in the
kernel, or in the host administrator's fingers (typing commands to
delete processes with no other end), or anything else - if connections
that look useless for an extended period are deleted the same result
is achieved.  Its also mostly irrelevant what the definition of "useless"
is, or that is, it is unless you have decided that killing useless
connections are OK, then you need to decide which ones in particular
to go after (ftp connections not transferring data that have been idle
15 minutes might be useless to one person, while to another they're
harmless, but mailer processes that haven't received an SMTP command
for 5 minutes are a disaster).

kre

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 12:01:38 GMT
From:      bygg@sunet.se (Johnny Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

karn@chicago.qualcomm.com writes:

! You can't -- not without risking the clearing of a connection that
! appears to be dead, but is still alive because of a temporary network
! outage.  FIN-WAIT-2 is just like ESTABLISHED state, except that the
! connection is only half open. Both are stable states, and they should
! be allowed to exist indefinitely (unless cleared by a RST from a host
! that has since rebooted).
! 
! Something tells me that the "keepalive wars" are about to start again...

The correct term for it ought to be "killalive", since that is what
it does...

! Phil

--Johnny

"When in doubt -- hesitate!"

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 13:29:03 GMT
From:      arnej@lise.unit.no (Arne Henrik Juul)
To:        comp.protocols.tcp-ip
Subject:   Anybody *implement* RFC1009?


  Lately, I have been struggling with DEC (Digital Equipment
Corporation) because I want them to implement some of the features
mentioned in RFC1009, Gateway Requirements.  Specifically, the part
that says that gateways should not try to forward datagrams arriving
via local network broadcast (Section 4.6).

  So far their response has been

  a) DEC do not support RFC1009 fully in Ultrix 4.2,
  b) It's not their problem,
  c) They don't want to do anything about it.

  I have also (by testing) found that other vendors make the same
mistake in their embedded gateways; probably this wasn't there in
BSD4.X (for some X) and nobody bothered to fix it afterwards.

  Do you know if anyone (SUN, IBM, HP or anything) has actually
implemented these MUSTs of RFC1009?
  Or even better, if any of you are employed with a vendor, do you
think this could (and should) be done?
  I would welcome any input by TCP/IP experts.

  Some background
  ---------------

  At our university, we use a technique with several logical IP
networks on the same cable, using ethernet bridges and repeaters to
make the network work OK.  As departments get more computers and
hardware, they will also (in due time) buy a router.  It is then
simple to put their logical IP network(s) behind their router(s), so
things function more in a normal, routed manner.
  At the same time, more departments and laboratories buy new
computers, which is added to the main (backbone) network directly,
without having to buy new routers constantly.  At the time being,
there are 29 logical IP networks on our backbone (broadband) cable.
We would probably need >20 routers to make these completely routed,
because of geographical distance.

  Naturally, nobody supports the notion of several logical IP networks
on the same physical cable, even if this is not very difficult in
practice. (The university have used it for some years. It works.)


  The problem
  -----------

  (I hope I can make this clear; but if it's not, try reading it again
slowly - I'm not very good at explaining.)

  The problem arises primarily when hosts on the backbone network put
out a broadcast intended for their own, logical IP network.  This is
sent via ethernet broadcast, so every host and gateway on the physical
network receives it, even if they are on a different logical IP
network.  This normally causes no problem - a host in accordance to
the host requirements (rfc1122) must silently drop these datagrams.
Machines from DEC sometimes reply with ICMP packets (port
unreachable), but this is uncommon and does not cause any further
problems.
  The real problem is when such a datagram reaches something which
acts as a gateway.  This is usually a host with ipforwarding turned
on, such as any DECstation with two ethernet cards, or any SCO
machine, or a Banyan server.  The machine will try to forward the
datagram, and will send an ARP query on the same net where it was
received. Right now, any broadcast on the main net is followed by five
ARP requests, as this tcpdump shows:

 13:32:51.477 ludvig.route > 129.241.1.255.route: rip-resp 1: 129.241.3.0(1)
 13:32:51.481 arp who-has 129.241.1.255 tell pcf13.kjemi.unit.no
 13:32:51.481 arp who-has 129.241.1.255 tell tektl.turbin.sintef.no
 13:32:51.485 arp who-has 129.241.1.255 tell efix04.efi.sintef.no
 13:32:51.489 arp who-has 129.241.1.255 tell alma1.protek.unit.no
 13:32:51.512 arp who-has 129.241.1.255 tell ehitv.termo.unit.no

  Needless to say, this is not healthy for the network.


  The solution
  ------------

  There are two solutions to our problem. One is to buy enough routers
to segregate the machines on our main net logically as well as
physically. The other is to somehow shut up the machines squeaking out
ARP requests every 0.5 seconds.  And they *would* be shut up, if only
vendors would implement the gateway requirements.  But will they?

  Thanks in advance,
  Arne H. Juul, student

arnej@lise.unit.no         <-- internet mail please        -- hacker  -
Arne.Juul@unit.no          <-- X/400 mail for sadists      --   I    :-)
xx21ajuu@nobiobsys.bitnet  <-- bitnet mail if you have to. --  hope   -

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 13:58:39 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2


	To be in FIN_WAIT_2, you have to have done a close(), which for most
user interfaces means you no longer have a reference to the connection at the
application level. If with a "half close," you shouldn't be sending any more
data after sending a FIN. So you don't have any way of sending a TELNET no-op.
	I think the "problem" (quoted, because I hate keep-alives) you're
trying to solve is when an intermediate gateway goes down.

	The problem with FIN_WAIT_2 is when your side does a close(), and
gets the ACK for your FIN, but the other side crashes before closing. If you
put a timer on it, you lose, because it's perfectly legitimate for the other
side to do some arbitrary computation (and send more data, if you did a half-
close!) before doing his close.
	But if you don't put a timer and the other side crashes, you hang
(literally, in the protocol sense) forever. You have no unacked data and
no timer running to make you send anything again.

	Most user interfaces won't allow you to do anything at the application
level for this, because you don't have a writable file descriptor at that
point.
	You can fix it with "keep-alives" from within TCP, but that has the
(bogus, IMHO) side-effect of forcing idle connections to go away. If I'm not
using a connection at the time some intermediate gateway crashes, why should
I lose all my state (eg, login session), when, without keep-alives, I can resume
where I left off as long as both ends remain up and the intermediate gateway
that crashed has recovered? That's one of the great advantages of
packet-switching.
	Maybe implementations should allow system administrators to force
keep-alives on particular connections if it appears they're hung. I hate any
fixed-timer solution, myself.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 14:35:42 GMT
From:      ron@mpd.tandem.com (Ron Boerger)
To:        comp.protocols.tcp-ip
Subject:   Problems with Tandem's sendmail ?

Sorry for the possible waste of bandwidth (we got this information second
hand) but .. would the individual(s) who had problems with Tandem's
sendmail please reply to this posting or send a note to
postmaster@mpd.tandem.com with some details?  Post only; I don't normally
subscribe to this group.

Ron Boerger

NB - We heard that there was some sort of complaint posted here last week,
     but articles from then have already been expired at our site.  Thanks.


-- 
-------------------------------------------------------------------------------
|             | Unix System Administrator Apprentice | Tandem Computers, Inc. |
| Ron Boerger |   MPD MIS Operations, Austin TX USA  | ron@mpd.tandem.com     |
|             |  "Outlaw long .sigs"            ;-)  | or .. halley!ron       |

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 14:48:58 GMT
From:      ron@mpd.tandem.com (Ron Boerger)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with Tandem's sendmail ?

In my previous post, I said "post only", when of course I should have 
said, "send e-mail only"; that's what I get for posting before I have
my first (and second, and third ..) cup of coffee in the AM  ;-)

Ron
-- 
-------------------------------------------------------------------------------
|             | Unix System Administrator Apprentice | Tandem Computers, Inc. |
| Ron Boerger |   MPD MIS Operations, Austin TX USA  | ron@mpd.tandem.com     |
|             |  "Outlaw long .sigs"            ;-)  | or .. halley!ron       |

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jan 1992 15:29:43 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Packet drivers and PC-NFS

In article <1305@iiasa.UUCP> joerg@iiasa.AT (Joerg MESSER ) writes:

     Has anyone managed to get PC-NFS working with Sun's unsupported
   'pktd.sys' driver?  I'm trying to get PC-NFS to use a packet driver so
   that I can run a PC newsreader.  If anyone has tackled this problem
   before, I would very much appreciate a hand. Thanks.

Won't work.  PC-NFS is a TCP/IP suite; so is your PC newsreader
(Trumpet, I'll bet).  You can't run two of the same protocol at the
same time, not over packet drivers, nor NDIS nor ODI.

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

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 18:58:11 GMT
From:      jdt@voodoo.boeing.com (Jim Tomlinson)
To:        comp.protocols.tcp-ip
Subject:   client socket setup question (possible FAQ)


I hope this isn't a really FAQ:  I've gotten hold of some code that sets up a _client's_ socket thusly:

        sock = socket(AF_INET, SOCK_STREAM, 0);
        if(sock < 0) {
            perror("opening stream socket");
            exit(1);
        }

        saddr.sin_family = AF_INET;
        saddr.sin_addr.s_addr = INADDR_ANY;
        saddr.sin_port = htons(portnum);
        if(connect(sock, &saddr, sizeof(saddr)) < 0) {
            perror("connecting socket");
            exit(1);
        }

What I want to know is what does an s_addr field of INADDR_ANY mean
when it's used in a client application?  I know a server does it to
specify it'll accept connections on any interface; does this mean the
client will connect with a server at any IP address?  Thanks for any
info.
-- 
Jim Tomlinson                         (206)865-6578  \  "falling snow
BoGART Project                 jdt@voodoo.boeing.com  \  excellent snow"
Boeing Computer Services   ...uunet!bcstec!voodoo!jdt  \  - Anderson/Gabriel

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 20:07:32 GMT
From:      cunfer@beno.CSS.GOV (Ron Cunfer)
To:        comp.protocols.tcp-ip
Subject:   Looking for Slip/Cslip info on Ultrix 4.2

Greetings net.readers,

First, please note my email address below.  I am posting
from a coworkers system because my pnews is temporarily
inop.

I am attempting to locate slip/cslip for ultrix 4.2.
We are running DECstation 5000/120's and all must have
slip or cslip installed.  I would appreciate any information
on archive sites as well as installation experiences/night-
mares.  Please respond to my email address listed below.

Thanks in advance for any and all responses.  I will post
a summary -- or email one -- if there is any interest.

-----------------------------------------------------------
Allan V. Dianic
Ensco, Inc.  (407)254-4122
Internet: alland@osiris.css.gov

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 92 21:54:55 GMT
From:      rwed@hal.gnu.ai.mit.edu (El-surfamundo)
To:        comp.protocols.tcp-ip
Subject:   TCP acking - when exactly?

After reading the RFC about TCP (793... I believe) Im a bit hazy on
when exactly TCP is supposed to ACK data. For example, suppose I
am doing a FTP recieve of a file. The main loop of the ftp program
may look something like: 
  while the file is not completely here yet do
    read data from the socket
    write data to the disk

Presumable, there is a buffer to which data coming from the socket
is stored, until it is retreived by the read in statement 2. Is
the data acknowledged when it is placed in this buffer, or is it
acknowledged after it is read out of this buffer? Or when?
Forgive me for not knowning the OSI terms... I am currently reading
about them.  

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 92 00:05:06 GMT
From:      ivar@ppc.ubc.ca (ivar jonsson)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NCASRC TCP/IP package

From where can I get the public domain NCASRC TCP/IP package

and

The QNX-Version of uucp, qqcp, from a company called QUICS?
  

Thanks for any hints or help,

-- 

Ivar Mar Jonsson			E-mail: ivar@ppc.ubc.ca
Pulp and Paper Centre			Tel:  (604) 822-8567
University of British Columbia

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 92 01:45:24 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: client socket setup question (possible FAQ)

In article <2169@voodoo.UUCP> jdt@voodoo.boeing.com writes:
>
>
>        saddr.sin_family = AF_INET;
>        saddr.sin_addr.s_addr = INADDR_ANY;
>        saddr.sin_port = htons(portnum);
>        if(connect(sock, &saddr, sizeof(saddr)) < 0) {
>            perror("connecting socket");
>            exit(1);
>        }
>
>What I want to know is what does an s_addr field of INADDR_ANY mean
>when it's used in a client application?  I know a server does it to
>specify it'll accept connections on any interface; does this mean the
>client will connect with a server at any IP address?

It depends on the implementation.  In some, like 4.2BSD, it is an error.
In others, like 4.3, and SUN 4.1, it means "the address of the primary
interface on the local machine", which means it will only connect to
a server on the local machine.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jan 1992 18:03:30 GMT
From:      ajwright@sacam.OREN.ORNL.GOV (Albert J Wright)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Tar help needed.

I am having trouble with un-TAR-ing the files "zmodem.tar" and "xmodem.tar".   Iread the manual pages and did not learn a thing.  Could someone EMail me with   a command line to un-TAR these files.

advTHANKSance

AJW

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 92 19:34:42 GMT
From:      andyk@hoh.mbl.edu (Andy Kogelnik)
To:        comp.protocols.tcp-ip
Subject:   Need packet driver for a 3com Etherlink II (twisted pair)

Has anyone out there got a packet driver for a 3com Etherlink II TP
ethernet board for a PC?  I just need a bare bones driver to run telnet,
ftp, etc.

Thanks

Andy
andy@mbl.edu

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jan 1992 23:40:07 GMT
From:      karn@chicago.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan16.143314.5610@ns.network.com> lyman@anduril.network.com (John R. Lyman) writes:
>This leaves us with two choices (IMHO), a straight timeout approach (which
>is not allowed by the standard, but might still be used), and of course, 
>the keepalive.  IMHO keepalives are great when used correctly, but lets
>not start the wars (again).

There's a third choice: ignore the problem. Are modern timesharing
hosts so memory starved that they cannot tolerate even a few orphaned
user tasks?

I have a dialup SLIP link from my house. I frequently stay logged in
while puttering elsewhere around the house, so the link often stays up
for hours at a time (it's a local phone call). But recently I bought a
FAX machine that shares my data line, so I'm thinking about having my
home gateway dial the SLIP link on demand, much as the Telebit
Netblazer does. That would keep the line clear for faxes or other
possible uses.

But keepalives would break this scheme. Chances are they would just
keep my SLIP link dialed up unnecessarily. But if the gateway did in
fact drop the link, keepalives from hosts on the other end would
gratuitously abort my TCP connections because I don't want the
Netblazer at work to call me. I prefer to place all of the calls from
my end, so I can be assured of having control over the line. Also,
incoming data calls would confuse my FAX machine.

As long as I don't have to contend with keepalives, this scheme will
work great. I stop typing long enough from home, and the gateway drops
the line. I start typing again, and the gateway redials the line; my
own TCP is patient enough to wait for this to happen. Since the UNIX
hosts I telnet to generally don't generate traffic on their own (I
don't run biff) they'll never know the difference.

The Internet is no longer a collection of dedicated point-to-point
links. It now includes links that are established on demand, and links
that come and go for other reasons (radio users move, routers crash
and reboot, routes flap, etc). The architecture should not include
gratuitous features that prevent it from accomodating these unreliable
and/or non-traditional network paths.

>The bottom line is that PC (and workstation) users turn off or reboot 
>their machines without closing their connections.  This can cause host
>resources to be lost, until the host is rebooted.  There needs to be
>a way to timeout TCP connections, and these are the only ways I've 
>been able to come up with.

If you really *are* resource-starved on your host, then you might time
out idle users ONLY AS NEEDED to free them up for new users. But if an
occupied resource is not immediately needed for reuse, why
gratuitously free it by bumping an idle user?

Last I heard, 1-megabyte SIMMs were down to $36...

Phil


is otherwise idle, wh
 (last I heard,
memory was down to $36/megab


-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Jan 1992 02:35:27 GMT
From:      pae@netwise.com (Phil Earnhardt)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan18.234007.3085@qualcomm.com> karn@chicago.qualcomm.com (Phil Karn) writes:
>In article <1992Jan16.143314.5610@ns.network.com> lyman@anduril.network.com (John R. Lyman) writes:
>>This leaves us with two choices (IMHO), a straight timeout approach (which
>>is not allowed by the standard, but might still be used), and of course, 
>>the keepalive.  IMHO keepalives are great when used correctly, but lets
>>not start the wars (again).
>
>There's a third choice: ignore the problem. Are modern timesharing
>hosts so memory starved that they cannot tolerate even a few orphaned
>user tasks?

Maybe I should have said more at the start. The problem behind the problem...

The problem isn't FIN-WAIT-2 sockets staying around forever. The problem is
that I can't re-register my listener on the port as long as there are
connections associated with that port hanging around in the FIN-WAIT-2 state.

I'm running on a Sys V box that doesn't let me do the setsockopt() magic.

Hope I'm not going to re-open a second religious war in one week...

Phil Earnhardt		pae@netwise.com
Netwise, Inc. 		Boulder, CO  (303) 442-8280



-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 92 04:32:18 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   definition of "primary interface"?

In <1992Jan17.204524.20479@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:

>In article <2169@voodoo.UUCP> jdt@voodoo.boeing.com writes:
>>
>>What I want to know is what does an s_addr field of INADDR_ANY mean
>>when it's used in a client application?
 
>It depends on the implementation.  In some, like 4.2BSD, it is an error.
>In others, like 4.3, and SUN 4.1, it means "the address of the primary
>interface on the local machine", which means it will only connect to
>a server on the local machine.

Can anyone point me to a document which defines "primary interface"?  I 
know that in the Sun implementation, it happens to be the first interface 
for which an address was defined.  So what?  What's special about
the first defined interface?  Is it supposed to have any special
attributes?  If someone wants to talk to the local machine, why don't
they use 127.0.0.1?

Thanks.

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

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 92 18:55:57 GMT
From:      aris@tabbs.UUCP (Aris Stathakis)
To:        comp.protocols.tcp-ip
Subject:   Re: Has the OSPF protocol been implemented anywhere?

In <2982@key.COM> randyt@fireball.key.amdahl.com (Randy Taylor) writes:


>Is anyone aware of an implementation, either commercial or academic, 
>of the OSPF prtocol?  I have the RFC and it is substantial.

Proteon routers support OSPF.

Aris

-- 
Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP
-                                                                        - 
------------------------- Sex, dope, UNIX! -------------------------------

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 92 11:28:41 GMT
From:      nc00@eurotherm.co.uk (Neil Corlett)
To:        comp.protocols.tcp-ip
Subject:   summary of realtime/embedded TCP/IP implementations

A coupe of weeks ago I queried comp.protocols.tcp-ip and comp.realtime about
TCP/IP implementations suitable for our bespoke realtime system. We received
a lot of replies. I have placed a (long) summary in comp.realtime only to save
bandwidth.

Thanks for the help,
Neil
--
ncorlett@eurotherm.co.uk
Eurotherm Limited on +44 903 268500

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 92 14:42:07 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   UDP question

I have a question about UDP.  I currently have a set up of two directly
connected Sun Sparc IIs.  I am testing the performance of the TCP/IP on
them but I am having trouble with UDP.  I seem to be losing a large
majority of datagrams during my tests.  The transmitter is basically
a loop doing writes to a socket while the receiver is in a loop doing
reads.  When I set up the sockets, I us the setsockopt() call to set
SO_RCVBUF and SO_SNDBUF to 48K.  This helps a little but I still lose
datagrams.  My gut feeling is that I am overflowing some buffer on the
transmitting machine because when I add delays into the write loop,
I receive more data at the destination.  Any ideas as to what is
happening and what, if anything, can I do about it.  Thanks in advance.
Shikhar Bajaj

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jan 92 17:48:36 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <0dShyzC00io=E2r1pX@andrew.cmu.edu>, sb7c+@andrew.cmu.edu (Shikhar Bajaj) writes:
|> I have a question about UDP.  I currently have a set up of two directly
|> connected Sun Sparc IIs.  I am testing the performance of the TCP/IP on
|> them but I am having trouble with UDP.  I seem to be losing a large
|> majority of datagrams during my tests.  The transmitter is basically
|> a loop doing writes to a socket while the receiver is in a loop doing
|> reads.  When I set up the sockets, I us the setsockopt() call to set
|> SO_RCVBUF and SO_SNDBUF to 48K.  This helps a little but I still lose
|> datagrams.  My gut feeling is that I am overflowing some buffer on the
|> transmitting machine because when I add delays into the write loop,
|> I receive more data at the destination.  Any ideas as to what is
|> happening and what, if anything, can I do about it.  Thanks in advance.
|> Shikhar Bajaj

Your gut feeling is right, you are overflowing a buffer, the device transmit
buffer.  The only thing you can do you are doing, i.e. slowing down the
transmitter.  Increasing the size of endpoint buffers only helps for load peaks,
not sustained load (well that's not quite true, it will help some but not as much
as you want).

-- 
                                                                     
John A. Scott <scott@dg-rtp.dg.com> | Phone: 1-900 ASK-JOHN
Data General                        | $2 first minute,
62 TW Alexander Drive               | $3 each additional minute
Research Triangle Park, NC 27709    |
                                                       


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jan 92 19:48:44 GMT
From:      flamer@mithril.intel.com (Jim Trethewey)
To:        comp.protocols.tcp-ip
Subject:   /etc/services port id reservations

How does a person developing a server pick a good port ID?

I know that port IDs from 1 to 1023 are reserved for "standard" 
services by the NIC.  Port IDs of 1024 and higher are dynamically 
allocated when you try to bind socket #0.

So if I made a server that was not going to be added to the 
standard suite; I did not want to even tell NIC about it because 
it is so custom to my application, I might be inclined to pick 
some random number like, say, 3141 (from "pi").  But how can I 
be sure (1) that port ID won't get allocated dynamically on a 
heavily-loaded system, and (2) that port ID won't collide with 
some OTHER custom application, or ingres, or something else?
[I know if this happens I can just edit /etc/services and
everyone that calls getservbyname() will figure it out, but
this is not a nice thing to force on my poor users].

Is there a formally defined range for static and private port IDs?

Why are the port IDs 6000 - 600x reserved for X servers? Shouldn't 
they be below 1024?  That seems like a fairly universal service 
type to me.

Does there anywhere state that there is a MAXIMUM port ID?  On one
implementation of TCP/IP I know of, an attempt to bind port ID 20000
returns an error.  Is this a bug?

--Jim Trethewey, $WORK = flamer@mithril.intel.com, $HOME = flamer@alfirin
 5200 NE Elam Young Parkway HF3-73, Hillsboro OR 97124-6497 (503)696-5444

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jan 92 20:51:46 GMT
From:      rsc@merit.edu (Richard Conto)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan16.143314.5610@ns.network.com>, lyman@anduril.network.com (John R. Lyman) writes:
  |> In article <1992Jan16.014849.13737@qualcomm.com> karn@chicago.qualcomm.com writes:
  |> >In article <1992Jan16.003145.19963@netwise.com>, pae@netwise.com (Phil Earnhardt) writes:
  |> >|> How does a TCP host get a connection out of the FIN-WAIT-2 state, assuming
  |> >|> that the remote endpoint has gone away?
  |> >|> 
  |> >|> (where "gone away" means the remote end is a DOS box that crashed and
  |> >|> has not been rebooted.)
  |> >
  |> >You can't -- not without risking the clearing of a connection that
  |> >appears to be dead, but is still alive because of a temporary network
  |> >outage.  FIN-WAIT-2 is just like ESTABLISHED state, except that the
  |> >connection is only half open. Both are stable states, and they should
  |> >be allowed to exist indefinitely (unless cleared by a RST from a host
  |> >that has since rebooted).
 ...
  |> >Phil
  |> 
  |> This is a very real problem.  There are a couple approaches that I've used
  |> in the past.  Telnet can avoid this problem by sending the NOP command
  |> whenever the connection has been idle in both directions for 10 minutes
  |> (or whatever you feel is appropriate).  Unfortunatly, Telnet is only one
  |> of many ULPs above TCP!  In practice the only other ULP that seems to
  |> cause any problem is FTP.  I was never able to come up with a scheme
  |> where FTP could keepalive connections to avoid the FIN-WAIT-2 problem.

What is the real problem? What resources are being consumed by a TCP connection
being in FIN-WAIT-2? Memory? TCP port numbers? You must want to be in FIN-WAIT-2,
it doesn't happen just because a gateway or a host somewhere crashes.

  |> The bottom line is that PC (and workstation) users turn off or reboot 
  |> their machines without closing their connections.  This can cause host
  |> resources to be lost, until the host is rebooted.  There needs to be
  |> a way to timeout TCP connections, and these are the only ways I've 
  |> been able to come up with.

As others have said, the only time a TCP connection would be in FIN-WAIT-2
would be after the host had decided to tear down the connection and deallocate
reasources. Determing when to tear down the connection is not the issue here
(and should be application dependant in my opinion.)

If the "close()"-equivalent blocks until the TCP connection is torn down,
then perhaps the host application should release any other resources before
the call to "close()". After all, what would recovering from a "close()"
error entail anyway?

In short, I'm arguing that the resources consumed by a TCP connection in
FIN-WAIT-2 should be negligable. Even if a whole campus of PCs go offline 
because of a power-hit, a properly designed application shouldn't be consuming
excessive resources once it's tried to close the connections.

--- Richard Conto		Merit Computer Network
	rsc@merit.edu		MichNet Engineering and Developement

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jan 92 04:29:56 GMT
From:      djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/services port id reservations

In article <1992Jan20.194844.14741@intelhf.hf.intel.com> flamer@mithril.intel.com (Jim Trethewey) writes:
>How does a person developing a server pick a good port ID?
>
>I know that port IDs from 1 to 1023 are reserved for "standard" 
>services by the NIC.  Port IDs of 1024 and higher are dynamically 
>allocated when you try to bind socket #0.
>
>So if I made a server that was not going to be added to the 
>standard suite; I did not want to even tell NIC about it because 
>it is so custom to my application, I might be inclined to pick 
>some random number like, say, 3141 (from "pi").  But how can I 
>be sure (1) that port ID won't get allocated dynamically on a 
>heavily-loaded system, and (2) that port ID won't collide with 
>some OTHER custom application, or ingres, or something else?
>[I know if this happens I can just edit /etc/services and
>everyone that calls getservbyname() will figure it out, but
>this is not a nice thing to force on my poor users].
>
>Is there a formally defined range for static and private port IDs?
>
>Why are the port IDs 6000 - 600x reserved for X servers? Shouldn't 
>they be below 1024?  That seems like a fairly universal service 
>type to me.
>
>Does there anywhere state that there is a MAXIMUM port ID?  On one
>implementation of TCP/IP I know of, an attempt to bind port ID 20000
>returns an error.  Is this a bug?
>
>--Jim Trethewey, $WORK = flamer@mithril.intel.com, $HOME = flamer@alfirin
> 5200 NE Elam Young Parkway HF3-73, Hillsboro OR 97124-6497 (503)696-5444

I have a similar question about port assignments.  First, here is
a chart that we have derived from several sources concerning "standard"
TCP and UDP port assignment ranges, at least on UNIX.  There are, of
course, several deviations from this in practice.  The chart:

Port Range    Assigned or defacto use
------------+--------------------------------------------
     1-255  |  Internet "well known" ports
   256-511  |  Reserved
  512-1023  |  Allocated by rresvport() and others [TCP only]
 1024-5000  |  Dynamically ("automatically") assigned ports
 5001-5799  |  Available by application request
 5800-6100  |  X Windows servers
 6100-65535 |  Available by application request
---------------------------------------------------------

In snooping in various /etc/services files, I have seen various
other services "registered" with various ports.  Some are within
the Dynamic range (1024-5000), like NFSD's use of 2049.  Others
are in the upper range.

My big question is:  where, if anywhere, can I get a comprehensive
list of defacto port assignments?

Another question:  what is the real upper limit on port numbers?
I think it's supposed to be a 16 bit number, presumably unsigned,
but I know my SCO UNIX system has problems with ports bigger
than 32K or so.

Why is this important?  We've got a special situation where we're
trying to have two systems, UNIX and a proprietary one, share
an IP address and portspace.  We know we've got big troubles for
things like FTP and SMTP, with well known port numbers.  What
we want to find out is concerning the dynamic port range.  If
an application requests port 0, it expects to be given an
arbitrary port number. Can we shift that dynamic assignment
range up in the 6100+ range with some degree of safety?  In
other words, what happens if we pick ports 12000-16000 as the
dynamic range for the proprietary system?  Will we run into
lots of collisions with existing applications which use that
range?  What happens if we pick a number >32K?

(And no, I don't want to get into any discussions about why
we are trying to do such a crazy thing!)

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 05:23:59 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow

Various articles about NCSA Telnet being slow and not-slow.

Any relationship to how DEEP the screen is (i.e. how many colours)? I
always run B/W on my Portrait screen because the repaint takes too
long otherwise.

Tom Evans

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 07:39:24 GMT
From:      bj@steele.ohsu.edu (Bill Jackson)
To:        comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Capture to file with NCSA Telnet?

I am using NCSA Telnet for the Mac (MacTCP versions 2.3 and 2.4) and I have
a desperate need to be able to capture the screen output to disk. 

My users run queries on the host machines which result in long listings, and
while some of them are content to go through the hassle of selecting all the
text with the mouse and then printing it, others are asking the obvious 
question - "why can't I capture this to disk for perusal on a computer later?"

I have asked NCSA in the past and they have said (I think) that the feature may
be included in a future release.  I am still waiting . . . 

If this is not a thing that can be done with NCSA Telnet for the Mac I have
questions for this global audience as follows:

1)  is there a Mac "trick" such that I can redirect the Print output to a file?

2)  is there another public domain Mac telnet package which supports spooling
to a capture file?

3)  has anybody modified NCSA Telnet to do this?  If so please let me know if 
your mods would be available.

Glad to summarise if others are interested here.

Thanks

-- 
---
William Jackson                     Manager, Network Services, Gaines Hall #113
Oregon Health Sciences University (OHSU), 840 SW Gaines Road, Portland,OR 97201
(503) 494 4535          Internet: bj@ohsu.edu     AT&T Mail: attmail!ohsu3b2!bj

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 08:44:47 GMT
From:      rh0083b@tin.psg.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <0dShyzC00io=E2r1pX@andrew.cmu.edu> sb7c+@andrew.cmu.edu (Shikhar Bajaj) writes:
>I have a question about UDP.  I currently have a set up of two directly
>connected Sun Sparc IIs.  I am testing the performance of the TCP/IP on
>them but I am having trouble with UDP.  I seem to be losing a large
>majority of datagrams during my tests.  The transmitter is basically
>a loop doing writes to a socket while the receiver is in a loop doing
>reads.  When I set up the sockets, I us the setsockopt() call to set
>SO_RCVBUF and SO_SNDBUF to 48K.  This helps a little but I still lose
>datagrams.  My gut feeling is that I am overflowing some buffer on the
>transmitting machine because when I add delays into the write loop,
>I receive more data at the destination.  Any ideas as to what is
>happening and what, if anything, can I do about it.  Thanks in advance.
>Shikhar Bajaj

Hmm,

This is not a problem, but a feature... UDP is inherently unreliable.
If the receiving host, or the net cannot handle the packet for some
reason, it is silently discarded. That's why you receive more when you
send less (sounds like the IRS :-)).

UDP should (IMHO, I am not an IP wizard), be used for two types of
services:

1.  Information updates. Some host wants to share data with other hosts,
    but a loss of data is not critical. The same data will simply be in
    the next update.

2.  Lookup services, for which TCP is considered too expensive. When the
    information requestor times out, it can simply retry its query.

Regards,
-Roger

(no fancy signature yet, but disclaimers apply)

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 08:46:40 GMT
From:      trondk@zevs.ifi.unit.no (Trond Kandal)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client

We also have the same good experince with NCSA-telnet in our site,- it is widely used by students
and employees ...
I think it is very fast and easy to use ...

Trond Kandal.
-- 
System-administrator: Trond Kandal, Institutt for Informatikk, Universitetet i
Trondheim AVH, N-7055 DRAGVOLL, NORWAY   |   e-mail: troka@ifi.unit.no,
trondk@ifi.unit.no   |   voice: +47 7 59 17 26   |   fax: +47 7 59 17 33
"I'm the king, I can do anything..." Jim Morrison.

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 15:01:19 GMT
From:      rh0083b@tin.psg.medtronic.com (Roger Hunen)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow client

In article <1992Jan21.084640.28238@ugle.unit.no> trondk@zevs.ifi.unit.no (Trond Kandal) writes:
>We also have the same good experince with NCSA-telnet in our site,- it is widely used by students
>and employees ...
>I think it is very fast and easy to use ...

Yes, NCSA Telnet is fast and easy to use, but....

   WHEN I TRY TO DO FTP OVER A ROUTER WHICH INTERFACES MY ETHERNET TO
   A 64 KBIT/SEC LEASED LINE, NCSA TELNET MESSES UP THE LINE. IT DOES
   NOT PROCESS 'ICMP SOURCE QUENCH' MESSAGES AND THE TCP FLOW CONTROL
   IS APPARENTLY BROKEN.

I hate to say this: NCSA is fine on ethernet where a PC can hardly flood
the receiving host. But when I get a congested WAN router because the
flow control is broken, I better not run the risk that my colleagues kill
me...

Regards,
-Roger
(no fancy signature yet, usual disclaimers apply)

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 15:28:26 GMT
From:      rh0083b@tin.psg.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   UCSD archives

Is there a mail server to access the ucsd.edu archives. Please let me
know if you know (I cannot do FTP).

Thanks,
-Roger
(no fancy signature yet, usual disclaimers apply)

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jan 92 15:28:47 GMT
From:      berg@physik.tu-muenchen.de (Stephen R. van den Berg)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

>Your gut feeling is right, you are overflowing a buffer, the device transmit
>buffer.  The only thing you can do you are doing, i.e. slowing down the
>transmitter.  Increasing the size of endpoint buffers only helps for load
>peaks,
>not sustained load (well that's not quite true, it will help some but not as
>much as you want).

Does this mean that there is absolutely no way of making sure an UDP-packet
makes it to the physical network interface directly connected to the machine
(provided of course, there are no hardware failures)?

To be more specific:
Doesn't write() simply wait until a buffer gets free?  Can you make it to?
Does a select() on writeability of the UPD socket help?
-- 
Sincerely,                                berg@messua.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"My name is Psmith, the P is not pronounced."

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 15:41:12 GMT
From:      skaamjm@ucl.ac.uk (Matthew Moore)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet and Tektronics Emulation

vax_hamm@spike.psc.scarolina.edu (Kurt Hamm) writes:

>Hello,
 
>	Anyone out there know of a package I can use with NCSA telnet for
>Macintosh that will allow me to do Tektronics emulation.  I am probably not
>giving enough information because I was tasked to look for this package and
>I do not know much about NCSA telnet for Mac or Tektronics.  Any help or
>advice would be greatly appreciated.
 
>	Kurt R. Hamm
>	Univ. of South Carolina
NCSA Telnet for the Mac includes a Tektronics emulator - in the
Session pull down, click on 'Tek page'.

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jan 1992 16:59:25 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan20.205146.2596@terminator.cc.umich.edu> rsc@merit.edu (Richard Conto) writes:
> In short, I'm arguing that the resources consumed by a TCP connection in
> FIN-WAIT-2 should be negligable. Even if a whole campus of PCs go offline 
> because of a power-hit, a properly designed application shouldn't be consuming
> excessive resources once it's tried to close the connections.

Well, if a properly designed application does a chdir() to /, and closes all
other file descriptors, before closing the port so it's not holding a mounted
file system busy... yeh. It should also background itself so that it doesn't
leave you unable to get to the shell, and close stdin, stdout, and stderr so
it doesn't keep DTR up on the serial port...

In practice shutting down a running process so it doesn't cause *any* loss of
capability for the users of a system isn't quite as trivial as that.
-- 
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 18:52:38 GMT
From:      pxv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   xterm & tn3270. Question.


Hi !

I am working on tn3270 code. I came across an un-usual request, which I
am wondering, is doable or not ?

Is it possible (or feasible) to embed (in either tn3270 and/or xterm
code) a way so that when the user clicks the left mouse button at a
position on the xterm window, the cursor is moved to that position.

If I had to do it only in xterm, I guess it would be easier, but I am
not too sure about the implications when done under tn3270.

Any tips would be of great help 
thanks !
-Kamlesh

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 92 21:20:17 GMT
From:      xjeldc@luldcfs.ldc.lu.se (Jan Engvald LDC)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow

In article <2258@wcc.oz.au> tom@wcc.oz.au (Tom Evans) writes:

>Various articles about NCSA Telnet being slow and not-slow.
 
>Any relationship to how DEEP the screen is (i.e. how many colours)? I
>always run B/W on my Portrait screen because the repaint takes too
>long otherwise.

We have found that on a net with high broadcast traffic NCSA will sooner
or later slow down to a crawl. We have switched to Kermit Telnet for now
and are also installing routers instead of bridges.

_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458, Telefax: +46 46 138225, Telex: 33533 LUNIVER S
E-mails: Jan.Engvald@ldc.lu.se,  xjeldc@seldc52,  psi%2403732202020::xjeldc

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jan 1992 23:49:29 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: REALLY slow

xjeldc@luldcfs.ldc.lu.se (Jan Engvald LDC) writes:

>We have found that on a net with high broadcast traffic NCSA will sooner
>or later slow down to a crawl. We have switched to Kermit Telnet for now
>and are also installing routers instead of bridges.

Usually problems like this in PC TCP/IP implementations are due to the
chunky receive buffers.  Most commercial and freeware stacks allocate
only a few receive buffers of a static (ie. predefined) size.  MSKermit
uses a smaller total buffer area, but it carves it into exact packet sizes
in real time.  This is really important on busy networks, because most
of the broadcasts tend to be small though there tend to be a lot of them.

This becomes particularly noticable when you are sending lots of traffic,
such as FTPing files, because lost packets can kill any large window advantage
and also mess up the RTT computations.

Erick


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

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 1992 04:09:59 GMT
From:      clare@uniwa.uwa.oz.au (Clare Johnstone)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver for PC-Appleshare?

Please, Does anyone know of a Packet Driver, or other means,
by which a  PC running DOS, with an Appleshare card on Apple localtalk,
(connected to ethernet (Internet) thru a Webster Multiport Gateway), 
could use NCSA Telnet?


Clare Johnstone, University Computing Services, Tel +61 9 380-2607
clare@ucs.uwa.edu.au

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 04:30:30 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In <1992Jan20.174836.28873@dg-rtp.dg.com> scott@tdc.rtp.dg.com
(John Scott) writes:

>In article <0dShyzC00io=E2r1pX@andrew.cmu.edu>, sb7c+@andrew.cmu.edu
>(Shikhar Bajaj) writes:
>
>|> I have a question about UDP.  I currently have a set up of two directly
>|> connected Sun Sparc IIs.  I am testing the performance of the TCP/IP on
>|> them but I am having trouble with UDP.  I seem to be losing a large
>|> majority of datagrams during my tests.
>
>Your gut feeling is right, you are overflowing a buffer, the device transmit
>buffer.  The only thing you can do you are doing, i.e. slowing down the
>transmitter.  Increasing the size of endpoint buffers only helps for load peaks,
>not sustained load (well that's not quite true, it will help some but not as much
>as you want).

I believe the Sun le (AMD LANCE) ethernet driver is wrong to discard
packets when the transmit buffers are being overrun.  If, instead of
discarding the packets, the driver just left them on its queue, rest of
the operating system will very nicely apply back pressure to the
applications that are generating large amounts of traffic.

The Sun ie (Intel 82586) driver does leave the packets in the queue in
this situation, and does not discard them.  This seems much more
civilized, not to mention the inconsistancy of different behavior
depending on the specific ethernet chip being used.

Yes, it's legit for the driver to drop packets when it's short of
resources, and the upper level protocols should recover.  But the
recovery is inefficient, and decent performance depends on not loosing
packets very often.  As long as there's a simple way to avoid dropping
packets that doesn't strain other resources in the system, why dump them?

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

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 1992 06:27:01 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <1992Jan22.043030.768@ultra.com> shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
>I believe the Sun le (AMD LANCE) ethernet driver is wrong to discard
>packets when the transmit buffers are being overrun.  If, instead of
>discarding the packets, the driver just left them on its queue, rest of
>the operating system will very nicely apply back pressure to the
>applications that are generating large amounts of traffic.

Before we go too far on this tack: every time i've seen UDP packets
dropped in a rapid-fire UDP test, it's been because the *receiver*
couldn't keep up with arriving packets and ran out of buffer space,
not because of any overrun in the transmitting node.  I don't know
anything about Suns, so can someone confirm that the likely problem
here is on the transmit side rather than the receive side?

						don provan
						donp@novell.com

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 21:11:35 -800
From:      Ed.Wilts@BCsystems.Gov.BC.CA (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Introductory online documentation

X-Date: 22 Jan 92 21:10:58 -800
X-Organization: BC Systems Corporation
Lines: 17

I'm looking for some introductory documentation to pass on to our users on
TCP/IP - in particular, MultiNet.

This would be a <5 page blurb that we can keep online as a starting point - not
meant to replace TGV's documentation at all, but something that answers some
basic questions:
	- what is TCP/IP and why do I want it?
	- what kind of tools/utilities are available (eg, FTP, Telnet, etc)
	- what is the Internet and what's out there for me?

Has anybody written anything like this, or do I have to do it myself?

Thanks in advance,

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

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 1992 08:21:35 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <1992Jan22.043030.768@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> 
> I believe the Sun le (AMD LANCE) ethernet driver is wrong to discard
> packets when the transmit buffers are being overrun.  If, instead of
> discarding the packets, the driver just left them on its queue, rest of
> the operating system will very nicely apply back pressure to the
> applications that are generating large amounts of traffic.
> 
> The Sun ie (Intel 82586) driver does leave the packets in the queue in
> this situation, and does not discard them.  This seems much more
> civilized, not to mention the inconsistancy of different behavior
> depending on the specific ethernet chip being used.
> 
> Yes, it's legit for the driver to drop packets when it's short of
> resources, and the upper level protocols should recover.  But the
> recovery is inefficient, and decent performance depends on not loosing
> packets very often.  As long as there's a simple way to avoid dropping
> packets that doesn't strain other resources in the system, why dump them?


Doesn't the "back pressure" consist of an ENOBUFS return from the if_
driver output hook and from there back to the application thru the write()
or send() system call?  At least in 4.*BSD style systems?

How should an UDP application deal with the pressure indicated by ENOBUFS?
A naive sleep(1) as in TTCP?  By ignoring the problem?

What's the difference between dropping the packet because it won't fit on
the LANCE queue and dropping it because IF_QFULL() says to?

The driver queue must be finite as well as the LANCE ring, or you'll
deadlock on mbuf's or kernel dynamic memory, or at least give innocent
processes ENOBUFS.  The queue length of 50 in the 4.3BSD is right between
the obvious choices of LANCE write-ring sizes of 32 and 64.

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

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?


Vernon Schryver,   vjs@sgi.com


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 14:27:52 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <1992Jan22.062701.15188@novell.com>, donp@novell.com (don provan) writes:
|> In article <1992Jan22.043030.768@ultra.com> shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
|> >I believe the Sun le (AMD LANCE) ethernet driver is wrong to discard
|> >packets when the transmit buffers are being overrun.  If, instead of
|> >discarding the packets, the driver just left them on its queue, rest of
|> >the operating system will very nicely apply back pressure to the
|> >applications that are generating large amounts of traffic.
|> 
|> Before we go too far on this tack: every time i've seen UDP packets
|> dropped in a rapid-fire UDP test, it's been because the *receiver*
|> couldn't keep up with arriving packets and ran out of buffer space,
|> not because of any overrun in the transmitting node.  I don't know
|> anything about Suns, so can someone confirm that the likely problem
|> here is on the transmit side rather than the receive side?

I get a little suspicious when the transmitter reports speeds greater than
wire speed. (Ever try "ttcp -t -u host" on a Sparc?)  The packets have to 
go somewhere.  Dropping packets seems the only sane thing to do since flowcontrol
can not be effectively passed through a multiplexor.  

I'm done on this subject.  If you want the last word, take it.

|> 
|> 						don provan
|> 						donp@novell.com


-- 
                                                                     
John A. Scott <scott@dg-rtp.dg.com> | Phone: 1-900 ASK-JOHN
Data General                        | $2 first minute,
62 TW Alexander Drive               | $3 each additional minute
Research Triangle Park, NC 27709    |
                                                       

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 14:52:31 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   Re: xterm & tn3270. Question.

In article <1992Jan21.185238.17579@njitgw.njit.edu> pxv0618@hertz.njit.edu (Paranjothi Varadarajan) writes:

   Is it possible (or feasible) to embed (in either tn3270 and/or xterm
   code) a way so that when the user clicks the left mouse button at a
   position on the xterm window, the cursor is moved to that position.

If you have XView, you can use my xvttool/xtntool package 
	(via ftp) => titan.rice.edu/sun-source/vttool.shar.? 
and jmg@dxcoms.cern.ch's 3270 emulator, you can do that, but the code
currently binds that action to Control-LeftMouse.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 17:26:26 GMT
From:      nagel@ucsu.Colorado.EDU (Kurt Nagel)
To:        comp.protocols.tcp-ip
Subject:   Network simulation tool needed


Hello,

	I am looking for a tool to simulate wide area network characteristics
on a local area network.  Specifically, I would like to be able to introduce
a known delay to simulate differing lengths of network.  Ideally the tool
should also allow variable error rates, block duplication, corruption, etc.

	The appropriate tool would probably be code for a gateway or repeater
that would intercept incoming packets and retransmit them according to test
criterion.  

	Anyone involved in network testing or evaluation could greatly benefit
from such a tool and it strikes me that there must be something like that out
there.

	Ideally, the tool would NOT require hardware purchase. I.E. software.
The tool should run on a Sun sparc station, an IBM PC or a Decstation or
other hardware that can be used as a gateway.  I am interested in hearing all
options, ideas you may have.

Thank you in advance,

Kurt Nagel
nagel@fido.colorado.edu

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 17:43:35 GMT
From:      subbu@hpindda.cup.hp.com (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP acking - when exactly?


>After reading the RFC about TCP (793... I believe) Im a bit hazy on
>when exactly TCP is supposed to ACK data. For example, suppose I
>am doing a FTP recieve of a file. The main loop of the ftp program
>may look something like: 
>  while the file is not completely here yet do
>    read data from the socket
>    write data to the disk
>
>Presumable, there is a buffer to which data coming from the socket
>is stored, until it is retreived by the read in statement 2. Is
>the data acknowledged when it is placed in this buffer, or is it
>acknowledged after it is read out of this buffer? Or when?

You are right in presuming that there is a buffer in which incoming data
is stored. The ACK delivered by TCP only says that TCP has received the 
data and has taken the reponsibility to pass it on to the uiser. It does not
mention whether the user program has consumed the data or not.

The window size, sent along with the ACK, in some sense conveys whether the
user has consumed the data. TCP operates on a sliding window principle. The
sending TCP does not send data unless a window is advertised by the receiving
TCP. And the received advertizes the window on the basis of availability
of space in the (socket) buffer.

Most TCP impementations defer sending the ACK until a few more data packets
are received (The Host Recquirements document says that a TCP implelentation
should not defer ACK for more than one outstanding data packet) or until
a timer pops, which ever happens earlier (since TCP ACKs are cumulative,
it is advantageous to ACK  multiple data packets).

>Forgive me for not knowning the OSI terms... I am currently reading
>about them.  

-Subbu

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 92 18:59:00 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron 602-885-7700x.2546)
To:        comp.protocols.tcp-ip
Subject:   Needed inetd that restricts connections based on net/host address


	A while back someone mentioned that there is available for
	anonymous ftp out there an Inetd which allows restriction
	of incoming connections based on originating host network
	and/or host address.  (Much like HP-UX has, or TGV MultiNet
	for VMS has).

	Where can I get such a copy for Ultrix or BSD? 

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
FUN is never having to say you're SUSHI!!

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 1992 21:17:24 GMT
From:      karches@utdallas.edu (Tom Karches)
To:        comp.protocols.tcp-ip.ibm,comp.protocols.tcp-ip
Subject:   Need to network LaserMaster printer on PC with Unix


I need to configure a LaserMaster laser printer as a network printer
in a network with SparcStations and PC's. The LaserMaster printer
requires a controller card in the PC and is addressed as LPT1 under
DOS.

Is there software that will allow the LaserMaster to be available on 
the network as a network printer that can be accessed through normal
Unix network print commands (lpr)? I realize that the PC with the
LaserMaster controller would also need an Ethernet card.

Please e-mail responses; I don't regularly read this group.

Regards,
Tom Karches
Integral Systems
karches@utdallas.edu
-- 
-------------------------------------------------------------------------------
Tom Karches          |"If rap music had been around when I was a kid,
karches@utdallas.edu | I would have become a musician instead of a politician."
---------------------'----------------------------------- Richard Nixon

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jan 1992 22:08:31 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   Re: Network simulation tool needed

In article <1992Jan22.172626.15021@ucsu.Colorado.EDU>, nagel@ucsu.Colorado.EDU (Kurt Nagel) writes:
>
>Hello,
>
>	I am looking for a tool to simulate wide area network characteristics
>on a local area network.  Specifically, I would like to be able to introduce
>a known delay to simulate differing lengths of network.  Ideally the tool
>should also allow variable error rates, block duplication, corruption, etc.
>
> [criteria deleted]
>
I just read about a piece of software called NEST (Network Simulation
and Prototyping Testbed).  It is described as a Unix-based public-domain
simulator, from Columbia University in New York.  I don't know if it will
do the type of simulation you desire, nor do I know how to get this
software.  You might try checking Columbia's ftp archives.  Or maybe 
someone else knows more about NEST?!!!

-Robin
***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu


-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jan 1992 03:43:47 GMT
From:      russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u)
To:        comp.protocols.tcp-ip
Subject:   PCroute v2.2 and WD8003 woes

We are trying to set up a PC with pcroute 2.2 with one slip port
and one ethernet port. We are using a WD8003 ethernet card.

If we use the packet driver everything works fine but if we try and
use the native WD8003 driver we never get anything out on the ethernet
at all. Even using the supplied wd03slip.exe.

Does anybody have any ideas about what is going on here?

Thanks, Russell
-- 
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@aukuni.ac.nz>

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 04:55:18 GMT
From:      wjq@uts.amdahl.com (Bill Quigley)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan18.234007.3085@qualcomm.com> karn@chicago.qualcomm.com (Phil Karn) writes:
 >In article <1992Jan16.143314.5610@ns.network.com> lyman@anduril.network.com (John R. Lyman) writes:
 >>The bottom line is that PC (and workstation) users turn off or reboot 
 >>their machines without closing their connections.  This can cause host
 >>resources to be lost, until the host is rebooted.  There needs to be
 >>a way to timeout TCP connections, and these are the only ways I've 
 >>been able to come up with.
 >
 >If you really *are* resource-starved on your host, then you might time
 >out idle users ONLY AS NEEDED to free them up for new users. But if an
 >occupied resource is not immediately needed for reuse, why
 >gratuitously free it by bumping an idle user?
 >
 >Last I heard, 1-megabyte SIMMs were down to $36...
 >
 >Phil

I'm confused.  I thought that, from the FIN-WAIT-2 state, it was
impossible to get back to ESTABLISHED.  So a timer started in
FIN-WAIT-2 can only drop a connection that couldn't communicate
anyway, right?  It sounds like Phil is talking about timing out
established connections, while I think the original problem is timing
out connections in fin-wait-2 that never receive a fin.

What are keepalives, and how do they work, anyway?

-- 
Flower Cake - Trends in food come and go, but
the popularity of cookies never wanes - easy to make, easy to eat.
Bill Quigley
Amdahl - UTS Communications Product Support
wjq@charon.amdahl.com

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 06:17:00 GMT
From:      wjq@uts.amdahl.com (Bill Quigley)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/services port id reservations

In article <1992Jan20.194844.14741@intelhf.hf.intel.com> flamer@mithril.intel.com (Jim Trethewey) writes:
 >Is there a formally defined range for static and private port IDs?

Ports between 1024 and 5000 are supposedly reserved for servers.  I
don't know whether most implementations actually avoid giving one of
these ports when port==0.

In practice, you can take a port just below 1024 that is not already
used, and you can be pretty well assured that you won't collide with
anything.  You have to be root to bind to these ports, though.

 >Does there anywhere state that there is a MAXIMUM port ID?  On one
 >implementation of TCP/IP I know of, an attempt to bind port ID 20000
 >returns an error.  Is this a bug?

Yes.  The tcp specification states that port number is to occupy 16
bits, unsigned.  This gives a range of 0..65535.  You should be able
to bind to any port in this range.

 >--Jim Trethewey, $WORK = flamer@mithril.intel.com, $HOME = flamer@alfirin


-- 
Flower Cake - Trends in food come and go, but
the popularity of cookies never wanes - easy to make, easy to eat.
Bill Quigley
Amdahl - UTS Communications Product Support
wjq@charon.amdahl.com

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 15:21:52 PST
From:      steven@pita.seas.ucla.edu (steven stovall)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SNMP for the IBM Bridge Program


I need an SNMP agent that can somehow coexist with the IBM Bridge Program
running on a PS/2. If anyone has such a thing, or ideas on how to acquire
or hack such a thing (or even on what such a thing should look like :-),
please drop me a line.

thanks. 
______________________________________________________________________________

steven stovall
steven@pita.cns.ucla.edu
(213) 825 7405

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 10:20:23 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In <1992Jan22.062701.15188@novell.com> donp@novell.com (don provan) writes:

>Before we go too far on this tack: every time i've seen UDP packets
>dropped in a rapid-fire UDP test, it's been because the *receiver*
>couldn't keep up with arriving packets and ran out of buffer space,
>not because of any overrun in the transmitting node.  I don't know
>anything about Suns, so can someone confirm that the likely problem
>here is on the transmit side rather than the receive side?

From the comments at the beginning of the Sun lestart() routine:

> * Note:  Out of tmds's causes outgoing packets
> * to be discarded rather than requeued

Sun's own iestart() routine does just the opposite:

> * Start or restart output to wire.  If there are sufficient
> * resources available add a new frame to the transmit queue.
> * Otherwise, wait until later.

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

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 16:11:14 GMT
From:      rcronh@wsannw01.win.tue.nl (Ron Helwig)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.sys.sun.misc
Subject:   connecting a QMS printer to a SUN-pcnfs network


Is there a (possibly cheap) way to connect QMS PS8xx PostScript 
laserprinters directly to a pc-nfs ethernet?

The picture shows what I'm looking for:


                  -------------
  thin wire       |           |        serial 
-----------+------+ black box +---------------------PS8xx
  ethernet |      |           |        connection
           |      -------------
           |
           +--PC 
           |
           +--SUN 
           |


I`m not looking for a solution in which the printer is connected
directly to a SUN or a PC, but for some `black box' that 
hooks the printer up to the network in a way that comunication
from the printer to a SUN is possible (e.g. paper out).

A terminal server could do the job, but the problem at our
site is that the printers (some 17) are distributed over 
an entire building.

Thanks in advance for any hints and ideas,

	Ron
-- 
e-mail: rcronh@win.tue.nl               | Ron Helwig
phone:  +31 (0)40 472724                | Eindhoven University  of Technology
fax:    +31 (0)40 436685                | P.O. Box 513, 5600 MB Eindhoven, NL

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 18:44:18 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In <g3u089g@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Doesn't the "back pressure" consist of an ENOBUFS return from the if_
>driver output hook and from there back to the application thru the write()
>or send() system call?  At least in 4.*BSD style systems?

No.  From the send(2) man page on Sun:

     If no buffer space is available at the socket  to  hold  the
     message  to  be  transmitted,  then  send() normally blocks,
     unless the socket has been placed in non-blocking I/O  mode.
     The  select(2) call may be used to determine when it is pos-
     sible to send more data.

The IRIX 3.3 send(2) man page says exactly the same thing.

However, it looks like I may have misspoke when I said that a Sun with
an ie driver correctly throttles the application.  I just ran a quick test
on one of our Sun's with an ie interface, and it claims to be sending
6 MB/sec out the ethernet.  Clearly, someone is dumping bits somwhere
(or maybe if I let it run for a few minutes, it will swell up and
explode :-) ).

This doesn't change my main point: there's no reason for any layer in
the protocol stack to dump packets if it doesn't have to.

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

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 19:22:30 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In <1992Jan22.142752.21305@dg-rtp.dg.com> scott@tdc.rtp.dg.com (John Scott) writes:

>I get a little suspicious when the transmitter reports speeds greater than
>wire speed. (Ever try "ttcp -t -u host" on a Sparc?)  The packets have to 
>go somewhere.  Dropping packets seems the only sane thing to do sinceflowcontrol
>can not be effectively passed through a multiplexor.  
 
>I'm done on this subject.  If you want the last word, take it.

I'l try one more time.

Just because flow control isn't available in some circumstances, that's
no excuse to not use it when it is available.  No layer of the protocol
stack should discard data if there's an available queue to put it on.

I consider the lack of flow control in the larger internet world to be a
deficiency.  Let's try to figure out ways to fix that, rather than
continuously design more elaborate recovery techniques to deal with it.

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

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 92 20:31:33 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <1992Jan23.184418.6521@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> In <g3u089g@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >Doesn't the "back pressure" consist of an ENOBUFS return from the if_
> >driver output hook and from there back to the application thru the write()
> >or send() system call?  At least in 4.*BSD style systems?
> 
> No.  From the send(2) man page on Sun:
> 
>      If no buffer space is available at the socket  to  hold  the
>      message  to  be  transmitted,  then  send() normally blocks,
>      unless the socket has been placed in non-blocking I/O  mode.
>      The  select(2) call may be used to determine when it is pos-
>      sible to send more data.
> 
> The IRIX 3.3 send(2) man page says exactly the same thing.

Since I'm aquainted with both IRIX man pages and source, I can confirm that
this is true, not just for IRIX 3.3, but also IRIX X.* for X in [1,5].  It
is also irrelevant.

Yes, if your socket buffer is full, your process will block.  Please read
the friendly code and explain how to fill a SOCK_DGRAM socket buffer.  The
bits fall out the bottom as fast as your user process puts them in.


> However, it looks like I may have misspoke when I said that a Sun with
> an ie driver correctly throttles the application.  I just ran a quick test
> on one of our Sun's with an ie interface, and it claims to be sending
> 6 MB/sec out the ethernet.  Clearly, someone is dumping bits somwhere
> (or maybe if I let it run for a few minutes, it will swell up and
> explode :-) ).
> 
> This doesn't change my main point: there's no reason for any layer in
> the protocol stack to dump packets if it doesn't have to.


Read the code and explain how to do otherwise in a socket based system.
The *_output() function is given a struct mbuf*, a struct ifnet*, and a
struct sockaddr*.  It has no way to block, wake up, slow down, speed up or
even know about any user processes.

After thinking of what might be changed to implement a different policy,
consider what would also have to be done in the cases when no user process
is involved, as when an IP packet is being forwarded from one interface to
another.


From private correspondence, it seems that some STREAMS implementations use
the same strategy of discarding on overflow, while some new STREAMS
implementations can slow down the user process.

That after 10 years few people know of this policy in the 4.*BSD code and
no one has made a valid complaint (ttcp and spray cannot support valid
complaints) proves that the additional, heavy weight (IMO) mechanism to
implement other policies would be wrong.


Vernon Schryver,   vjs@sgi.com

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jan 1992 21:54:48 GMT
From:      mcmahon@tgv.com (John 'Fast-Eddie' McMahon)
To:        comp.protocols.tcp-ip
Subject:   How does one join the Canadian Internet



I am giving a "What is the Internet" style talk at a Canadian DECUS Symposium
in a few weeks.  While a lot of the material I am going to present is common to
the US segment of the Internet, I have little idea how one goes about joining
the Internet in Canada.  Any suggestions ?  A FTP site with documentation would
be ideal.

Thanks,
John 'Fast-Eddie' McMahon    :    MCMAHON@TGV.COM    : TTTTTTTTTTTTTTTTTTTTTTTT
TGV, Incorporated            :                       :    T   GGGGGGG  V     V
603 Mission Street           : HAVK (abha) Gur bayl  :    T  G          V   V
Santa Cruz, California 95060 : bcrengvat flfgrz gb   :    T  G    GGGG   V V
408-427-4366 or 800-TGV-3440 : or qrfgeblrq ol znvy  :    T   GGGGGGG     V


-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 92 00:08:30 GMT
From:      gre253@mis.csiro.au (Steven Green)
To:        comp.sys.ibm.pc.misc,comp.protocols.tcp-ip
Subject:   How do I connect a thin-net loop to a thick-net backbone ?

We have a thin-net ( coaxial cable ) ethernet consisting mainly of PC's running
TCP/IP software.

I would like to connect this to a thick-net backbone.

What do I need to do this. 

A transciever ?

or a bridge ???

HELP...

Steve Green


-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 01:12:04 GMT
From:      russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u)
To:        comp.protocols.tcp-ip
Subject:   Re: PCroute v2.2 and WD8003 woes

russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:

>We are trying to set up a PC with pcroute 2.2 with one slip port
>and one ethernet port. We are using a WD8003 ethernet card.
 
>If we use the packet driver everything works fine but if we try and
>use the native WD8003 driver we never get anything out on the ethernet
>at all. Even using the supplied wd03slip.exe.


Here's what we have concluded. (I got one other response saying that
they had experienced the same problem.)

Work around for the pcroute 2.2 wd 8003e problem.

Pcroute 2.2 implements new features in the WDE driver code - these
may work for the wd8013 card (we have not tried this) but they fail
completely for the wd8003e.

I have sidestepped this problem by replacing the wd8003.asm and
wd8003.inc in pcroute 2.2 with their 2.1 versions and changed the
wd8003e line in declare.inc to match. (the 2.2 version has different
parameters)

I then assembled, linked and ran wd8003e-slip version of pcroute without
further problems.

Nevil Brownlee
-- 
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@aukuni.ac.nz>

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 01:52:22 GMT
From:      aw2t+@andrew.cmu.edu (Alex R.N. Wetmore)
To:        comp.protocols.tcp-ip
Subject:   telnet protocol

Are there any good texts on the telnet protocol?  I would like to know
what to send out and what to expect to recieve if I were to write my own
telnet server (ie, how to get terminal type, how to turn off local echo,
etc).  If I am heading in the wrong direction can you straighten me out?

thanks,
alex

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 02:00:56 GMT
From:      Roger Watt <rwwatt@watserv1.uwaterloo.ca>
To:        comp.protocols.tcp-ip
Subject:   Re: How does one join the Canadian Internet

>I am giving a "What is the Internet" style talk at a Canadian DECUS Symposium
>in a few weeks.  While a lot of the material I am going to present is common to
>the US segment of the Internet, I have little idea how one goes about joining
>the Internet in Canada.  Any suggestions ?  A FTP site with documentation would
>be ideal.
 
One joins the provincial TCP/IP network administration's association
in one's province. Each provincial network is linked by the CA*net 
Canadian backbone.            
 
Each of these provincial associations provides "getting registered"
services to its new members.

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 04:16:34 GMT
From:      parghi@cs.uiuc.edu (Amit Parghi)
To:        comp.protocols.tcp-ip
Subject:   Re: How does one join the Canadian Internet

Roger Watt <rwwatt@watserv1.uwaterloo.ca> writes:
>One joins the provincial TCP/IP network administration's association
>in one's province. Each provincial network is linked by the CA*net 
>Canadian backbone.            
> 
>Each of these provincial associations provides "getting registered"
>services to its new members.

The above information, while correct, is less than helpful.  Attached
is a list of the provincial IP networks and appropriate contact persons
(known to be accurate as of late last October).

    Amit


    Regional           Contact             E-Mail                    Phone #

ONet  (Ontario)     Andy Bjerring      bjerring@uwovax.uwo.ca      519 661-2151
BCnet (BC)          Mike Patterson     Mike_Patterson@mtsg.ubc.ca  604 822-3932
ARnet (Alberta)     Walter Neilson     neilson@TITAN.arc.ab.ca     403 450-5188
SASK#net (Sask.)    Dean C. Jones      jonesdc@admin.usask.ca      306 966-4860
MBnet (Manitoba)    Gerry Miller       miller@ccm.UManitoba.ca     204 474-8230
RISQ (Quebec)       Bernard Turcotte   turcotte@crim.ca            514 340-5700
AccessNB (NB)       David MacNeil      DGM@unb.ca                  506 453-4573
NSTN (Nova Scotia)  Michael Martineau  martinea@hawk.nstn.ns.ca    902 468-NSTN
NLnet (Nfld&Lab)    Wilf Bussey        wilf@kean.ucs.mun.ca        709 737-8329
PEINet (PEI)        Jim Hancock        hancock@upei.ca             902 566-0450


-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 04:51:06 GMT
From:      hal@actrix.gen.nz (Hal King)
To:        comp.dcom.lans,comp.protocols.ibm,comp.protocols.tcp-ip,comp.sys.hp
Subject:   Ethernet: HP3000/947 to IBM4381 and MicroVAX. Help requested.

We are currently planning to replace our networked HP3000/70 computer
systems with the HP3000/9x7 (XL) range.

The existing system comprises one model 70 in each of three cities
and a single model 52 (Used for software development). The cities are
a minimum of 600Km apart. Networking is performed via NZ over an X.25
backbone on leased lines.

In addition one of the existing model 70s communicates with a MicroVAX
and an IBM4381 (VSE under VM) via a switched RJE link. The MicroVAX is
running packaged software which we are unable to change, and which has 
been tailor made to run RJE. The IBM already has RSCS and VTAM 
software, and is equipped with a 4Mbits/sec token ring. We are willing
to convert the IBM to use different communications software/techniques
and are prepared to make the RJE link a direct IBM to MicroVAX
connection if necessary.

We are replacing the central model 70 with a model 947 on an Ethernet
backbone. Inter HP communications will be replaced by Ethernet 
bridges/routers with NS over TCP/IP and ARPA software. The configuration
of the machine means that there will be no spare slots for a PS1 card
to continue with the RJE links.

Does anyone have any experience with similiar conversions, or with
bridging Ethernet to IBM4381s and/or MicroVAX RJE?

While we would be especially interested in hearing about any packaged
solutions, we are not adverse to doing a little programming ourselves.

Any help provided will be most gratefully received.

--

Hal King       hal@actrix.gen.nz



-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 05:45:28 GMT
From:      mckay@ka.reg.uci.edu (Kyle J. McKay)
To:        comp.protocols.tcp-ip
Subject:   HELP - How do I force the PUSH flag to be set

I have some custom applications that are communicating with each other
using TCP/IP on a Sun unix workstation running SunOS 4.1.1.  The
applications seem to work fine without paying any attention to the PUSH
flag, but I'm concerned that I can't figure out how to set it for two
reasons:

        1) I was under the impression that the TCP/IP implementation was
allowed to buffer up data for a little while before either sending it or
delivering it to the receiver (on the other end) unless it sees a PUSH
in which case it has to deliver it right away.  I need this application
to communicate at maximum possible speed.
        2) Even if the unix-to-unix TCP isn't a problem, the other end
may not be unix but some other implementation of TCP that supports the
PUSH flag (I have an MS-DOS version that supports setting the PUSH flag)
and if I don't have access to it from the unix side I can't help but
expect problems down the road.

Does anyone out there know how a unix application causes this flag to be
set?  Or is it always set for you whenever you send data on a TCP
connection?  I'm using the SunOS implementation of berkeley sockets.

Any help would be appreciated.  Please email as I don't read this group
as often as I'd like.

Thanks,

Kyle McKay
mckay@ka.reg.uci.edu  (preferred)
kmckay@uci.edu        (less preferred)
kmckay@uci.bitnet     (if nothing else works)

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 06:41:58 GMT
From:      ralph@swmerc.rain.com (Ralph Merwin)
To:        comp.protocols.tcp-ip
Subject:   Re: PCroute v2.2 and WD8003 woes

In article <1992Jan24.011204.6179@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes:
>
>Work around for the pcroute 2.2 wd 8003e problem.
>
>Pcroute 2.2 implements new features in the WDE driver code - these
>may work for the wd8013 card (we have not tried this) but they fail
>completely for the wd8003e.
>
>I have sidestepped this problem by replacing the wd8003.asm and
>wd8003.inc in pcroute 2.2 with their 2.1 versions and changed the
>wd8003e line in declare.inc to match. (the 2.2 version has different
>parameters)
>
>I then assembled, linked and ran wd8003e-slip version of pcroute without
>further problems.

Well, there are at least two sites here in RAINet using the newest version
of PCRoute, with one wd8003e ethernet port and either 2 or 4 slip ports.
Works just fine.  Are you sure that you have the latest version?  Are you
sure that you are using the correct WDE_DECLARE entry (the order in the
default declare.inc file may have changed, but the parameters haven't). I
made NO changes to my declare.inc file, which leads me to think that you
must either be using an old version or you are using the wrong WDE_DECLARE
for your board (or I must have *really* missed something :-) ).

I've included part of Vance's announcement below.

Ralph

========================= PCRoute 2.22 ==============================

Version 2.22 of PCroute is available via anonymous FTP from accuvax.nwu.edu
(129.105.49.1) in pub/pcroute.   This version simply fixes one or two
bugs present in 2.21.   Note that if you use PCroute with packet drivers 
GET THIS NEW VERSION.  The old version has a VERY serious bug in which 
some memory gets overwritten with packet contents.  It can have very 
unpredictable results.   

-- 
-------------------------------------------------------------------------
Ralph Merwin             ralph@swmerc.rain.com             (503) 642-0256

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 07:36:50 GMT
From:      Dale_Semchishen@mindlink.bc.ca (Dale Semchishen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In order for you to ensure that a UDP-packet safely arrives at
its destination, write a layer of software on top of UDP that
provides a connection oriented protocol (Virtual Circuit).

This is what TCP already does for you, if possible use this instead.
--
Dale Semchishen              | Internet: Dale_Semchishen@mindlink.bc.ca
Personal Designs Inc.        | tel: (604) 590-0056
                             | Vancouver, BC, Canada

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 08:34:58 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <e7a702Kz58SJ00@amdahl.uts.amdahl.com> wjq@uts.amdahl.com (Bill Quigley) writes:
   I'm confused.  I thought that, from the FIN-WAIT-2 state, it was
   impossible to get back to ESTABLISHED.  So a timer started in
   FIN-WAIT-2 can only drop a connection that couldn't communicate
   anyway, right?  It sounds like Phil is talking about timing out
   established connections, while I think the original problem is timing
   out connections in fin-wait-2 that never receive a fin.

   What are keepalives, and how do they work, anyway?

The basic idea behind keepalives is to send a message with a sequenece
number equal to SND.UNA-1 to force the remote peer to reply.  You do
this if there has been no activity on a connection for awhile.  If,
after a time no reply is received you drop the connection.
--
Adnan Yaqub (adnan@sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 10:28:36 GMT
From:      koerber@ap542.uucp (Mathias Koerber)
To:        comp.protocols.tcp-ip
Subject:   ping with Record Route Option ?

Is there a program, which does basically a ping, but with the
IP-Options Record Route and/or timestamp set?

aTdHvAaNnKcSe
----
Mathias Koerber   | Tel: +49/89/636-45685   | koerber%ap542@ztivax.siemens.com
SNI AP 114        | Fax: +49/89/636-45860   | koerber@ap542.uucp
MchP/LZ Rm:L1562  |  4: C=DE/A=DBP/P=SNI    | koerber.muc@sni.de
Carl-Wery-Str. 22 |X.0: O=SIEMENS NIXDORF/OU1=MUENCHEN/OU2=P4/OU3=D5/OU4=AP11
D-8000 Muenchen 83|  0: S=KOERBER/G=MATHIAS
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht was Leiden schafft *

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 14:06:50 GMT
From:      trondk@ifi.unit.no
To:        comp.protocols.tcp-ip
Subject:   Documentation, POP-2 and POP-3

Is there anybody out there that can help to get documentation for
POP-2 and POP-3.

I interested in the programming interface for these protocols.

I`m using PC-NFS from SUN as netsoftware.

If you have something of interest,- please send a note to me by e-mail.

Thank you very much!.

Trond Kandal
Institutt for Informatikk
Universitetet i Trondheim, AVH
7055 Dragvoll
NORWAY

e-mail:	trondk@ifi.unit.no
			troka@ifi.unit.no
			trondk.kandal@ifi.unit.no
			Trond.Kandal@ifi.unit.no 

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 14:18:52 GMT
From:      gah@trc.mew.mei.co.jp (Gary A. Hildebrand)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Problem with ARP, Sun, FDDI, Ethernet

Felow netters,

I have recently encountered a serious problem involving ARP packets.  The
network involved is relatively simple:

+-------------+    +------------------+                +-----------------+
|             |--->|                  |   (Ethernet)   |                 |
| Sun FDDI/DX |    | AT&T Multibridge |================| UNIX EWS & PC's |
|   {DAS}     |<---|     {DAS}        |                |     & Mac's     |
+-------------+    +------------------+                +-----------------+
          ^ |        ^ | (FDDI dual ring)
          | v        | v
        +-------------------+
        |                   |
        |  AMD Fastcard 2   |
        | FDDI Concentrator |
        |      {DAS}        |
        +-------------------+
                ^ |
                | v       
       +---------------------+
       |                     |
       | Network Peripherals |
       |     NP-EISA/STP     |
       |        {SAS}        |
       +---------------------+

The problem is talking to the Sun on the FDDI dual ring, a 4/330 running
SunOS 4.1.1 w/JLE, which has a Sun FDDI/DX interface installed.

It seems that if a system *either* on the FDDI ring itself or on the
bridged Ethernet attempts to use ARP to query the Sun's hardware address,
the Sun (according to etherfind running on the Sun) will see the ARP
request, generate a legitimate ARP reply, and the other system will fail to
register the information.  It is not entirely clear whether the failure is
due to the ARP reply packet getting lost or containing invalid information
(the only two possibilities I can think of for failure).  However it is
highly unlikely that the packet is getting lost, since this has been tried
from as close as the PC which has the Network Peripherals NP-EISA/STP board
installed, which is attached via the AMD FDDI Concentrator directly to the
FDDI ring without any form of bridging.  FDDI monitoring software on the
AMD FDDI Concentrator shows the ARP requests being transmitted (since they
are always broadcast), but cannot detect ARP replies.

As for invalid information, etherfind shows expected data in both the ARP
request and reply packets.  The "Ethernet type" is 0x0806 (ARP), the ARP
hardware type is 0x0001 (for 10MB Ethernet), the ARP protocol type is
0x0800 (IP), the hardware address length is 6 bytes, the protocol address
length is 4 bytes, the ARP control field is either 0x0001 for request or
0x0002 for reply, and encapsulated source/destination hardware/protocol
addresses appear in the right order.  There seem to be data bytes beyond
the destination protocol address, what these are I have no idea since the
content is not consistent and I don't know where the checksum is in the
etherfind output.  The length of all ARP frames has been 60 bytes.

The obvious downside of this problem is little or no TCP/IP
communications with the Sun!!!  Curiously, if the Sun is allowed to
initiate the ARP dialog (by Telnetting out from the Sun, for instance), the
Sun will successfully receive the ARP reply, the ARP caches of both
machines will be populated, and the session will be successful.  For this
reason, UNIX-UNIX sessions with the Sun have not been a problem, since lots
of two-way activity is usually going on.  However, PC- and Macintosh-based
TCP/IP implementations have not been so amiable.  When first brought up,
these systems have a clean ARP cache (if any) and are generally not spoken
to initially by the Sun since they are mostly running client-based
stuff.  Examples:

  1.  The PC which has the Network Peripherals NP-EISA/STP installed has a
      copy of NCSA Telnet 2.3b14 running on it.  After running TELBIN,
      the only way to telnet to the Sun is to have the Sun send something
      to the PC, say a ping.  Then TELBIN will record the ARP information and
      telnetting is fine until TELBIN's ARP cache times out.  But this
      machine is directly on FDDI!

  2.  The same exact scenario as (1) exists from other PC's on the Ethernet
      which is bridged, running either the same version of TELBIN or the
      2.2 version.

  3.  PC's on the bridged Ethernet running Ungermann-Bass Net/One TCP/IP
      Telnet software cannot connect to the Sun, and cannot be made to
      using the method of (1) because this software is neither a server nor
      responds to pings. 

  4.  Mac's running NCSA Telnet 2.3.x over the bridged Ethernet cannot
      telnet to the Sun, and cannot be made to using the method of (1) for
      unknown reasons.

If anyone can provide help on this matter, please do so via e-mail.  If
there is enough of a response to this, I will post a summary.

/ Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
/  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
/   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
/    Tokyo 108, JAPAN                Tel:      03-3452-4941            \

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 14:46:13 GMT
From:      sat@tridom.uucp (Stephen Thomas)
To:        comp.protocols.tcp-ip
Subject:   Public Domain Integrated IS-IS?

Anyone know of any public domain (via ftp) implementations of IS-IS or
integrated IS-IS?

Thanks,

Stephen Thomas (sat@eng.tridom.com)
AT&T Tridom

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 15:25:52 GMT
From:      bell@inxs.NoSubdomain.NoDomain (david bell)
To:        comp.protocols.tcp-ip
Subject:   Mailing List

Sorry to post this, rather than mail to control, but I have tried without success
to get my name removed from the mailing list for this group.

Could someone in authority out there please cancel my subscription,

thank you in advance,

David Bell


-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 16:20:00 GMT
From:      misc@falcon.cs.uofs.edu
To:        comp.protocols.tcp-ip
Subject:   Ada Implementation?


A colleague of mine recently told me that he thought he saw reference to an Ada implementation 
of TCP/IP that was available via FTP somewhere on the net.  Any truth to this?  If so, where 
can it be found?  

Rich___

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 16:24:58 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   UDP Question answered

It seems that my innoculous little posting has started a discussion which has
since evolved into something much deeper. I am by no means an expert on
the Internet protocols so I probably won't be able to contribute much to it.
In case anyone is still interested, I have found that I am dropping my
packets at the receiver.  Using recommendations from various replies,
I have learned that my sender is transmitting the information just fine
but that I am overflowing the receive buffer on the destination side.  Thanks
for all the responses people have sent me and posted on the net.

Shikhar

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 16:55:05 GMT
From:      Roger Watt <rwwatt@watserv1.uwaterloo.ca>
To:        comp.protocols.tcp-ip
Subject:   Re: How does one join the Canadian Internet

>from parghi@cs.uiuc.edu (Amit Parghi) :
>>from Roger Watt <rwwatt@watserv1.uwaterloo.ca>:
>The above information, while correct, is less than helpful. Attached
>is a list of the provincial IP networks and appropriate contact persons
>(known to be accurate as of late last October).
>    Regional           Contact             E-Mail                    Phone #
>ONet  (Ontario)     Andy Bjerring      bjerring@uwovax.uwo.ca      519 661-2151
 
The "contact" info you list is actually the individuals who chair the
executive committees of the various provincial administrations, and 
probably they are NOT the individuals who handle the day-to-day details of
new-member queries and applications. In the case of ONet, the information
above is out of date now; the new chair is John Drake, drake@mcmaster.ca,
and I don't have phone info handy. The day-to-day contact re new-member
stuff is Herb Kugel, herb@ugw.utcs.utoronto.ca (again, I don't know
phone). Sorry, but I don't have comparable info for the other nine
administrations. The entity that operates CA*net will definitely
have current "exec" and maybe also "new-member query" info,
but I don't have a pointer (the national body deals directly with
the provincial bodies, not with the members of the provincial bodies).
If this is still "less than helpful", my apologies.          

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 17:52:47 GMT
From:      bpalmer@bbn.com (Brian Palmer)
To:        comp.protocols.tcp-ip
Subject:   Packet driver for SONIC

Are there PD packet drivers for the National SONIC ethernet chip?

Has anyone ever used this chip?  Any comments?

Thanks,
Brian

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 17:54:15 GMT
From:      saloffre@jeeves.waterloo.edu ()
To:        comp.protocols.tcp-ip
Subject:   Re: How does one join the Canadian Internet


Or better yet, dont waste your money or time on Onet (Ontario Net), just
join uunet canada. For further info ftp to uunet.ca for more info.
Prices are cheaper, and 'no usage restrictions'.

JUST SAY NO TO ONET


-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 18:55:12 GMT
From:      Richard.E.Brown@dartmouth.edu (Richard E. Brown)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: "ping" for AppleTalk?

Philip Machanick (philip@concave.cs.wits.ac.za) writes:

> Is there any (preferably) public domain software to check how
> good a connection to a specific machine is? (Like "ping" on
> TCP/IP networks.)).

Dartmouth College has developed MacPing (tm), a Macintosh application
which sends AppleTalk Echo packets to all the devices on a particular
AppleTalk network.  You can choose the zone and network to test: 
MacPing will use NBP to discover all the devices in that network, and
then will test them.

MacPing differs from other network testing programs in that it tests
all the devices of a network in parallel.  (The display is a series of
horizontal traces, one trace per device. Lost packets show up as black
marks on a dotted line.) This display format allows you to compare the
performance of different devices on the same wire to determine the
cause of the problem.

MacPing is available now, and retails for $69.00; an unlimited-copy
site license is available for $149.00.  For more information, contact:

Rich Brown                    E-Mail: richard.e.brown@dartmouth.edu
Manager of Special Projects   AppleLink address:  A0183
Dartmouth College             Telephone: 603/646-3648
Kiewit Computer Center        Fax: 603/646-2810
Hanover, NH 03755 USA          

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 19:15:29 GMT
From:      gallo@zeno.fit.edu (Michael A. Gallo)
To:        comp.protocols.tcp-ip
Subject:   Public Domain TCP-IP

Question:

Is there a public domain package available for PCs that will provide 
TCP/IP capabaility?  Essentially I will need the TCP/IP drivers and a
Telnet application.  Please respond via email.  (The PCs are 386 IBM
compatibles.)

Mike Gallo
Florida Institute of Technology
Melbourne, FL 32901
407/768-8000 x7551
gallo@zeno.fit.edu

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 22:00:00 GMT
From:      gumley@ltp2.gsfc.nasa.gov (Liam E. Gumley)
To:        comp.protocols.tcp-ip
Subject:   SLIP/CSLIP for MSDOS PC information needed

G'day folks.

Can anybody tell me where to find a SLIP and/or CSLIP package for a
MSDOS PC that works with a *modem* (9600 bps V.42bis) over normal phone lines?

Any and all information/tips/hints are very welcome.

Cheers,
Liam.

--
Liam E. Gumley                        | Phone    : (301) 982-3700
MODIS Science Data Support Team       | Fax      : (301) 982-3749
Research and Data Systems Corporation | Internet : gumley@ltp.gsfc.nasa.gov
Greenbelt MD 20707, USA               | 

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jan 1992 23:23:32 GMT
From:      jonc@uhunix.uhcc.Hawaii.Edu (Jon Ciliberto)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: "ping" for AppleTalk?

Newsgroups: comp.protocols.appletalk
Subject: How to create multiple new users
Summary: 
Expires: 
References:
Sender: Jon Ciliberto 
Followup-To: 
Distribution: 
Organization: University of Hawaii
Keywords: 

Is there a way to create new appleshare Users from a list of names (i.e., I 
have a list of some 450 people, and i need to make each a new User; is there a 
way to avoid manually entering all of them?)

thanks for any info.

jon ciliberto

jonc@uhunic.uhcc.hawaii.edu

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 92 23:58:37 GMT
From:      jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp & DOS 5.0 high not work

>In article <davidi.4@deakin.OZ.AU?> davidi@deakin.OZ.AU (David Ivens    ) writes:
>I tried DOS 5.0 and dos=high in config.sys but it hung just after the bootp
>file was downloaded and with the drive a: light on.

If your ethernet interface is memory mapped then "dos=high" can cause
DOS to load into the memory of the ethernet card.  OK, until you send
or receive your first packet and overwrite part of DOS!

Use the exclude option on the emm statement to tell DOS not to use
the memory occupied by the ethernet board.  I think this is why many of
the vendors default to using programmed IO even though it is slower than
memory mapped.  There is less potential for a conflict so less problem
reports from the field.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jan 92 00:25:30 GMT
From:      trier@odin.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp & DOS 5.0 high not work

In article <52678@olivea.atc.olivetti.com> jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) writes:
>If your ethernet interface is memory mapped then "dos=high" can cause
>DOS to load into the memory of the ethernet card.

This is incorrect.  The part of MS-DOS that causes problems is the emm386
driver, which is often used with "dos=umb" or "dos=high,umb".  I know
of no Ethernet cards that will conflict with the "dos=high" command,
which uses only memory in the 1024K-1088K range.

The solution, as you said, is to include the "x=" exclude option on the
emm386 load line in config.sys.  This option should exclude the area of
memory used by your network card.

Symptoms of the problem frequently include a network failure on cold boots
or hardware resets, but proper functioning after a Ctrl-Alt-Delete.

-- 
Stephen Trier
CWRU IRIS/INS
trier@ins.cwru.edu

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jan 1992 00:45:07 GMT
From:      mikec@calvin.tcs.com (Mike Curry)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

I've been following this thread since its inception, and I'm wondering whether
anyone out there has written (or knows of) a diagnostic tool that can allow 
one to determine, for a given machine architecture, just how fast one can
pump datagrams at the socket before beginning to lose.

I expect I could probably write such a tool myself, but I am already swamped
under the code I *must* write, so adding more code that I *could* write 
seems unwise if it's already available.

So, how about it? Has someone already invented this wheel?

mikec@calvin.tcs.com
Michael A Curry
Teknekron Communications Systems, Inc.
2121 Allston Way, Berkeley CA 94704 USA 

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jan 1992 02:51:57 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet driver for SONIC

In article <68455@bbn.BBN.COM> bpalmer@bbn.com (Brian Palmer) writes:

   Are there PD packet drivers for the National SONIC ethernet chip?

Well, strictly speaking, one develops a packet driver for a specific
board, not a chip.  Perhaps National has a demonstration board?

   Has anyone ever used this chip?  Any comments?

I don't know of any manufacturers using it in a general-purpose
Ethernet board.  Perhaps it's being used in embedded Ethernet systems?

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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jan 1992 03:01:40 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ping with Record Route Option ?

In article <1992Jan24.102836.18414@ap542.uucp>, koerber@ap542.uucp (Mathias Koerber) writes:
> Is there a program, which does basically a ping, but with the
> IP-Options Record Route and/or timestamp set?


There was something called "pong" which used loose source routing.

4.3BSD-reno (I think) ping includes -R which does record route.
Years older source from BRL.MIL does it as well.


Vernon Schryver,   vjs@sgi.com


-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 92 03:15:59 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

In article <1992Jan25.004507.15917@tcsi.com>, mikec@calvin.tcs.com (Mike Curry) writes:
> I've been following this thread since its inception, and I'm wondering whether
> anyone out there has written (or knows of) a diagnostic tool that can allow 
> one to determine, for a given machine architecture, just how fast one can
> pump datagrams at the socket before beginning to lose.
> 
> I expect I could probably write such a tool myself, but I am already swamped
> under the code I *must* write, so adding more code that I *could* write 
> seems unwise if it's already available.
> 
> So, how about it? Has someone already invented this wheel?


I'd start with ttcp.c, and hack its ENOBUFS error handler.  Instead of
delaying a fixed amount, vary the delay until you don't quite suffer the
error.  This is kind of hard to do because the feedback loop is so slow.
By the time you've handled the ENOBUFS and delayed, you have no idea of the
state of the queues.


What machine cannot transmit as fast as it can generate packets when not
medium limited?  I hesitate to imagine a system which that has an
independent DMA system which moves data more slowly than the CPU can copy,
checksum, and header-ize it.


Vernon Schryver,   vjs@sgi.com

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 92 07:57:43 GMT
From:      shih@madrone.eecs.ucdavis.edu (Alan S. Shih)
To:        comp.protocols.tcp-ip
Subject:   Help: SLIP and FAS doesn't like each other?


Help Netlanders:

	I have installed FAS driver on my SVR4.386. However, when I
	ran slattach it reply "I_LINK /dev/slip". It was working fine
	when I use the old asy. driver.  Does anyone know what 
	happend and give my some suggestion?

	Thanks in advance!


-- 
|   ALAN SHIH  
|   UC.Davis EE dept
|   "When I realize my life is full of sh*t, it was good;
|      because I can start cleaning it UP."

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 92 09:39:52 GMT
From:      duplain@rtf.bt.co.uk (Andy Duplain)
To:        comp.protocols.tcp-ip
Subject:   SunOS broadcast address


	This question has probably been asked too many times already...
	
	We  have  recently been allocated an offical block of IP addresses,
	and  during  the  reconfiguration  of our Sequent and Sun systems a
	query  arose  over  broadcast  addresses.  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++"
	
				....
				
	++ (footnote)
	"Unfortunately, an early release of TCP/IP code that accompanied
	Berkeley UNIX incorrectly used all zeroes for broadcast, and even
	though the Berkeley code has been repaired, the mistake still
	survives in some commercal systems derived from that code."
	
	Are Sun still making the mistake described by Comer ?
	
	What should the broadcast address be - should I force it to
	xxx.xxx.255.255 ?
						    
	
	Thanks in advance.
	

================================================================================
Andy Duplain, BT Customer Systems, Brighton, UK.            duplain@rtf.bt.co.uk
#define	DISCLAIMER      My views and opinions are my own, and not my company's
================================================================================
	

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jan 1992 11:16:01 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:

>In <1992Jan22.142752.21305@dg-rtp.dg.com> scott@tdc.rtp.dg.com (John Scott) writes:
>Just because flow control isn't available in some circumstances, that's
>no excuse to not use it when it is available.  No layer of the protocol
>stack should discard data if there's an available queue to put it on.

The latter as a generalisation is simple rubbish - the former sentence
should be qualified by something referring to the desireablity of
reliable delivery.

If I have an application that's chosen to send bulk data at high speed
using UDP, then I can guarantee that I don't want my process slowed down
because some layer in the kernel is trying to be helpful, and avoid
discarding my packets - I'd much prefer that it simply discarded them.
If I'm generating data that fast, and sending via udp, then its very
likely that the timeliness of the data is much more important than that
every packet arrives correctly at the destination.

If I cared about reliability, I'd have either layering a protocol over UDP,
in which case I wouldn't be sending huge quantities before expecting some
kind of ack,,and I'd be expecting packets to be discarded occasionally,
or I wouldn't be using UDP at all, but TCP, which will do the hard work
for me.

kre

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 92 13:39:48 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Two simple programming questions

I am familiar with C programming under Unix, but new to network programming.  I
hope someone can answer two simple questions for me:

1) Can a process interact with a socket using read() and write() rather than
send() and recv()?  If so, are there any disadvantages to doing so?

2) Can a program which has it's stdin and stdout attached to a socket (such as
a process started by inetd for example) determine that stdin and stdin ARE in
fact attached to a socket and then determine the IP address of the other end?

Thankyou in advance for any assistance.

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

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 92 22:33:30 GMT
From:      rwed@hal.gnu.ai.mit.edu (El-surfamundo)
To:        comp.protocols.tcp-ip
Subject:   TCP probes

Hello!

  My implementation of TCP/IP is coming along nicely...

  I seem to recall talk of "TCP probes"... I gathered they were a means to
  "ping" as it were a remote TCP. I suspected it was some kind of empty
  composed from a normal TCP packet skeleton... empty of data.. that
  elicited a response. Is this correct? I cannot think of what kind of
  packet this would be. Is it an out of sequence ACK? And does this
  have to do with socket keep-alives?

-Rob


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 92 09:05:02 GMT
From:      tetsuji@rai.juice.or.jp (Tetsuji Rai)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   TCP/IP version of Esix R3.2 ?

I'm running Esix SysV R3.2, but trying to install the distribution package
of X11R5, X386 server fails in the function 'listen'.

   I was told TCP/IP functions on Esix R3.2 are incompatible with those
with others(for which X11R5 is programmed).   Are there any significant
differences ?   My TCP/IP network version number is 1.12.   Which is
the current (or the most popular) version ?   I must buy manuals for it.

   Thank you in advance.
-- 
RRR              Tetsuji Rai    tetsuji@rai.juice.or.jp -- private site
R  R   aaa   i    5-12-21, Toyotamakita, Nerimaku, Tokyo 176, Japan
RRR   a  a   i   voice: +81-3-3557-3936   fax: +81-3-3993-0323
R  R  aaaaa  i   "Never do today what you can put off until tomorrow :-)"

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 92 13:44:08 GMT
From:      dhuber@autelca.ascom.ch (Daniel Huber)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   MacTCP (?) routing problem? (long)

Hi there,

I have a little (in fact, it it grows. at least for me) problem with
MacTCP, Mac Router, GatorBox, TCP/Connect....

Sorry, the description of this problem is not that detailed as it
should be.... Just consider me as a novice in MacTCP...

Out net looks this way (simplified):

				case1	mac1
				|	|
 --------+-------+-------+-------+----NET1
			|			|
 Router1			gator1
			|			|
		---+----+--------NET2		|
	           |			--------+--+-----NET3
		   mac2				   |
						   mac3

NET1:		Ethernet, TCP/IP (136.232.0.0, subnet mask
		255.255.0.0), EtherTalk Phase 2 (net=1,
		zone=EtherTalk_Phase2)
NET2:		AppleTalk (net=4000, zone=LT_Solsport))
NET3:		AppleTalk (net=2000, zone=LT_Neubau))
Router1:	Apple MacIntosh with Apple Router software, MacTCP not
		installed. Acts also as a Mac Server. Ethernet and
		AppleTalk interface.
gator1:		GatorBox with GatorShare and GatorPrint. TCP/IP
		routing enabled. Static addresses 136.232.7.[200-249],
		dynamic addresses 136.232.7.[250-254].
		case1 as fileserver defined.
mac1:		Macintosh with Ethernet interface, MacTCP installed
		static address 136.232.7.1
mac2:		Mac Plus, MacTCP installed <--- here is my problem
mac3:		Mac Plus, MacTCP installed, address 136.232.7.202
		(address from gator1)
case1:		Sun server

Ok. Each mac (mac1..mac3) is able to mount a filesystem from the Sun
over the GatorBox. Interpoll, started on each mac, also stats each
other mac on the whole net.
mac1 is also able to connect each TCP/IP node with TCP/Connect
(telnet). Also mac3 is able to do that.
Now here comes my problem. mac2 is NOT able to connect to any TCP/IP
node behind Router1. I tried several ways to fix that, but I was not
successfull.

- Is the configuration I want possible?
- Do I have to install MacTCP on Router1 ? Would Router1 then also
  act as a TCP/IP router?
- Do I have to setup then Router1 as default gateway for mac3?
- How do I have to setup MacTCP on mac3 correctly:
  - using server IP addresses (from gator1)?
  - using dynamically adresssing (also from gator1)?
  - using static addresses?

Getting this configuration to work is *very* important for me, since
we have to bridge some months with a solution, until we get an
additional GatorBox...

I would have installed MacTCP on Router1, but it's not easy to shut
down that server just for testing. 

I would *very* appreciate, if somebody outthere could give me a
hint...

Thanks in advance

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

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 92 19:11:28 GMT
From:      chrobot@irisa.fr (Piotr Chrobot)
To:        comp.protocols.tcp-ip
Subject:   ip-isdn

We are students at French Telecommunication University(ENST Bretagne)
of Rennes,France.
In order to make our project we look for the products (software,
hardware), accessible on the market, which enable the IP pakets
transmission through the ISDN.
Please, send any information on address: chrobot@irisa.ir 

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jan 1992 22:40:24 GMT
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: MacTCP (?) routing problem? (long)

dhuber@autelca.ascom.ch (Daniel Huber) writes:

>				case1	mac1
>				|	|
 --------+-------+-------+-------+----NET1
>			|			|
 Router1			gator1
>			|			|
>		---+----+--------NET2		|
>	           |			--------+--+-----NET3
>		   mac2				   |
>						   mac3
 
>Now here comes my problem. mac2 is NOT able to connect to any TCP/IP
>node behind Router1.
 
>- Do I have to install MacTCP on Router1 ? Would Router1 then also
>  act as a TCP/IP router?

Nope. This won't help.

It looks to me that the GatorBox (which I assume mac2 must get its
IP address from) is set up to serve LocalTalk only. This is an option
in the IP configuration screen (I think). Make sure it is turned off.
If you can't find it, write via e-mail and I will look in my manual
tomorrow in the office.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 01:19:46 GMT
From:      fvance@airgun.wg.waii.com (Frank Vance)
To:        comp.protocols.tcp-ip
Subject:   Which regional network?

Which regional network(s) covers Nebraska, Kansas, Oklahoma, Missouri,
Arkansas, and North and South Dakota?

Is there a map available for this (supposedly existing) regional network,
similar to the maps for the other regionals?

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

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 1992 04:07:36 GMT
From:      dupuy@cs.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip
Subject:   Re: Network simulation tool needed

A new version of Nest, Columbia's Network Simulation Testbed, has been released.
Nest is a tool for simulating and prototyping distributed algorithms and
systems.  It includes a Unix simulation library and a graphical user interface.
The Nest library provides a simulated network environment in which independent
functions can easily be composed into distributed systems.  The simulated
network can be modified while the system is running, allowing performance
tracing and measurement in a wide variety of simulated conditions, including
failures.

This new version of Nest (version 2.6) includes a number of enhancements to
portability and user interface.  The Nest 2.6 distribution includes complete
source, documentation and a sample application.  Nest 2.6 runs on most versions
of Unix, including non-Berkeley derived systems.  It has been tested on System
V.3, 4.3bsd, Ultrix 4.2, HP-UX 7.0 and SunOS 4.1.1 (earlier releases of these
operating systems are still supported).  In addition to CPUs supported
previously (VAX, MC68K, and WE32000), SPARC (Sun-4) and MIPS ports are
provided.

The user interface program for Nest 2.6 can be compiled either for SunView, or
for X, using the XView toolkit provided on Suns and available as part of the
MIT X11R4 distribution, in the user-contributed software section.

Nest documentation and full source is available via FTP on cs.columbia.edu:
[128.59.16.20].  You can use anonymous ftp to get the distribution; use the FTP
program on your machine to connect to cs.columbia.edu, and login with the
username "ftp", and your username as the password.  It is important to use ftp
binary mode, as shown in the example below:

Connected to cs.columbia.edu.
220 cs.columbia.edu FTP server (SunOS 4.1) ready.
Name (cs.columbia.edu:username): ftp
331 Guest login ok, send ident as password.
Password:username
230 Guest login ok, access restrictions apply.

ftp> cd nest
250 CWD command successful.

ftp> dir 
200 PORT command successful.
150 ASCII data connection for /bin/ls (128.59.24.3,1328) (0 bytes).
total 660
-rw-rw-r--  1 dupuy    wheel      195069 Nov 18 06:27 nest-2.6.tar.Z
-rw-rw-r--  1 dupuy    wheel       72451 May 31  1990 nest-25-disp.tar.Z
-rw-rw-r--  1 dupuy    wheel       78099 May 31  1990 nest-25-doc.tar.Z
-rw-rw-r--  1 dupuy    wheel      172146 May 31  1990 nest-25-doc2.tar.Z
-rw-rw-r--  1 dupuy    wheel      122747 May 31  1990 nest-25-src.tar.Z

ftp> binary
200 Type set to I.

ftp> get nest-2.6.tar.Z
.
. [ more messages here ]
.
ftp> bye
221 Goodbye.

There are five files in the ~ftp/nest directory:

 195069 bytes	nest-2.6.tar.Z		Source for Nest 2.6 library & UI display

 78099 bytes	nest-25-doc.tar.Z	Lineprinter formatted documentation.
 172146 bytes	nest-25-doc2.tar.Z	Scribe and PostScript formatted docs.

 122747 bytes	nest-25-src.tar.Z	Source for Nest 2.5 simulation library.
 72451 bytes	nest-25-disp.tar.Z	Source for Nest 2.5 user interface.

The Nest software is distributed under this arrangement for research and
evaluation purposes only.  Any redistribution or commercial use of the software
itself in any form is prohibited without further licensing from Columbia
University.

@alex
--
--
inet: dupuy@cs.columbia.edu
Member of the League for Programming Freedom -- write to league@prep.ai.mit.edu

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 08:35:14 GMT
From:      koerber@ap542.uucp (Mathias Koerber)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/services port id reservations

In article <1992Jan20.194844.14741@intelhf.hf.intel.com> flamer@mithril.intel.com (Jim Trethewey) writes:
|How does a person developing a server pick a good port ID?
 
|                                                 But how can I 
|be sure (1) that port ID won't get allocated dynamically on a 
|heavily-loaded system, and (2) that port ID won't collide with 
|some OTHER custom application, or ingres, or something else?
|[I know if this happens I can just edit /etc/services and
|everyone that calls getservbyname() will figure it out, but
|this is not a nice thing to force on my poor users].

This might be stupid, but I always thought that /etc/services only assigned the
portnumbers "locally". So how does my CLIENT MACHINE figure out, what port
a server on another machine listens to, when it's not a well-known port?

Is there a service, whereby I can call the remote machine and ask it to
get the entry from /etc/services?

aTdHvAaNnKcSe
----
Mathias Koerber   | Tel: +49/89/636-45685   | koerber%ap542@ztivax.siemens.com
SNI AP 114        | Fax: +49/89/636-45860   | koerber@ap542.uucp
MchP/LZ Rm:L1562  |  4: C=DE/A=DBP/P=SNI    | koerber.muc@sni.de
Carl-Wery-Str. 22 |X.0: O=SIEMENS NIXDORF/OU1=MUENCHEN/OU2=P4/OU3=D5/OU4=AP11
D-8000 Muenchen 83|  0: S=KOERBER/G=MATHIAS
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht was Leiden schafft *

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 10:05:28 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: UDP question

After I claimed that the Sun ie ethernet driver didn't through away
packets, but instead caused the user application to block, 
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) wrote in <g5tiiss@sgi.sgi.com>:

>Read the code and explain how to do otherwise in a socket based system.
>The *_output() function is given a struct mbuf*, a struct ifnet*, and a
>struct sockaddr*.  It has no way to block, wake up, slow down, speed up or
>even know about any user processes.

Vernon is right, I was wrong.  With sockets implemented as they are,
there is no way for an _output() routine  to apply back pressure.

I engaged keyboard before brain.  The only difference between the Sun ie
and le ethernet driver is where they toss packets when they are over-
whelmed.  One does it directly in the *_output() routine, the other
in the hardware start() routine.

>From private correspondence, it seems that some STREAMS implementations use
>the same strategy of discarding on overflow, while some new STREAMS
>implementations can slow down the user process.

My only excuse for my foot-in-keyboard is that I have recently been
looking at STREAMS routines, where it is indeed possible, if all the
modules on a stream cooperate, to apply back-pressure all the way
back to the user process.

Sorry for the noise.

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

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 14:30:41 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   TCP Segment size

Hello,

    I have a couple of questions relating to the TCP segment size under
Sun OS 4.1.1.

1)  When using the TCP_MAXSEG option on getsockopt(), is the value
returned the segment size used whenever possible or is it just an upper
limit?

2)  Does the TCP segment size dynamically change during a connection or is the
value fixed after the initial negotiation?
Thanks in advance.


Shikhar

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 15:33:55 GMT
From:      rmy@pacer.cis.ufl.edu (Rahim Yaseen)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Looking for info on OSF/DCE


Summary: 
Followup-To: 
Distribution: usa
Organization: Univ. of Florida CIS Dept.
Keywords: 


i would appreciate it if anyone could let me know where i
might be able to find a (detailed) description of
OSF/DCE i.e., protocols, capabilities, portability, release
dates (projected ?), etc.

i am not sure if the question is directed at the correct
newsgroups. is there a newsgroup where this question would
be more appropriate ?

thanks in advance for any info.
please e-mail responses to rmy@reef.cis.ufl.edu

- yaseen



-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 17:29:09 GMT
From:      vaillan@ireq.hydro.qc.ca (Clement Vaillancourt)
To:        comp.protocols.tcp-ip
Subject:   Re: Public Domain TCP-IP

In article <3460@winnie.fit.edu> gallo@zeno.fit.edu (Michael A. Gallo) writes:
>Question:
>
>Is there a public domain package available for PCs that will provide 
>TCP/IP capabaility?  Essentially I will need the TCP/IP drivers and a
>Telnet application.  Please respond via email.  (The PCs are 386 IBM
>compatibles.)
>
>Mike Gallo
>Florida Institute of Technology
>Melbourne, FL 32901
>407/768-8000 x7551
>gallo@zeno.fit.edu


We use NCSA package with the Clarkson drivers.

You can ask the data base archie.cs.mcgill.ca for the locations where
you can get it. Here are two outputs from archie:

Host tut.cis.ohio-state.edu

    Location: /
      DIRECTORY drwxrwxr-x        512  Feb 20 1990  ncsa

Host unixd1.cis.pitt.edu

    Location: /software/ms-dos
      DIRECTORY drwxr-xr-x       2048  Mar 31 1991  ncsa

there are many more....

Clem.
-- 
   Clement Vaillancourt, Analyste,   |   Institut de Recherche d'Hydro-Quebec
   Responsable du Reseau Ethernet    |        1800 Montee Ste-Julie, Varennes
   (Analyst, Network Manager)        |             P. Quebec, Canada, J3X 1S1
   vaillan@ireq.hydro.qc.ca   VE2HQJ |Tel:+1 514 652 8238 Fax:+1 514 652 8309

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 17:44:56 GMT
From:      harry@atmos.washington.edu (Harry Edmon)
To:        comp.protocols.tcp-ip
Subject:   Berkeley Packet Filters under SunOS 4.1.1

I would like to implement Berkeley Packet Filters under SunOS 4.1.1.
I need the patches to the operating system (especially to if_le.c)
that are necessary to make this work.  I have access to SunOS source.
If anyone has done this, could they let me know how to do it.  Thanks.
--
Harry Edmon		INTERNET: harry@atmos.washington.edu
(206) 543-0547		UUCP:	  uw-beaver!atmos.washington.edu!harry
Dept of Atmospheric Sciences, AK-40
University of Washington

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 1992 18:08:49 GMT
From:      s2465499@ucc.umass.edu (Jim Doyle)
To:        comp.protocols.tcp-ip
Subject:   Does CSLIP need hardware serial port or can I use ptys through a LAT ?

	Just double checking on a technical problem....
We have a number of Ultrix hosts that may be used to support CSLIP for
dial-users on our campus. Our dial-in ports are not connected to 
hardware serial lines on the Unix machines. Rather we use Xyplex
terminal servers to attach the modem pool to the machines via a 
LAT and TCP/IP connection.

	Will CSLIP still allow users to start a dial-up tcp/ip traffic
session on ptys or is a hardwired serial connection to the machine
required?

.......... Jim 
:wq


-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 1992 18:26:20 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
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:
>	Are Sun still making the mistake described by Comer ?

In a word, yes, although compatibility with their own equipment already
in the field makes this hard for them to avoid.

>	What should the broadcast address be - should I force it to
>	xxx.xxx.255.255 ?

You should use the all-1s broadcast address unless you need to talk to
systems that are incapable of using anything except all-0s.
-- 
"Breakthrough ideas are not             | Henry Spencer @ U of Toronto Zoology
from teams."  -- Hans von Ohain         |  henry@zoo.toronto.edu  utzoo!henry

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 92 18:52:33 GMT
From:      Karl_Kleinpaste@cs.cmu.edu
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: Public Domain TCP-IP

vaillan@ireq.hydro.qc.ca writes in comp.protocols.tcp-ip:
   Here are two outputs from archie:
   Host tut.cis.ohio-state.edu

A problem for Archie: Making "gone" hosts really "gone."

Tut hadn't been under maintenance for quite a while (he was a 5-yr-old
Pyr 98x), and he smoked his boot floppy and one of his CPUs over
Christmas.  He won't be back.  Archives had been moved to
archive.cis.ohio-state.edu some time back anyway.  Tut is now a CNAME
for Archive.  Yet Archie continues to report about things like this.

fyi,
--karl

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 19:03:12 GMT
From:      alberti@mudhoney.micro.umn.edu (Albatross)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP/CSLIP for MSDOS PC information needed

In <24JAN199217000431@ltp2.gsfc.nasa.gov> gumley@ltp2.gsfc.nasa.gov (Liam E. Gumley) writes:

>G'day folks.
 
>Can anybody tell me where to find a SLIP and/or CSLIP package for a
>MSDOS PC that works with a *modem* (9600 bps V.42bis) over normal phone lines?
 
>Any and all information/tips/hints are very welcome.

You may wish to try out the SLIPDIAL program available for anonymous fTP
from boombox.micro.umn.edu:/pub/slipdial directory.  A handy utility for 
initiating your SLIP session.  It's beta, so please write and offer
comments and improvements.
--
Bob Alberti: Computer & Information Services U of MN   |aka: Albatross| Unitar-
Internet   : alberti@boombox.micro.umn.edu             |Metropolis BBS| ian/
Disclaimer : My employer does not mean what I say.     |(612) 721-1870| Univer-
Ingredients: 30% header, 30% quote, 10% comment, 30% cutesy signature.| salist!

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 92 19:45:20 GMT
From:      sweeny@silver.ucs.indiana.edu (Brent Sweeny)
To:        comp.protocols.tcp-ip
Subject:   Re: Which regional network?

In article <1178@airgun.wg.waii.com> fvance@airgun.wg.waii.com (Frank Vance) writes:
>Which regional network(s) covers Nebraska, Kansas, Oklahoma, Missouri,
>Arkansas, and North and South Dakota?
>
>Is there a map available for this (supposedly existing) regional network,
>similar to the maps for the other regionals?
>
Midnet serves the area you mention, in addition to ND and IA (except for the U
of Iowa, which is in CICnet).  an 11/90 listing of Midlevel Networks list the
contacts for Midnet as Mary Beadslee, mkb@hpux.unl.edu and Dale Finkelson,
dmf@westie.unl.edu.

hope that helps.
Brent Sweeny
Indiana University 
sweeny@indiana.edu


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 19:49:42 GMT
From:      dxe@cassidy (Dan Ellsweig - Network Software)
To:        comp.protocols.tcp-ip
Subject:   Re: Two simple programming questions

In article <9639@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>I am familiar with C programming under Unix, but new to network programming.  I
>hope someone can answer two simple questions for me:
>
>1) Can a process interact with a socket using read() and write() rather than
>send() and recv()?  If so, are there any disadvantages to doing so?
>___________________________________________________________________
>Frank I. Reiter                UUCP:  ...!van-bc!rsoft!frank
>Reiter Software Inc.       INTERNET: frank@mindlink.bc.ca (prefered)
>Surrey, British Columbia             frank@rsoft.bc.ca


Greetings

I make this posting under the assumption that sometime after one makes a recv or send 
call, the library function simply moves ones parameters to a read or write
call. Any time you can eliminate code and use the lower level function it would
be safe to say you are increasing your codes efficiency!!.
In the case of sendmsg and recvmsg things get a little more complex as the functions
take care of scatter gather operations while making read and write calls!!





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

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 92 01:09:42 EST
From:      max@underg.UUCP (Max Cray)
To:        comp.protocols.tcp-ip,news.newusers.questions
Subject:   1-900 SLIP Access

 
   Is there a service where you can call a 1-900 number and connect to the 
Internet using the SLIP protocol? I am thinking of something like UUNET's 
uucp service, but for SLIP instead. Could someone mail me info if this 
service exists, or if there is a reason why is does not exist please send me 
mail telling me why this is a bad idea? Thank you in advance.

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

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 20:27:31 GMT
From:      hanson@pogo.fnal.gov (Steve Hanson)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS broadcast address

In <1992Jan27.182620.22160@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

>In article <1992Jan25.093952.24835@rtf.bt.co.uk> duplain@rtf.bt.co.uk (Andy Duplain) writes:
>>	Are Sun still making the mistake described by Comer ?
 
>In a word, yes, although compatibility with their own equipment already
>in the field makes this hard for them to avoid.

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.

-- 
Steve Hanson - FERMILAB, Batavia, Il.  (708)840-8043
hanson@calvin.fnal.gov or hanson@fnal.fnal.gov


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 1992 20:35:27 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: Two simple programming questions


   Article <725@pivot-sts.sbi.com> dxe@cassidy (Dan Ellsweig-Network Software):

      Article <9639@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter):

      1) Can a process interact with a socket using read() and write()
      rather than send() and recv()?  If so, are there any disadvantages to
      doing so?

   I [assume] that sometime after one makes a recv or send call, the 
   library function simply moves ones parameters to a read or write call.

recv() and send() are system calls, not library routines (on BSD-based
systems). 

read() and write() work for sockets, if you don't need the added functions
provided by recv() and send().

   In the case of sendmsg and recvmsg things get a little more complex as
   the functions take care of scatter gather operations

As do readv() and writev(), also BSD system calls, also fine for sockets.

John Wroclawski
jtw@lcs.mit.edu

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 92 21:50:44 GMT
From:      sb7c+@andrew.cmu.edu (Shikhar Bajaj)
To:        comp.protocols.tcp-ip
Subject:   Re: Two simple programming questions

Also, don't forget that send() and recv() allow you to use the peeking
options that read() and write() don't support


Shikhar

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 1992 22:27:59 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <e7a702Kz58SJ00@amdahl.uts.amdahl.com>, wjq@uts.amdahl.com (Bill Quigley) writes:
|> I'm confused.  I thought that, from the FIN-WAIT-2 state, it was
|> impossible to get back to ESTABLISHED.  So a timer started in
|> FIN-WAIT-2 can only drop a connection that couldn't communicate
|> anyway, right?  It sounds like Phil is talking about timing out
|> established connections, while I think the original problem is timing
|> out connections in fin-wait-2 that never receive a fin.

You're correct in that you can't get back to ESTABLISHED from
FIN-WAIT-2, but it is NOT true that you can't communicate on a TCP
connection in the latter state -- you could continue receiving data
indefinitely. You may be confusing TCP's functionality with its most
common user interface, the close() call in UNIX, which closes both
directions of a socket simultaneously. But nothing *requires* you to
do this.

In fact BSD UNIX derivatives provide a shutdown() call that maps very
nicely into TCP's half-close operations. If you say shutdown(s,1),
you'll send a FIN on the connection but it will remain open
indefinitely (in FIN-WAIT-2 state) for reading.

Phil

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jan 1992 23:09:05 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: ping with Record Route Option ?

In article <g7j6af8@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> In article <1992Jan24.102836.18414@ap542.uucp>, koerber@ap542.uucp (Mathias Koerber) writes:
|> > Is there a program, which does basically a ping, but with the
|> > IP-Options Record Route and/or timestamp set?
|> 
|> 
|> There was something called "pong" which used loose source routing.
|> 
|> 4.3BSD-reno (I think) ping includes -R which does record route.
|> Years older source from BRL.MIL does it as well.
|> 
|> 
|> Vernon Schryver,   vjs@sgi.com
|> 

Does anyone do anything with the record route and source route options
anymore? Aren't these things just anacronisms from a bygone era?

	-John Kalucki
	johnk@gordian.com


-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 00:05:27 GMT
From:      Peter@aquarius.Stanford.EDU (Peter C. Tam)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   SLIP on 2400 baud Asychronous modems

Hi,
  I have slip (Serial Line Internet Packet) running in Sun OS 4.1.1 Unix.
	It will work fine if I use only hardwire, with
			TX <-> RX,
			RX <-> TX,
			RTS <-> CTS,
			DTR <-> DSR
  But if I hang a pair of 2400 baud dial up modems with factory defaults
setting between the slip line, the client software complains about bad
checksums on packets, and starts to throw packets away.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 00:39:47 GMT
From:      Peter@aquarius.Stanford.EDU (Peter C. Tam)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: SLIP on 2400 baud Asychronous modems

In article <Peter.2@aquarius.Stanford.EDU> Peter@aquarius.Stanford.EDU (Peter C. Tam) writes:

>Hi,
>  I have slip (Serial Line Internet Packet) running in Sun OS 4.1.1 Unix.
>       It will work fine if I use only hardwire, with
>                       TX <-> RX,
>                       RX <-> TX,
>                       RTS <-> CTS,
>                       DTR <-> DSR
>  But if I hang a pair of 2400 baud dial up modems with factory defaults
>setting between the slip line, the client software complains about bad
>checksums on packets, and starts to throw packets away.

   Please forward all replies to pct@leo.Stanford.EDU !!!!!!!

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 01:05:05 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   getperrname() question

SCO documents getperrname() thusly:

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?

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

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 01:14:13 GMT
From:      wyatt@ccu.umanitoba.ca (David Anthony Wyatt)
To:        comp.sys.ibm.pc.net,comp.sys.dec.micro,comp.sources.wanted,comp.binaries.ibm-pc.wanted,comp.dcom.lans.ethernet,comp.protocols.tci-ip
Subject:   WANTED: Telnet packet drivers for EtherWORKS Turbo ethernet cards

Can anyone help us locate NCSA telnet / tn3270 packet drivers for our
DEPCA EtherWORKS Turbo ethernet cards?

We are running a lab of 16 Digital 320sx DECstations (PCs) equipped with 
Digital 'EtherWORKS Turbo' ethernet cards and networked by small-size 
coaxial ethernet.  The network is served by a Novell 3.11 server and a
DECnet VMS Pathworks 4.0 server.  The client PCs are configured to access 
either server (but not both simultaneously).  We intend to attach our LAN 
to the campus backbone (and it's develnet, MVS and SunOS UNIX services) and 
that's where the TCP/IP packet drivers will be needed.

Our best advice from our Computer Services Department is to junk our VMS
DECnet server, replace all the EtherWORKS cards with something standard, 
and then we'll be OK.  There has to be another way!  I don't think I can
get away with proposing the replacing of equipment less than eight months
old!

Has anyone any advice for our situation? We are after DECnet, Novell and
TCP/IP all on the same EtherWORKS cards.  Is it possible?  Practical?

David Wyatt
Continuing Education Division
University of Manitoba

-- 
                                                                                
---David Wyatt          
Internet:   WYATT@ccm.UManitoba.CA   or   WYATT@UOFMCC.BITNET   or
            wyatt@ccu.umanitoba.ca

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 01:24:12 GMT
From:      khanna@penda.cs.odu.edu (Sanjay Khanna)
To:        comp.protocols.tcp-ip
Subject:   Window Size Selection in SunOS 4.1.1?


I wonder how the TCP window size is chosen initially and where in
the SunOs it is first initialized. I had been trying to go
through some RFCs but they donot recommend specific values. 

Is there any information on window management in SunOs is
documented somewhere?


Hopefully somebody out there can answer these question quick for
me. A direct mail to khanna@cs.odu.edu will be appreciated.

Thanks.


khanna@cs.odu.edu

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 01:47:41 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ping with Record Route Option ?

In article <1992Jan27.230905.26471@gordian.com>, johnk@gordian.com (John Kalucki) writes:
> 
> Does anyone do anything with the record route and source route options
> anymore? Aren't these things just anacronisms from a bygone era?

`ping -R` is every bit as useful as traceroute.  With ping -R you can
diagnose problems on the return path.

Consider also the new LSRR option in traceroute.


Vernon Schryver, vjs@sgi.com


-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 03:26:53 GMT
From:      cyrus@pprg.eece.unm.edu (W. Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   network tools survey

I am looking for ALL sources of PD network tools.

1) I am interested in both source code as well as binaries only.
2) At this point I do not care what the machine is that it runs on.
3) I don't care how complicated it is or how simplistic, I would like
   to know about ALL available PD software.
4) I am also interested in any PD "sampling" of network traffic to help
   me show others about how the various tools work. [a 'sampling' that
   does not contain peoples passwords or other 'sensitive' data]

I am interested in doing some network 'work' and have various machines
available to me thus the interest in ALL machines.  I would rather not
restrict my search by describing what my needs are, but would rather see
what is available (different tools might approach the same problem
differently).

Anyway, I would very much appreciate being pointed to archive sites, or
individuals, where I can obtain these tools.

If there is enough interest, I will post a summary.

Thanks in advance.

-- 
W. Tait Cyrus   	e-mail: cyrus@pprg.unm.edu
University of New Mexico			
Dept. of Electrical and Computer Engineering
Albuquerque, New Mexico 87131

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 04:46:12 GMT
From:      lewis@ssigv.UUCP (Don Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS broadcast address

In article <1992Jan27.182620.22160@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1992Jan25.093952.24835@rtf.bt.co.uk> duplain@rtf.bt.co.uk (Andy Duplain) writes:
>>	What should the broadcast address be - should I force it to
>>	xxx.xxx.255.255 ?
>
>You should use the all-1s broadcast address unless you need to talk to
>systems that are incapable of using anything except all-0s.

Sun should at least provide a flag "-onesbroadcast" or something for
ifconfig so that you don't have to hard code the actual broadcast
address for each host, (really nasty if you have multiple nets/subnets).
-- 
Don "Truck" Lewis              Phone: +1 916 265-3211   Silicon Systems
Internet: (under contruction)  FAX:   +1 916 265-2931   138 New Mohawk Road
UUCP: {uunet,tektronix!gvgpsa.gvg.tek.com}!ssigv!lewis  Nevada City, CA  95959

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 06:06:13 GMT
From:      gah@trc.mew.mei.co.jp (Gary A. Hildebrand)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Problem with ARP, Sun, FDDI, Ethernet

I have recently encountered a serious problem involving ARP packets.  The
network involved is relatively simple:

+-------------+    +------------------+                +-----------------+
|             |--->|                  |   (Ethernet)   |                 |
| Sun FDDI/DX |    | AT&T Multibridge |================| UNIX EWS & PC's |
|   {DAS}     |<---|     {DAS}        |                |     & Mac's     |
+-------------+    +------------------+                +-----------------+
          ^ |        ^ | (FDDI dual ring)
          | v        | v
        +-------------------+
        |                   |
        |  AMD Fastcard 2   |
        | FDDI Concentrator |
        |      {DAS}        |
        +-------------------+
     	   ^ |
     	   | v       
       +---------------------+
       |                     |
       | Network Peripherals |
       |     NP-EISA/STP     |
       |        {SAS}        |
       +---------------------+

The problem is talking to the Sun on the FDDI dual ring, a 4/330 running
SunOS 4.1.1 w/JLE, which has a Sun FDDI/DX interface installed.

It seems that if a system *either* on the FDDI ring itself or on the
bridged Ethernet attempts to use ARP to query the Sun's hardware address,
the Sun (according to etherfind running on the Sun) will see the ARP
request, generate a legitimate ARP reply, and the other system will fail to
register the information.  It is not entirely clear whether the failure is
due to the ARP reply packet getting lost or containing invalid information
(the only two possibilities I can think of for failure).  However it is
highly unlikely that the packet is getting lost, since this has been tried
from as close as the PC which has the Network Peripherals NP-EISA/STP board
installed, which is attached via the AMD FDDI Concentrator directly to the
FDDI ring without any form of bridging.  FDDI monitoring software on the
AMD FDDI Concentrator shows the ARP requests being transmitted (since they
are always broadcast), but cannot detect ARP replies.

As for invalid information, etherfind shows expected data in both the ARP
request and reply packets.  The "Ethernet type" is 0x0806 (ARP), the ARP
hardware type is 0x0001 (for 10MB Ethernet), the ARP protocol type is
0x0800 (IP), the hardware address length is 6 bytes, the protocol address
length is 4 bytes, the ARP control field is either 0x0001 for request or
0x0002 for reply, and encapsulated source/destination hardware/protocol
addresses appear in the right order.  There seem to be data bytes beyond
the destination protocol address, what these are I have no idea since the
content is not consistent and I don't know where the checksum is in the
etherfind output.  The length of all ARP frames has been 60 bytes.

The obvious downside of this problem is little or no TCP/IP
communications with the Sun!!!  Curiously, if the Sun is allowed to
initiate the ARP dialog (by Telnetting out from the Sun, for instance), the
Sun will successfully receive the ARP reply, the ARP caches of both
machines will be populated, and the session will be successful.  For this
reason, UNIX-UNIX sessions with the Sun have not been a problem, since lots
of two-way activity is usually going on.  However, PC- and Macintosh-based
TCP/IP implementations have not been so amiable.  When first brought up,
these systems have a clean ARP cache (if any) and are generally not spoken
to initially by the Sun since they are mostly running client-based
stuff.  Examples:

  1.  The PC which has the Network Peripherals NP-EISA/STP installed has a
      copy of NCSA Telnet 2.3b14 running on it.  After running TELBIN,
      the only way to telnet to the Sun is to have the Sun send something
      to the PC, say a ping.  Then TELBIN will record the ARP information and
      telnetting is fine until TELBIN's ARP cache times out.  But this
      machine is directly on FDDI!

  2.  The same exact scenario as (1) exists from other PC's on the Ethernet
      which is bridged, running either the same version of TELBIN or the
      2.2 version.

  3.  PC's on the bridged Ethernet running Ungermann-Bass Net/One TCP/IP
      Telnet software cannot connect to the Sun, and cannot be made to
      using the method of (1) because this software is neither a server nor
      responds to pings. 

  4.  Mac's running NCSA Telnet 2.3.x over the bridged Ethernet cannot
      telnet to the Sun, and cannot be made to using the method of (1) for
      unknown reasons.

If anyone can provide help on this matter, please do so via e-mail.  If
there is enough of a response to this, I will post a summary.

/ Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
/  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
/   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
/    Tokyo 108, JAPAN                Tel:      03-3452-4941            \

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 06:24:36 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Which regional network?

In article <1178@airgun.wg.waii.com> fvance@airgun.wg.waii.com (Frank Vance) writes:
>Which regional network(s) covers Nebraska, Kansas, Oklahoma, Missouri,
>Arkansas, and North and South Dakota?

Nominally, Midnet (altho N. Dakota schools are part of Northwestnet
and Arkansas might be attached to Suranet).

But if you're serious about getting IP connected you should also get
quotes and information from the national IP network providers, e.g.
ANS, Alternet, and PSI.  In many cases these folks are more nimble
than the original NSF-chartered academic regional networks, and can 
offer competetive terms.

Things are spread pretty thin between the coasts, good luck - aside
from a few isolated pockets there's a considerable amount of area
that's just barely provided with IP service compared to e.g. Boston
or the Bay area.

--Ed


-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 06:37:24 GMT
From:      robert@peregrine.peregrine.com (Robert Young)
To:        comp.protocols.tcp-ip
Subject:   Need a telnet version that supports 3270 interface

I am looking for a public domain software version of telnet what supports
connectivity to IBM's MVS OS.

It needs to be similar to the tn3270 program that comes with AIX. Tn3270 is
really telnet but modified to interface with MVS/TSO.

ANy help out there would be really appreciated.

Please e-mail your replies.


My uucp address is:  ......!uunet!peregrine!robert


I am in the process of setting up our link to the Internet. Then I will
be able to to ftp transfers.



Thanks

Robert Young
(Peregrine Systems)


-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 16:11:36
From:      meissner@osf.org (Michael Meissner)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Looking for info on OSF/DCE

In article <1992Jan28.143429.16862@uwm.edu> hardiman@csd4.csd.uwm.edu
(Paul V Hardiman) writes:

| There is a book called "Guide to OSF/1: A Technical Synopsis"
| published by O'Reilly & Associates, Inc.  304 pages.  $21.95.
| ISBN 0-937175-78-1.  (800) 338-6887.

Umm, OSF/1 is the operating system, not the distributed services (DCE)
which the original question asked for.  While there is some
interconnection, they are separate offerings.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 14:12:48 GMT
From:      german@nd.edu (CHAD W. GERMAN)
To:        comp.protocols.tcp-ip
Subject:   Trumpet Posting problems

I'm having problems being able to post messages using version 1.04B of 
Trumpet...... I always get the message "Error in posting - re-edit 
article".  If I use version 1.03 everything posts fine.... Any 
suggestions????



*************************
Chad W. German
University of Notre Dame
internet:chad.w.german.1@nd.edu

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 14:18:07 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Problem with ICMP:Port Unreachable to Sun

I'm having a few problems connecting my TCP/IP implementation on a PC to a Sun
SPARCstation IPC, and would appreciate some advice on why my approach is wrong.
Specifically, I can initiate a telnet connection and log in fine. If the PC
then crashes (on purpose, to test robustness!) and connects again (on a 
different TCP port number), the Sun still attempts to retry the outstanding
segments from the previous connection. All this is fine and dandy, but when 
the PC attempts to demultiplex one of the old TCP packets, 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!
	If it matters, the Sun is running SunOS 4.1.1, I don't knew the
revision numbers for its TCP/IP software.

	Am I doing something wrong, sending an ICMP Port Unreachable?

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 14:34:29 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Looking for info on OSF/DCE

In article <33875@uflorida.cis.ufl.EDU> rmy@pacer.cis.ufl.edu (Rahim Yaseen) writes:
>
>Summary: 
>Followup-To: 
>Distribution: usa
>Organization: Univ. of Florida CIS Dept.
>Keywords: 
>
>
>i would appreciate it if anyone could let me know where i
>might be able to find a (detailed) description of
>OSF/DCE i.e., protocols, capabilities, portability, release
>dates (projected ?), etc.
>
>i am not sure if the question is directed at the correct
>newsgroups. is there a newsgroup where this question would
>be more appropriate ?
>
>thanks in advance for any info.
>please e-mail responses to rmy@reef.cis.ufl.edu
>
>- yaseen


There is a book called "Guide to OSF/1: A Technical Synopsis"
published by O'Reilly & Associates, Inc.  304 pages.  $21.95.
ISBN 0-937175-78-1.  (800) 338-6887.

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 15:26:31 GMT
From:      weissh@nextadm.cc.vt.edu (Hugh Weiss)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: SLIP on 2400 baud Asychronous modems

In article <Peter.2@aquarius.Stanford.EDU> Peter@aquarius.Stanford.EDU (Peter C. Tam) writes:

>Hi,
>  I have slip (Serial Line Internet Packet) running in Sun OS 4.1.1 Unix.
>       It will work fine if I use only hardwire, with
>                       TX <-> RX,
>                       RX <-> TX,
>                       RTS <-> CTS,
>                       DTR <-> DSR
>  But if I hang a pair of 2400 baud dial up modems with factory defaults
>setting between the slip line, the client software complains about bad
>checksums on packets, and starts to throw packets away.

It sounds as if you have not turned off software (ie, xon, xoff) flow
control.  You need to look at your modem manual and find out how to do
this.  This should take care of your problem.  Good luck.

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

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 16:49:27 GMT
From:      Ed.Wilts@BCsystems.Gov.BC.CA (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Introductory online documentation

X-Date: 28 Jan 92 08:48:31 -0800
X-Organization: BC Systems Corporation
Lines: 19

In article <1992Jan22.211058.236@galaxy.bcsystems.gov.bc.ca>, Ed.Wilts@BCsystems.Gov.BC.CA (Ed Wilts) writes:
> I'm looking for some introductory documentation to pass on to our users on
> TCP/IP - in particular, MultiNet.

Thanks to all who responded (the responses are still coming in).  Most people
pointed to a couple of RFC's, in particular RFCs 1118, 1175, 1206, and 1290.
I pulled my RFC's from FTP.NISC.SRI.COM.  I'm sure that there are many other
sites that store these - use Archie to find a site closest to you.

I have made some of the popular RFCs available to my users.  Most of the other
offers for documentation would have required me to do a bunch of customization
which I may eventually do.

Again, thanks for all the suggestions and offers of help.

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

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 17:53:47 GMT
From:      dtaylor@ems.cdc.com (Dave Taylor)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Looking for info on OSF/DCE

In article <33875@uflorida.cis.ufl.EDU>, rmy@pacer.cis.ufl.edu (Rahim Yaseen) writes:
|> 
|> Summary: 
|> Followup-To: 
|> Distribution: usa
|> Organization: Univ. of Florida CIS Dept.
|> Keywords: 
|> 
|> 
|> i would appreciate it if anyone could let me know where i
|> might be able to find a (detailed) description of
|> OSF/DCE i.e., protocols, capabilities, portability, release
|> dates (projected ?), etc.
|> 
|> i am not sure if the question is directed at the correct
|> newsgroups. is there a newsgroup where this question would
|> be more appropriate ?
|> 
|> thanks in advance for any info.
|> please e-mail responses to rmy@reef.cis.ufl.edu
|> 
|> - yaseen

Why not try the proverbial "horses mouth":
	Open Software Foundation (USA)
	11 Cambridge Center
	Cambridge, MA,  02142

	(617) 621-8700     (I think)

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 18:36:10 GMT
From:      brunner@practic.com (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: ping with Record Route Option ?

In article <1992Jan24.102836.18414@ap542.uucp> koerber%ap542@ztivax.siemens.com (Mathias Koerber) writes:

>Is there a program, which does basically a ping, but with the
>IP-Options Record Route and/or timestamp set?

Mathias, hi! long time no see! When I was working on improving the Netblazer's
signal/noise ratio and wanted to do just this, I'd take either the current
BSD or the BRL ping (I've forgotten which) and make the _few_ line change
to change the packet type and fire off whatever option I was keen on that day.
I'm working on a more generalized version for rreq/1009 testing, let me know
if it (the ping hack) isn't obvious.


-- 
#include <std/disclaimer.h>
Eric Brunner 4bsd/RT Project
uucp: uunet!practic!brunner or brunner@practical.com
trying to understand multiprocessing is like having bees live inside your head.

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 18:57:00 GMT
From:      liam@dcs.qmw.ac.uk (William Roberts)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Problem with ARP, Sun, FDDI, Ethernet


This is a classic. The problem is as follows:

a) ARP packets contain a "hardware type" code, which is officially supposed
   to be different for Ethernet and FDDI.
b) Sun kernels only respond to the "hardware type" for Ethernet, so the
   FDDI driver silently translated the FDDI "hardware type" to look like
   it was an Ethernet hardware type
c) Sun FDDI drivers silently translate the Ethernet "hardware type" back
   to FDDI when transmitting ARP packets, though in later versions of the
   driver this is configurable

Note that b) happens BEFORE the Network Interface Tap, so Etherfind will tell 
you lies about the true content of ARP packets viewed through a Sun FDDI 
driver. 

Another amusing thing to watch out for is the Sun interface defaulting to a 
Maximum Transfer Unit size of about 4K, and so sending out frames too large to 
transfer to the Ethernet. Try "spray" from the FDDI machine, use various 
different packet sizes, and expect everything to stop once you get over 1514 
bytes long. This definitively messes up NFS unless you turn down the rsize and 
wsize options in the mount commands....

Contact Sun and ask them for the ARP patch - if you really do need both 
flavours of ARP packet (the FDDI "hardware type" is officially 802.3 rather 
than specifically FDDI, so your PC stuff might expect it) then you are stuffed.

PS. You mentioned Macs - if you are using EtherTalk phase 2 then you will 
probably find that the EtherTalk ARP packets are being misconstrued by your 
bridges as something to do with encapsulation of old-Ethernet frames in 802.2 
frames using SNAP. I don't know what you do about that....
--

% 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

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 92 19:51:28 GMT
From:      klassen@sol.UVic.CA (Melvin Klassen)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: ARCHIE databases are out-of-date (was: Public Domain TCP-IP

In article <1992Jan27.185238.133791@cs.cmu.edu> 
                    Karl_Kleinpaste@cs.cmu.edu writes:
>
>A problem for Archie: Making "gone" hosts really "gone."
>
> Archives had been moved from TuT to 
>archive.cis.ohio-state.edu some time back anyway.  Tut is now a CNAME
>for Archive.  Yet Archie continues to report about things like this.
>
When you login to archie, it states:
  ** 'help' for help
  ** corrections/additions to archie-admin@archie.McGILL.CA
  ** bug reports, comments, etc., to archie-l@archie.McGILL.CA
 
Pretty obvious, eh?

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1992 19:56:55 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SunOS broadcast address

In article <1992Jan28.044612.7007@ssigv.UUCP> lewis@ssigv.UUCP (Don Lewis) writes:
>Sun should at least provide a flag "-onesbroadcast" or something for
>ifconfig so that you don't have to hard code the actual broadcast
>address for each host, (really nasty if you have multiple nets/subnets).

Yes, that would be nice.  Failing that, we have code in our rc.local that
figures it out.  We copied the ifconfig loop from rc.boot, but replaced the
"ifconfig $1 ..." line with the code below.  It assumes that the netmask is
always 255.255.255.0, which is true on all our subnets.

ipaddr=`ifconfig $1 | awk '{if ($1 == "inet") print $2;}'`
broadcast=`echo $ipaddr | awk '{split($1,byte,".");printf("%d.%d.%d.255\n",byte[1],byte[2],byte[3]);}'`
echo Setting broadcast address to $broadcast on interface $1
ifconfig $1 $ipaddr -trailers up netmask 255.255.255.0 broadcast $broadcast
unset ipaddr broadcast
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 20:27:53 GMT
From:      a722756@pan.mc.ti.com (W. D. Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: Need a telnet version that supports 3270 interface

robert@peregrine.peregrine.com (Robert Young) writes:

>I am looking for a public domain software version of telnet what supports
>connectivity to IBM's MVS OS.
 
>It needs to be similar to the tn3270 program that comes with AIX. Tn3270 is
>really telnet but modified to interface with MVS/TSO.
 
>ANy help out there would be really appreciated.
 
>Please e-mail your replies.


>My uucp address is:  ......!uunet!peregrine!robert


>I am in the process of setting up our link to the Internet. Then I will
>be able to to ftp transfers.



>Thanks
 
>Robert Young
>(Peregrine Systems)

You did not specify what operating system you are using, but it sounds
like you need the tn3270 source.  I downloaded it from:
 
  devvax.tn.cornell.edu

if I am not mistaken.
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 21:12:40 GMT
From:      generous@sti.nasa.gov (Curtis Generous)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Telnet problems versus terminal emulation

We are running into some difficulty telneting to an IBM mainframe
from various workstations, namely IBM PC's.  Apparently, this host
sends a series of six 0x7f characters after each <CR><LF> (see hex
dump below; names have been changed to protect the stupid, huh I mean
innocent :-).

Some workstations seem to ignore those characters (e.g. Sun Sparcs).
Macs just seem to display an extra 6 spaces, but the PC's will display
garbage on the screen, probably whatever the 0x7f maps into PC's
character set. These IBM mainframe folks claim that an 0x7f is being
used as a padding character, used to handle slow devices (the same
software is used on async terminals hardwired to the host), and that it
is perfectly legal to do so.  (BTW: the mac's and pc's are running ncsa
telnet).  It is not clear to me if this is a terminal emulation issue
or a telnet issue, or neither....

Can anyone comment on this?  To me, just doesn't sound right, but I
have nothing to back my gut feeling; I somehow don't trust empty statements
made without back up, especially from people how only speak EBCDIC.  

Can anyone point me to documents or references which could verify that 
statement?  Any help is appreciated.

Thanks.

--curtis
---
Curtis C. Generous
NASA STI
generous@nova.sti.nasa.gov

======cut here==================================================================

nova % telnet

telnet> toggle netdata
Will print hexadecimal representation of network traffic.
telnet> open XXXX.XXXX.XXX

Trying xx.xx.xx.xx ...
Connected to XXXX.XXXX.XXXX
Escape character is '^]'.

 XXXXXX SYSTEM SELECTED
 

 > 0x0   0d0a
 < 0x0   fff9
 < 0x0   0d0a7f7f7f7f7f7f20200d0a7f7f7f7f7f7f2020202020434f4d4d414e442049
 < 0x20  53204d495353494e470d0a7f7f7f7f7f7f20202020202020596f752070726f62
 < 0x40  61626c79206869742074686520454e544552206f7220584d4954206b65792077
 < 0x60  6974686f757420616e7920636f6d6d616e642e0d0a7f7f7f7f7f7f2020202020
 < 0x80  2020506c65617365207265656e74657220636f72726563746c792e0d0a7f7f7f
 < 0xa0  7f7f7f454e5445523a


COMMAND IS MISSING
    You probably hit the ENTER or XMIT key without any command.
    Please reenter correctly.
ENTER:
--
---
Curtis C. Generous
NASA STI
generous@nova.sti.nasa.gov

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jan 1992 23:05:51 GMT
From:      logier@cheops.qld.tne.oz.au (Rob Logie)
To:        comp.sys.pyramid,comp.protocols.tcp-ip,aus.pyramid
Subject:   traceroute software

I am running a Pyramid MIS 12/6 with OSX 5.1a on a TCP-IP wide area
network.  I have seen traceroute for a SUN machine and I would like similar
functionality for the Pyramid, (ie, find out the routers etc in the
route between the pyramid and other hosts).
So if anyone know if this software could the please let me know.  

Please reply by EMAIL.


Thanks in Advance


-- 
Rob Logie                                    The opions expressed are mine alone
Telecom Australia                            and in no-way reflect the views or
TNE Computer Support Services                policy of Telecom Australia
EMAIL: logier@cheops.qld.tne.oz.au           "These are my opinions alone"

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 92 23:39:52 GMT
From:      toreh@merkur.uucp (Tore Haraldsen)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Telnet problems versus terminal emulation

In article <generous.696633160@nova> generous@sti.nasa.gov (Curtis Generous) writes:
>We are running into some difficulty telneting to an IBM mainframe
>from various workstations, namely IBM PC's.  Apparently, this host
>sends a series of six 0x7f characters after each <CR><LF> (see hex
>dump below; names have been changed to protect the stupid, huh I mean
>innocent :-).
>
 [some stuff deleted]
>
>Can anyone comment on this?  To me, just doesn't sound right, but I
>have nothing to back my gut feeling; I somehow don't trust empty statements
>made without back up, especially from people how only speak EBCDIC.  
>
>Can anyone point me to documents or references which could verify that 
>statement?  Any help is appreciated.
>
>Thanks.
>
>--curtis

I have seen this functionality also on a DEC10 running Tops-10. It sort
of dates your IBM host, this is oooooooooold stuff from the days when
"network" meant a television broadcating corporation :-) ... and if you
check out some flavours of unix termio, you may still find traces of it.
BUT: it should be possible to tell your mainframe to send NULs instead
of DEL (NULs were the default fill character under Tops-10).

- Tore Haraldsen

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 00:19:20 GMT
From:      peterd@tscc2.macarthur.uws.edu.au (Peter Degotardi)
To:        comp.protocols.tcp-ip,comp.protocols,tcp-ip.ibmpc,comp.protocols.tcp-ip.misc
Subject:   os/2 lpr (PD)

Hi there,
Does anyone know of a public domain lpr server for os/2 v1.x (& 2.0) ?
How about tcp/ip in general for os/2 ? Are their any public-domain or
shareware offerings available ? 
--
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.)

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 01:13:56 GMT
From:      billing@ccu.UManitoba.CA (Wayne Billing)
To:        comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Capture to file with NCSA Telnet?

In article <1992Jan21.073924.23614@ohsu.edu>, bj@steele.ohsu.edu (Bill Jackson) writes:
> 
> I am using NCSA Telnet for the Mac (MacTCP versions 2.3 and 2.4) and I have
> a desperate need to be able to capture the screen output to disk. 
> 
> My users run queries on the host machines which result in long listings, and
> while some of them are content to go through the hassle of selecting all the
> text with the mouse and then printing it, others are asking the obvious 
> question - "why can't I capture this to disk for perusal on a computer later?"
> 
Just redirect the most machine output to a file which can then be FTP'd as
required.

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 01:25:59 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Problem with ARP, Sun, FDDI, Ethernet

In article <1992Jan28.185700.28625@dcs.qmw.ac.uk>, liam@dcs.qmw.ac.uk (William Roberts) writes:
> 
> This is a classic. The problem is as follows:
> 
> a) ARP packets contain a "hardware type" code, which is officially supposed
>    to be different for Ethernet and FDDI.
> b) Sun kernels only respond to the "hardware type" for Ethernet, so the
>    FDDI driver silently translated the FDDI "hardware type" to look like
>    it was an Ethernet hardware type
> c) Sun FDDI drivers silently translate the Ethernet "hardware type" back
>    to FDDI when transmitting ARP packets, though in later versions of the
>    driver this is configurable

The ARP hardware type code required by RFC-1188 for FDDI is the same as
that for ethernet, 1.  In early days, it was proposed to use the 802
number, 6, but that was changed at the BOF at InterOP-90 (or 89?).  There
are words in RFC-1188 justifying the change.

The current good practice is to send 1, but accept both 1 and 6.


> Note that b) happens BEFORE the Network Interface Tap, so Etherfind will tell 
> you lies about the true content of ARP packets viewed through a Sun FDDI 
> driver. 

Sun is not the only one who stomped on the ARP packet as it went thru the
FDDI driver.  Handily, that is no longer necessary.


> Another amusing thing to watch out for is the Sun interface defaulting to a 
>Maximum Transfer Unit size of about 4K, and so sending out frames too large to 
> transfer to the Ethernet. Try "spray" from the FDDI machine, use various 
> different packet sizes, and expect everything to stop once you get over 1514 
>bytes long. This definitively messes up NFS unless you turn down the rsize and 
> wsize options in the mount commands....

This behavior is required by the standards.  Moreover, this behavoir is
required by good sense.  If you've bought a $10,000 or $3,000 Sun FDDI
interface, you don't want to give up 50% of your performance by default.

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.

> Contact Sun and ask them for the ARP patch - if you really do need both 
> flavours of ARP packet (the FDDI "hardware type" is officially 802.3 rather 
> than specifically FDDI,....

Again, this paragraph conflicts with RFC-1188, as well as with current
industry practice as typified at Interop91.

Still, the diagnosis is interesting, and the actual problem may be related.


Vernon Schryver,   vjs@sgi.com


-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 07:49:58 MDT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Telnet problems versus terminal emulation

In article <1992Jan28.233952.1226@ulrik.uio.no>, toreh@merkur.uucp (Tore Haraldsen) writes:
> In article <generous.696633160@nova> generous@sti.nasa.gov (Curtis Generous) writes:
>>We are running into some difficulty telneting to an IBM mainframe
>>from various workstations, namely IBM PC's.  Apparently, this host
>>sends a series of six 0x7f characters after each <CR><LF> (see hex
>>dump below; names have been changed to protect the stupid, huh I mean
>>innocent :-).
>>
 [some stuff deleted]
>>
>>Can anyone comment on this?  To me, just doesn't sound right, but I
>>have nothing to back my gut feeling; I somehow don't trust empty statements
>>made without back up, especially from people how only speak EBCDIC.  
>>
>>Can anyone point me to documents or references which could verify that 
>>statement?  Any help is appreciated.
>>
>>Thanks.
>>
>>--curtis
> 
> I have seen this functionality also on a DEC10 running Tops-10. It sort
> of dates your IBM host, this is oooooooooold stuff from the days when
> "network" meant a television broadcating corporation :-) ... and if you
> check out some flavours of unix termio, you may still find traces of it.
> BUT: it should be possible to tell your mainframe to send NULs instead
> of DEL (NULs were the default fill character under Tops-10).
> 
> - Tore Haraldsen
--------------------
	DEL is a control code, just like ^S/^Q, and it is a legal padding
byte. The problem is with your terminal emulator on the PC; it's broken.
My guess is your IBM host is trying to follow DEC specs for VT100's and add
plenty of time for the terminal to scroll its screen. Sensible for directly
connected VT100's on serial lines, not so for networks. If you want decent
VT100 and up emulation via Telnet then there are many choices. The commerical
products usually do a good job. Free, but not Public Domain, is MS-DOS Kermit
v3.11 (and shortly v3.12) which has built-in Telnet and more terminal emulation
than most people care to know about; the emulation quality is at or above the 
level of commerical ones. In the meanwhile Tore has a good suggestion.
        Joe D.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 02:17:24 GMT
From:      mpd@anomaly.sbs.com (Michael P. Deignan)
To:        comp.protocols.tcp-ip,news.newusers.questions
Subject:   Re: 1-900 SLIP Access

max@underg.UUCP (Max Cray) writes:

>service exists, or if there is a reason why is does not exist please send me 
>mail telling me why this is a bad idea? 

Because it would be outrageously expensive (at least .50 cents/minute) and
you can get a limited-access, normal-dialup SLIP account for about $100 per
month.

MD
-- 
--  Michael P. Deignan                      / 
--  Domain: mpd@anomaly.sbs.com            /   I'm not a bigot,
--    UUCP: ...!uunet!rayssd!anomaly!mpd  /    I hate everyone.
-- Telebit: +1 401 455 0347              / 

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 02:53:00 GMT
From:      kaplan@ivax.ccit.arizona.edu (Making memories)
To:        comp.protocols.tcp-ip
Subject:   Yo - Who owns the RFCs - can they be reproduced?

General questions:

	1) What rules govern the duplication and distribution of RFCs outside
	of the net?

	2) Who owns them and controls their copyright?

Specific questions:

	1)The U.S. chapter of DECUS has a Security SIG that is putting
	together a "secuirity resource guide" which will be sold to the
	society though the "DECUS store" (at the next Symposia - where
	they sell "session notes" and trinkets).  Can they reproduce RFC-1244
	and sell it along with their booklet?

	2) As a presenter for various not-for-profit, non-profit and profit
	making organizations, I give present all over the world.  As such, I
	have handout material.  I'd like to duplicate some of the RFCs and
	include them in the handout materials.  Is this possible?

	3) I have a commercial newsletter called Views on DEC that would like
	to make RFC-1244 (and others) available to those without
	net/printer-on-the-net access.  Can I reproduce some of them for sale?

RayK 8-)

Ray Kaplan - I know what I don't know
Computer Center					P.O. Box 42650
University of Arizona				Tucson, AZ  85733-2650
Tucson, AZ, 85751
(602) 621-2857	kaplan@ccit.arizona.edu - kaplan@arizrvax

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 03:44:47 GMT
From:      bussiere@garrot.DMI.USherb.CA (Luc Bussieres)
To:        comp.protocols.tcp-ip
Subject:   How could I configure a cisco to filter the output packets??

I'm trying to configure a cisco to filter the outgoing packet so that
all tcp packets for ports 1111 2150 6667 9165 are all rejected. I have
try doing this using the access-list command here is a list of the
access-list that I have implanted:

access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 1111
access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 2150
access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 6667
access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 9165
access-list 100 permit ip 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 

The problem is that all outgoing packets are rejected, what is
incorrect in this setup? How should I configure the cisco to filter
those packets?



-- 
Luc Bussieres ---- System Analyst - Dept. of Mathematics and Computer Sciences 
University of Sherbrooke     
Internet : luc.bussieres@dmi.usherb.ca
Tel: (819) 821-7981

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 09:17:32 GMT
From:      dyer@spdcc.com (Steve Dyer)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Looking for info on OSF/DCE

In article <33875@uflorida.cis.ufl.EDU> rmy@pacer.cis.ufl.edu (Rahim Yaseen) writes:
>i would appreciate it if anyone could let me know where i
>might be able to find a (detailed) description of
>OSF/DCE i.e., protocols, capabilities, portability, release
>dates (projected ?), etc.

There was an invited talk given at the Winter 1992 USENIX last week which was a
quick overview of the components of the DCE offering.  I think you can purchase
the slides of the invited talks from USENIX.

You can get more detailed info by contacting OSF directly.   OSF does give a
a 1-day course which is a technical overview of the product, and other more
detailed courses (Applications Development, Internals) are in development.


-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 10:55:10 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Need a telnet version that supports 3270 interface

The problem with tn3270 is that it's buggy, and the author doesn't
maintain it.

We use one developed by jmg@cernvax.cern.ch. Send him e-mail.
He's very receptive to bug reports.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 11:28:48 GMT
From:      lmn@z.amu.se (Lars Magnusson - teacher)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP to an old Xenix286 - Help.



Posting for a fellow teacher, so please reply to mailaddress  bok@z.amu.se.
-------

Having a Xenix 286, some 3-4 years old, we want to know if there
is any PD TCP/IP we can get up, running on this old bastard. We 
don't want to upgrade to a new Xenix, sinces it is for a test on 
a small, subsidary, educational center. We are to run telnet/popmail
from some PC's to the Xenix. The need is only to connect to a tcp-
port, no nfs (in short, a packetdriver/small portserver for Xenix).

Alternative, has anyone tried to "port" NCSA and Clarkson/similar to 
Xenix/Minix/Coherent (knows that's it's a large diff between a DOS-
and a "UNIX"-driver, but as an idea)?   Other tips ?

Replies to,
Bo Karlsson, bok@z.amu.se

----------------
(Mail please, we post replies if interest exist).



- Lars Magnusson (Dept. of Computing) : (EU)Net: lmn@z.amu.se    -
- AMU Jamtland                        : Tel.   : +46 63 14 56 00 -
- Box 603 ,  S-832 01 Froson,  Sweden : Fax    : +46 63 12 33 42 -
- A M U - Group  (National Employment Training Agency),   Sweden -

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 15:18:46 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Need a telnet version that supports 3270 interface

In article <BARNETT.92Jan29055510@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
|>The problem with tn3270 is that it's buggy, and the author doesn't
|>maintain it.

The author is no longer at Berkeley, last I heard.  IMHO Berkeley
could do a better job of maintaining it.  Last year I reported a bug and 
a fix via email, and it was one year to the day (talk about serendipity)
before anyone even got back to me about it.

|>We use one developed by jmg@cernvax.cern.ch. Send him e-mail.
|>He's very receptive to bug reports.

Yes, the author of this program is exceptional in his support.

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||          hughes@indiana.edu          ||
||        Indiana University         ||                                      ||
||   University Computing Services   ||   "The person who knows everything   ||
||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
||      Bloomington, IN  47405       ||                                      ||
||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
 \\==========================================================================//

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 17:00:19 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

karn@chicago.qualcomm.com writes:
> In fact BSD UNIX derivatives provide a shutdown() call that maps very
> nicely into TCP's half-close operations. If you say shutdown(s,1),
> you'll send a FIN on the connection but it will remain open
> indefinitely (in FIN-WAIT-2 state) for reading.

	OK, but why would you want to?  What do you gain by doing a
half-close that you wouldn't by closing both sides of the connection?  Do
you save any significant network bandwidth, or host resources, or get
improved performance or reliability, or what?  In other words, is
deliberately generating a half-closed connection something the tcp
architects decided was important for some applications and thus made sure
the protocol supported, or is it just happenstance that you can do that?
Are there actually any applications that use shutdown() instead of close(),
or their equivalents on other systems?
-- 
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!"

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1992 17:38:59 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How could I configure a cisco to filter the output packets??

In article <BUSSIERE.92Jan28224447@garrot.DMI.USherb.CA> bussiere@garrot.DMI.USherb.CA (Luc Bussieres) writes:
>I'm trying to configure a cisco to filter the outgoing packet so that
>all tcp packets for ports 1111 2150 6667 9165 are all rejected. I have
>try doing this using the access-list command here is a list of the
>access-list that I have implanted:
>
>access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 1111
>access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 2150
>access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 6667
>access-list 100 deny tcp 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 9165
>access-list 100 permit ip 132.210.0.0 0.0.255.255 0.0.0.0 255.255.255.255 
>
>The problem is that all outgoing packets are rejected, what is
>incorrect in this setup? How should I configure the cisco to filter
>those packets?

That looks correct, assuming you also want to reject any packets that
aren't from the 132.210 net.

What cisco release are you running?  Until a recent release (8.1, I think),
there was a problem if you tried to use access lists on an interface with
fast switching enabled.

You would probably be better off posting cisco-specific questions to
comp.dcom.sys.cisco.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 19:06:58 GMT
From:      bgi@stiatl.salestech.com (Brad Isley)
To:        comp.unix.i386,comp.protocols.tcp-ip
Subject:   When will ISC fix their SLIP?  Here's how to kludge it.

Someone here local to Atlanta heard that I had managed to get ISC's SLIP
to somewhat work with gated to function as a gateway between the Internet
and our local network.  Here's what I sent to him.  I thought someone
else might want to see it.  It's kind of cryptic, but everything is here.

Background - We got our news feed yanked because someone here though it was
better to hide his face in the sand after someone forged an inflammatory
posting by pulling the plug on our Usenet connections.  When we were finally
ready to come back on the air (after causing our neighbors much grief) our
feed told us to beat it.  So we switched to PSI.  The decision to use ISC
was based on the fact that it was what we had been using for a while.  Up
until this point we had been using pure dialup uucp and a WD8003 ethernet
to talk to our LAN.  We knew the TCP/IP from ISC was flaky (we're using
TCP/IP ver 1.2 with Unix 2.2.1).  Little did we know what we had in store
for us when I proceeded to try to connect to PSI with SLIP.

  What a nightmare!

Below is a solution that works - somewhat.  The machine crashes every
3 to 4 days.

-brad
---------------- cut here ------------

Here's the scoop - If you need to set up an Interactive system to answer
TCP uucp request, you need to call Multiuser Systems at 1-800-537-5324 and
ask for the paper by Parviz Afshar titled _How to Setup CU/UUCP on TCP/IP_.
This, of course, assumes that you're a Multiuser customer.  We dial into
Sun computers and a RS/6000 so we never set up a listner on an ISC box.
Sun and AIX are delivered with the listening service already on.
Run /etc/sldial and at the prompt manually dial the modem, then login.
After connection, press <ESC> to exit sldialup and leave it running.
Then run the /etc/ifc script.

Remember - ping will crash the system and LOTS of pings do NOT get routed
properly.  Telnet and FTP are much better for testing because the packets
get routed properly and it doesn't crash.  Dunno if 1.3 fixed this.

Interactive bundles routed's functionality in gated.

Also - Interactive does not support SLIP in conjunction with gated.  It has
been a known bug for well over a year.  If you run this, your system will
crash regularly.  Ours stays up for anywhere from 3-7 days at a stretch.

PS:  This works for ICS TCP/IP release 1.2 with ISC Unix 2.2.1.  Interactive
specifically told me that TCP/IP 1.3 did NOT fix the SLIP/gated bug.
They spiffed up the installation and supposedly eliminated some causes of
crashes.  Maybe 1.3 would help us, but I cannot get Steve to order the
measly $50 upgrade.

The /comtrol/... commands below are for hardware flow control.  Do whatever
you need to do in lieu of these commands.  This is for a Comtrol Ultra
multiport board.

If you have to dial the connection, don't put an infconfig entry in
/etc/netd.cf.  Installing slip will do it.  You'll have to comment it out.
The relevent portion of netd.cf is the last 6 lines.

Lemme know how it goes...

-later

---------   /etc/ifc   --------
set -x
tty=`cat /etc/slip.tty`
touch /usr/spool/locks/LCK..$tty
slattach /dev/$tty `cat /etc/slip.bps`
addr=`cat /etc/slip.addr`
#
# if you need a netmask
#
ifconfig sl0 $addr $addr netmask 255.255.0.0 up
#
# if you need no netmask
#
#ifconfig sl0 $addr $addr up
#
# Gateway and router combined - you need a netmask for this
#
gated -tu /usr/adm/route.log
#
# Turn on HW Flow Control
#
/comtrol/ultra/rtscts -y /dev/$tty # turn on hw flow ctl
route add default $addr 1
nohup routeadd $addr&
---------   /etc/netd.cf   --------
#	"@(#)_netd.cf	2.1	89/04/03"
#
# This is a configuration file for host-based
# TCP/IP using the wd ethernet interface
#

# open control streams for transport protocols
tcp = "/dev/tcp"
udp = "/dev/udp"

# open an IP stream for each transport protocol
ip_tcp = "/dev/ip" nsap 6       # bind stream to TCP protocol id
ip_udp = "/dev/ip" nsap 17       # bind stream to UDP protocol id

# open ARP for ethernet use
arp    = "/dev/arp" lsap 0x800

# open link level devices
wd_arp = "/dev/wd" lsap 0x806   # stream for ARP messages
wd_ip  = "/dev/wd" lsap 0x800   # stream for IP messages
loop   = "/dev/lo" lsap 0x800	# stream for loopback driver

# put it together
link ip_tcp under tcp
link ip_udp under udp

# names must not assume a unit number so use as part of name
link loop under ip_tcp name "lo0"
link arp under ip_tcp name "wd0"
link wd_arp under arp type 0x101
link wd_ip under arp type 0x1

# initial configuration of interfaces
ifconfig "wd0" stiatl netmask 255.255.0.0 up
#ifconfig "wd0" stiatl up
ifconfig "lo0" localhost up
#	@(#)_netd2.slip	1.1 		 89/07/13"
#
sl_ip  = "/dev/sl" lsap 0x888   # stream for IP messages
link sl_ip under ip_tcp name "sl0"
#ifconfig "sl0" stislp uupsi netmask 255.255.0.0 up
#ifconfig "sl0" stislp uupsi up
---------   /etc/routeadd   --------
for i in 1 2 3 4 5 6 7 8 9 10
do
    sleep 60
    route add default $1 1
done
---------   /etc/sldial   --------
tty=`cat /etc/slip.tty`
/etc/slset /dev/$tty &
/usr/ucb/sldialup $tty `cat /etc/slip.bps`
addr=`cat /etc/slip.addr`
echo "Current address is $addr"
echo "Be sure that the Current address matches the assigned address above from PSI."
echo "Edit /etc/slip.addr to change it if neccessary."
---------   /etc/slip.addr   --------
<you-slip-addr-which-will-be-the-same-on-both-ends>
---------   /etc/slip.bps   --------
9600
---------   /etc/slip.tty   --------
ttyu03
---------   /etc/slset   --------
/comtrol/ultra/rtscts -n $1 # turn off hw flow ctl
sleep 2
stty -parenb cs8 `cat /etc/slip.bps` < $1
stty -a < $1
#
# this is a prompt for to manually dial when you have no notes
#
# fill in the <>'s
#
echo "Dial <your-number> login <userid> passwd <passwd>; then slip then ESC"
---------   /usr/lib/uucp/Devices   --------
#
# T1600
ACU ttyu03,M - 9600 hayes \D
#
# TB 1600 direct
t1600 ttyu03 - 9600 direct
#
TLIS,eg tcp - - TLIS \D nls
TCP,eg tcp - - TLI \D nls
---------   /usr/lib/uucp/Dialers   --------
hayes	=,-,	"" \M\dATE1Q0X1\r\c\dAT\r\c OK\r \EATDT\T\r\c CONNECT \m\c
##########
# Changed re fax "UUCP over TCP/IP" from ISC - BGI 11.12.90
nls	""	""
# This is the original. (this doesn't work)
#nls	""	"" NLPS:000:001:101\N\c
---------   /usr/lib/uucp/Systems   --------
# SLIP connection
#		     |---- 0002 specifies Streams connection
#		     |   |---- 021c /etc/services port number on remote
#		     |   |   |---- xx.xx.xx.xx IP address to connect to
#		     |   |   |       |---- 16 zeros
#		     aaaappppiiiiiiii0000000000000000
system Any TCP Any \x0002021cxxxxxxxx0000000000000000 ogin: <userid> assword: <password>

-- 
    Itchy, Scratchy, Homer, Bart, Bugs, Elmer...  The list goes on and on.
                 They're so much more real than Congress...
-----------------------------------------------------------------------------
bgi@salestech.com           (404) 841-4169           Sales Technologies, Inc.

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 20:35:36 GMT
From:      jch@mitchell.cit.cornell.edu (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Need a telnet version that supports 3270 interface

> You did not specify what operating system you are using, but it sounds
> like you need the tn3270 source.  I downloaded it from:
>  
>   devvax.tn.cornell.edu
> 
> if I am not mistaken.

You may have gotten it from there, but devvax.tn.cornell.edu no longer
exists (I should know, since that uVAX is now in my lab).  I think the
"official" source for tn3270 is ucbvax.berkeley.edu although there
seems to be a copy on ftp.uu.net in the networking directory.

Jeff

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jan 1992 20:42:54 GMT
From:      bgi@stiatl.salestech.com (Brad Isley)
To:        comp.unix.i386,comp.protocols.tcp-ip
Subject:   Re: When will ISC fix their SLIP? Here's how to kludge it.

bgi@stiatl.salestech.com (Brad Isley) writes:

Oh, I forgot to say why this mess is here:

>---------   /etc/routeadd   --------
>for i in 1 2 3 4 5 6 7 8 9 10
>do
>    sleep 60
>    route add default $1 1
>done

Seems that when you start SLIP and add a default route, the system forgets
it after a few minutes.  This reminds enough that it eventually remembers.

Thank you, ISC, for such a wunnerful TCP/IP.   8-(
-- 
    Itchy, Scratchy, Homer, Bart, Bugs, Elmer...  The list goes on and on.
                 They're so much more real than Congress...
-----------------------------------------------------------------------------
bgi@salestech.com           (404) 841-4169           Sales Technologies, Inc.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 21:03:23 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan27.222759.12956@qualcomm.com> karn@chicago.qualcomm.com writes:
>
>In fact BSD UNIX derivatives provide a shutdown() call that maps very
>nicely into TCP's half-close operations. If you say shutdown(s,1),
>you'll send a FIN on the connection but it will remain open
>indefinitely (in FIN-WAIT-2 state) for reading.
>

Although shutdown() does allow for the closing of one side of a connection, I
was under the impression that once shutdown() was called, you could no longer
use read() on the file descriptor, thus making shutdown() without use.  Am I
right?

mb
---

-- 
Mark Boolootian		booloo@llnl.gov		+1 510-423-1948

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 92 22:46:47 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Looking for info on OSF/DCE

>There was an invited talk given at the Winter 1992 USENIX last week which was a
>quick overview of the components of the DCE offering.

And which spent about the same 3 minutes on the DFS that it spent on the
time protocol.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jan 1992 01:50:54 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   IP over JANET  [how long, oh lord...]

Below is offered in evidence of some "operational" problems I have
with current state of JIPS. I know IP is there, I have used FTP to
2 places in the home counties, and done talk with a (bemused) undergrad
in the AI department of Edinburgh University.

I accept that coverage within *.ac.uk is low. I do not accept that this
means basic DNS "glue" for the UK is uneccessary. Trying to find out on
spec who you can reach is impossible without more a priori information
than a typical (braindead) sysop like myself has to hand.

Why is this so? 

	-George

	Script started on Thu Jan 30 12:48:22 1992
	brolga%	nslookup
	Default Server:  uq.oz.au
	Address:  130.102.128.5
	> set type=NS
	> ac.uk.
	Server:  uq.oz.au
	Address:  130.102.128.5
	
	*** No name server information is available for ac.uk.
	> oz.au.
	Server:  uq.oz.au
	Address:  130.102.128.5
	
	oz.au	nameserver = mulga.cs.mu.OZ.AU
	oz.au	nameserver = munnari.OZ.AU
	oz.au	nameserver = dmssyd.syd.dms.CSIRO.AU
	oz.au	nameserver = ns.UU.NET
	oz.au	nameserver = nameserver.arc.NASA.GOV
	mulga.cs.mu.OZ.AU	inet address = 128.250.35.21
	mulga.cs.mu.OZ.AU	inet address = 192.43.207.2
	munnari.OZ.AU	inet address = 128.250.1.21
	munnari.OZ.AU	inet address = 192.43.207.1
	munnari.OZ.AU	inet address = 192.43.207.15
	dmssyd.syd.dms.CSIRO.AU	inet address = 130.155.96.1
	ns.UU.NET	inet address = 137.39.1.3
	nameserver.arc.NASA.GOV	inet address = 128.102.18.31
	>


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

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 92 04:16:11 GMT
From:      bob@snuffy.dracut.ma.us (Bob Smith)
To:        comp.protocols.tcp-ip
Subject:   Routing table thrashed using cslip

Here's the problem...

Sun 3/60, running SunOS 3.5...  cslip installed (with VJ header
compression)...  When I kill the running slip session the machines
routing table get's thrashed and the only way to recover is to
reboot the machine...  or I can try to restart slip in which case
the machine will panic and reboot for me! :-)

The exact same setup on a Sun 2/50 and on a Sun 2/120 doesn't
exhibit this problem...  Does it have anything to do with the
Lance ethernet chip the '60 uses ???

-- 
 \ Bob Smith         \ mx: bob@snuffy.dracut.ma.us
  \ 835 Mammoth Rd.   \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
   \ Dracut, MA. 01826 \ office && voice mail: +1 508 670-6712

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 92 20:18:27 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET  [how long, oh lord...]

In article <ggm.696736254@brolga>, ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
> Below is offered in evidence of some "operational" problems I have
> with current state of JIPS. I know IP is there, I have used FTP to
> 2 places in the home counties, and done talk with a (bemused) undergrad
> in the AI department of Edinburgh University.
>
> I accept that coverage within *.ac.uk is low. I do not accept that this
> means basic DNS "glue" for the UK is uneccessary. Trying to find out on
> spec who you can reach is impossible without more a priori information
> than a typical (braindead) sysop like myself has to hand.
>
> Why is this so?
>
> 	-George
>
> 	Script started on Thu Jan 30 12:48:22 1992
> 	brolga%	nslookup
> 	Default Server:  uq.oz.au
> 	Address:  130.102.128.5
> 	> set type=NS
> 	> ac.uk.
> 	Server:  uq.oz.au
> 	Address:  130.102.128.5
>
> 	*** No name server information is available for ac.uk.
> 	> oz.au.
> 	Server:  uq.oz.au
> 	Address:  130.102.128.5
>
>[listing of NS RRs for OZ.AU deleted]

There is no glue or SOA for AC.UK simply because AC.UK is not delegated.
What nslookup is telling you is true; the servers authoritative for the UK
domain do not delegate an AC.UK subdomain to other servers.  In other words,
the servers authoritative for UK contain all the RRs for names ending in
AC.UK also.  If a zone cut is made in a name space, it obviously has to be
made at a "boundary" between two labels (i.e., at a '.' dot).  However, there
is no rule that says that there *must* be a zone cut at *every* boundary.
That is purely up to the delegating authority.  The authority for UK decided
not to for AC.UK.  In fact, I don't think anything under UK is delegated.
The authority for AU did decide to do it for OZ.AU.

For another example, the authority for US delegates the state.US subdomains
to the same set of servers that serve the US domain.  One reason for doing
this is that there is a reasonable expectation that authority for these
subdomains will be delegated elsewhere at some time in the future, so it
would be easier to avoid having to split up a huge zone at that time by
maintaining several smaller zone files today.  Another reason is that it can
reduce the amount of data that needs to be transferred for an update.  For
example, for an update that adds an A RR for MUMBLE.INDPLS.IN.US, only the
IN.US domain needs to be transferred to propagate the information, not the
entire US domain.

So, the considerations for delegating authority fall in to two classes:
(1) you really want to give control of that chunk of the namespace to
another set of servers, as in the case of AU that delegates OZ.AU, or
(2) purely management considerations, as in the case of the US domain.
But in any case, you don't *have* to, and the British don't.

As to WHY the British don't delegate AC.UK, you will have to ask the British.
All of the JANET hosts are centrally registered; I suspect that this may have
something to do with it.  The UK domain is all theirs and they can do as they
please with it...

--
Jim Harvey, IUPUI Integrated Technologies Services-Technical Support/Networks
Internet: harvey@iupui.edu  uucp: {...}!iugate!harvey  BITNET: harvey@indyvax

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 92 15:25:25 GMT
From:      cudep@warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <116805@lll-winken.LLNL.GOV> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>Although shutdown() does allow for the closing of one side of a connection, I
>was under the impression that once shutdown() was called, you could no longer
>use read() on the file descriptor, thus making shutdown() without use.  Am I
>right?

It does mean you can no longer use read() on the descriptor, but I believe it
does mean that anything using read() on the other end will see an 'EOF' whilst
still allowing the other half of the connection to remain open.

Cheers,
-- 
\/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

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 92 19:02:11 GMT
From:      erik@marge.phys.washington.edu (Erik D. Olson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   POP3 Server & ka9q & WinQVTnet & the universe & everything

I decided to do a little learning about TCP/IP by writing a POP3 server
for ka9q nos.  I did it.  It works!  It conforms to the complete minimum
spec for POP3 as given by rfc 1225!  I can read mail using POPmail and
WinQVTNet just fine.  

BUT WinQVTNet won't SEND mail because my server doesn't support the
XTND XMIT command.  OK, fine, I'd love for the thing to support it,
but WHERE'S THE DOCUMENT FOR IT?!  The only rfc for XTND commands
I have seen is rfc 1082.  Anybody have any clues about this?  Is there
one in progress?  Is it undocumented but having source code somewhere?
Is there another news group that has discussions about it?

Thanks for any help,
  Erik Olson

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jan 1992 21:28:16 GMT
From:      logier@cheops.qld.tne.oz.au (Rob Logie)
To:        comp.protocols.tcp-ip,comp.protocols,tcp-ip.ibmpc,comp.protocols.tcp-ip.misc
Subject:   Re: os/2 lpr (PD)

peterd@tscc2.macarthur.uws.edu.au (Peter Degotardi) writes:

>Hi there,
>Does anyone know of a public domain lpr server for os/2 v1.x (& 2.0) ?
>How about tcp/ip in general for os/2 ? Are their any public-domain or
>shareware offerings available ? 
>--
>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.)

We are currently developing one for use with OS/2 & LanManager.  I don't
know if it will be public domain or not.  We developed it because we could
not find any other's that would work with the TCP/IP stack we are using.(3COM's)


-- 
Rob Logie                                    The opions expressed are mine alone
Telecom Australia                            and in no-way reflect the views or
TNE Computer Support Services                policy of Telecom Australia
EMAIL: logier@cheops.qld.tne.oz.au           "These are my opinions alone"

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jan 92 22:21:43 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 ?

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 wost segment, so the most cynical restrictions on the thin
co-ax have to be applied to the entire network.

You have to obey the so-called 3-4-5 rule on setting up your net
topology.  In short, you'd be OK if the thin co-ax net is only one
subnet away from the main.  The two can be attached through a hub.
HP makes an 8-port managable hub that includes thin, thick, and 8
TP ports.  Attach the thin net to the thin port on the hub, then
use a standard drop cable and transciever tap on the back-bone.
The 8-port hub costs us under $400 in quantity.

Bill

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

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 92 23:20:05 GMT
From:      davida@haight.West.Sun.COM (David Auerweck - Sun San Francisco SE)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   rfc1001 & 1002 (netbios over tcp)

Howdy,
I am looking for public domain implementation of 
rfc 1001 & 1002. These two rfcs spec out a 
netbios implementation over tcp-ip transport. 
I particularly would like a version for SunOS. 
Anybody willin' to share thier work? 
Thanks !

--
    
     /\
    \\ \
   \ \\ /     David L. Auerweck		SUN:      david.auerweck@West

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 92 23:22:04 GMT
From:      ce1zztw@prism.gatech.EDU (Tommy Barr)
To:        comp.protocols.tcp-ip
Subject:   Data-Link Level ?


   Hello everyone,  I would like to do something but need some help getting
 started.  I would like to obtain information from the Ethernet header from
 all packets passing through my interface.  More specically, I would like
 to read the Destination and Sorce addresses as well as the sequence number
 from all tcp packets going through my interface.  Not only those addressed
 to me.  This would be done within an application thus Suns etherfind and
 IBM's iptrace are not suitable.  How do these (etherfind and iptrace) obtain
 this type of information.  Is it done with sockets?  Is it as easy as
 creating sockets, binding them to well known ports such as telnet and ftp etc.
 and read() the datagrams.  I have Stevens book and it is very helpful, however
 it seems to stop at the lower levels.   Are the methods of obtaining
 made with some real low level hardware calls.  I have also pondered the
 idea of creating a new device or socket to do this but it is new to me.

 I would just like to read this information from within an application
 and buffer it.  Maybe have two concurrent process going at once. One 
 reading the datagrams and another one using this information.   Before I 
 ramble on too much.... 

 I just was looking for some tips on getting started.  In summary I want
 to read the Ethernet headers of packets not neccessaryl addresed to me.

 I have access to most platforms of hardware (Sun, HP, Apollo, IBM rs, etc.)   

   Please respond via Email or Posting.

    Thank's for any clues,  Tommy Barr ce1zztw@prism.gatech.edu 
-- 

Tommy Barr (404)894-2260           ce1zztw@prism.gatech.edu


-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 92 00:06:02 GMT
From:      brunner@practic.com (Thomas Eric Brunner)
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:

[following up a posting by William Roberts on ARP hardware types]


>The ARP hardware type code required by RFC-1188 for FDDI is the same as
>that for ethernet, 1.  In early days, it was proposed to use the 802
>number, 6, but that was changed at the BOF at InterOP-90 (or 89?).  There
>are words in RFC-1188 justifying the change.

I recollect that it was at the 89 BoF, my memories of the '90 ring are the
"which version of SMT" shall be used, one step up the protocol stack and a
step to the side. I can't remember anything _intersting_ from last October,
the rings worked and I paid off my bet ($1).

The passage of interest in 1181 occurs at the top of page 4:

   The ARP protocol has several fields that parameterize its use in any
   specific context [2].  These fields are:

      hrd   16 - bits     The Hardware Type Code
      pro   16 - bits     The Protocol Type Code
      hln    8 - bits     Octets in each hardware address
      pln    8 - bits     Octets in each protocol address
      op    16 - bits     Operation Code

   The hardware type code assigned for IEEE 802 networks is 6 [13].  The
   hardware type code assigned for Ethernet networks is 1 [13].
   Unfortunately, differing values between Ethernet and IEEE 802
   networks cause interoperability problems in bridged environments.  In
   order to not preclude interoperability with Ethernets in a bridged
   environment, ARP packets shall be transmitted with a hardware type
   code of 1.  Furthermore, ARP packets shall be accepted if received
   with hardware type codes of either 1 or 6.


>The current good practice is to send 1, but accept both 1 and 6.

That's certainly how I read "shall" in the sense of rfc1122 conventions.


-- 
#include <std/disclaimer.h>
Eric Brunner 4bsd/RT Project
uucp: uunet!practic!brunner or brunner@practic.com
trying to understand multiprocessing is like having bees live inside your head.

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 92 01:00:47 GMT
From:      scott@labtam.labtam.oz.au (Scott Colwell)
To:        comp.protocols.tcp-ip
Subject:   Looking for references on how TCP/IP is encapsulated over 802.5 token ring

I am involved in a project that includes running tcp-ip over 802.5 token ring
(IBM token ring) and I need some references on how it is encapsulated and
how things like arp work etc.  We need to be able to interwork with RS6000s.

Is the encapsulation done according to RFC 1042 with connectionless LLC
and SNAP headers?
Is IBMs emphasis on connection oriented LLC due to SNA using this mode ?

We have the IEEE standards and the above RFC. I have also obtained the IBM
Token-Ring Network Architecture Reference which explains much of the lower level
stuff but does not talk at all about tcp-ip.

p.s. what is the latest version of 802.2 ?

Thanks,

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

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 02:23:33 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

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.

In the absense of a high degree of IP penetration into the UK, that seems
a shame. I do not wish to return to the days of hosts.txt.

It would be MOST USEFUL if the JIPS team would provide some DNS coverage
at this level, including .co.uk. 

Does anybody agree?

	-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

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 05:07:02 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET  [how long, oh lord...]

	George. ac.uk is not a seperate zone from the uk. There is no
	requirement to delegate out at each level of the DNS. you only
	need a new zone when you delegate authority for a sub domain
	that you will not control.

	There are no name servers listed for ac.uk because all the
	relevent information is in the uk zone.

	Mark.

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 92 11:44:50 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.696736254@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
   Below is offered in evidence of some "operational" problems I have
   with current state of JIPS. I know IP is there, I have used FTP to
   2 places in the home counties, and done talk with a (bemused) undergrad
   in the AI department of Edinburgh University.

   I accept that coverage within *.ac.uk is low. I do not accept that this
   means basic DNS "glue" for the UK is uneccessary. Trying to find out on
   spec who you can reach is impossible without more a priori information
   than a typical (braindead) sysop like myself has to hand.

   Why is this so? 

The reason for the current situation is bureaucratic: funding for a
machine to act as the primary nameserver for the .ac.uk domain was
only obtained a few months ago. Until this DNS box becomes fully
operational, the present ad-hoc arrangements will have to suffice.
Hopefully, this box will be up and running Real Soon Now.

There also has to be some understanding with the other UK IP service
provider UKnet so that they act as secondary servers to each other and
also manage the .uk namespace effectively. This has been agreed in
principle but has still to be worked out operationally.

There is a further problem for JANET sites in deploying DNS. They have
to provide some form of compatibility with NRS names so that the JANET
community who are stuck with coloured book protocols don't see names
that break their mailers or confuse their end-users.

From your perspective, the complaint is justified. However you should
appreciate that this problem (and others) are being worked on.
Everyone working on JIPS is determined to provide as good an IP
service as possible. When you consider the funding and resource
constraints that JIPS has to contend with - as well as the *real*
hassles of "backwards compatibility with Coloured Books" - it's
remarkable that so much has been done already. [A year ago, JIPS only
existed on paper and funding for routers had not been obtained.]

The bulk of the work in establishing JIPS has come from *voluntary*
effort. Instead of jeopardising that goodwill by public criticism,
please contact the JIPS manager - Bob Day (r.a.day@jnt.ac.uk) - about
any failings or problems concerning the JANET IP Service.

		Jim

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 92 12:06:48 GMT
From:      cudep@warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET  [how long, oh lord...]

In article <ggm.696736254@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
>Below is offered in evidence of some "operational" problems I have
>with current state of JIPS. I know IP is there, I have used FTP to
>2 places in the home counties, and done talk with a (bemused) undergrad
>in the AI department of Edinburgh University.
 
>I accept that coverage within *.ac.uk is low.

So far.

> I do not accept that this
>means basic DNS "glue" for the UK is uneccessary. Trying to find out on
>spec who you can reach is impossible without more a priori information
>than a typical (braindead) sysop like myself has to hand.

No RFCs state that you must delegate each domain at all points (though
there are some technically good reasons for doing so, specially close
to the root).
Quite simply the information for ac.uk, co.uk and all other immediately
subordinate domains in under uk are not delegated yet.

>Why is this so? 

Historical and political reasons abound, but more recently, with the advent
of JIPS and the UKnet services, this is due to change.  The reason it
hasn't already been done is making sure we do it right, and have the
resource to run it well.  It won't be long before it happens now,
though I don't know an official date.

Cheers,
-- 
\/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

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 92 14:13:47 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.696824613@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
>absense of suitable delegations  means people outside cannot "browse"
>the DNS to find connected hosts.

Yeah, but strictly speaking why should you need to browse ?  If
someone advertises their machine for access, ten to one they'll
also give you the IP address.  If you want to know at this stage
if a site is connected, why not mail them and ask ?

>It would be MOST USEFUL if the JIPS team would provide some DNS coverage
>at this level, including .co.uk. 

You have to appreciate that the JIPS is in its infancy.  The pilot
project only became a service last November, and we're still building
up the service.  There are a lot of things that would be `MOST USEFUL'
to do - we're working on them.  As it happens, .ac.uk. should soon
be delegated.

Dunc

Note that nothing above is to be taken as an official statement about
the JIPS - these are purely my own personal comments.

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 16:48:07 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing table thrashed using cslip

In article <1992Jan30.041611.249@snuffy.dracut.ma.us> bob@snuffy.dracut.ma.us (Bob Smith) writes:
   When I kill the running slip session the machines routing table
   get's thrashed and the only way to recover is to reboot the
   machine...

It sounds like you're running routed, which isn't as smart as it
thinks it is about intermittent point-to-point links.  Either (1)
don't start routed and use static routes instead, or (b) mark the
intermittent links as `passive' in /etc/gateways, or (III) use gated,
which is more configurable and can use protocols that are smarter than
RIP about describing network topologies that include point-to-point
links.  Alternatively, (D) use a SLIP that always has the interfaces
ifconfig()d `up', even when the modem is hung up, so neither routed or
gated nor any of the applications can discover the physical link
state.

   ...or I can try to restart slip in which case the machine will
   panic and reboot for me! :-)

That's a different problem, perhaps evidence of a bug in your SLIP
implementation.  It's certainly always a danger whenever you have too
much protocol-specific smarts inside your kernel.

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 92 17:12:24 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.696824613@brolga> 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.

The delegation of zones within the .ac.uk. domain will begin once a
full-blown UK DNS is fully operational. Each JIPS site will have the
choice of taking responsibilty for its own zone or else letting it be
managed for them by JIPS.

   In the absense of a high degree of IP penetration into the UK, that seems
   a shame. I do not wish to return to the days of hosts.txt.

Nor does anyone else. What makes you think JIPS does?

   It would be MOST USEFUL if the JIPS team would provide some DNS coverage
   at this level, including .co.uk. 

It's going to happen, so just be patient. The people who work an JIPS
are well aware of the present limitations and are working to remove
them. You must also appreciate that direct Internet access is a new
experience for the UK and a lot of catching up has to be done wrt
routing, DNS and so on. There isn't a wealth of UK expertise in these
areas - yet. 

FWIW, the .co.uk. domain will be delegated to UKnet, the commercial IP
service providers in the UK. You can count their IP customers on the
finger of one hand, so don't expect miracles there either.

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 :-).....]

		Jim

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 19:56:54 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing table thrashed using cslip

In article <BOB.92Jan31114758@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> In article <1992Jan30.041611.249@snuffy.dracut.ma.us> bob@snuffy.dracut.ma.us (Bob Smith) writes:
>    When I kill the running slip session the machines routing table
>    get's thrashed and the only way to recover is to reboot the
>    machine...
> 
> It sounds like you're running routed, which isn't as smart as it
> thinks it is about intermittent point-to-point links.  Either (1)
> don't start routed and use static routes instead, or (b) mark the
> intermittent links as `passive' in /etc/gateways, or (III) use gated,
> which is more configurable and can use protocols that are smarter than
> RIP about describing network topologies that include point-to-point
> links.  Alternatively, (D) use a SLIP that always has the interfaces
> ifconfig()d `up', even when the modem is hung up, so neither routed or
> gated nor any of the applications can discover the physical link
> state.
> ....


Or run a routed that is not broken.

(many use SLIP and RIP around here.)


Vernon Schryver,   vjs@sgi.com


-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 92 20:58:32 GMT
From:      dank@blacks.jpl.nasa.gov (Dan Kegel)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: POP3 Server & ka9q & WinQVTnet & the universe & everything

erik@marge.phys.washington.edu (Erik D. Olson) writes:
>I decided to do a little learning about TCP/IP by writing a POP3 server
>BUT WinQVTNet won't SEND mail because my server doesn't support the
>XTND XMIT command.  OK, fine, I'd love for the thing to support it,
>but WHERE'S THE DOCUMENT FOR IT?!  The only rfc for XTND commands
>I have seen is rfc 1082.

One POP server that supports it is UCB's popper, which
is  available  via  anonymous   ftp   from ftp.CC.Berkeley.EDU 
(128.32.136.9, 128.32.206.12).  

The code that implements the behavior after XTND XMIT is the following:

/*
 * Copyright (c) 1989 Regents of the University of California.
 * All rights reserved.  The Berkeley software License Agreement
 * specifies the terms and conditions for redistribution.
 */

#ifndef lint
static char copyright[] = "Copyright (c) 1990 Regents of the University of California.\nAll rights reserved.\n";
static char SccsId[] = "@(#)@(#)pop_xmit.c	2.1  2.1 3/18/91";
#endif not lint

#include <stdio.h>
#include <sys/types.h>
#include <sys/file.h>
#include <sys/wait.h>
#include "popper.h"

/*
 *  xmit:   POP XTND function to receive a message from 
 *          a client and send it in the mail
 */

pop_xmit (p)
POP     *   p;
{
    FILE                *   tmp;                    /*  File descriptor for 
                                                        temporary file */
    char                    buffer[MAXLINELEN];     /*  Read buffer */
    char                    temp_xmit[MAXDROPLEN];  /*  Name of the temporary 
                                                        filedrop */
    union   wait            stat;
    int                     id, pid;

    /*  Create a temporary file into which to copy the user's message */
    (void)mktemp((char *)strcpy(temp_xmit,POP_TMPXMIT));
#ifdef DEBUG
    if(p->debug)
        pop_log(p,POP_DEBUG,
            "Creating temporary file for sending a mail message \"%s\"\n",
                temp_xmit);
#endif DEBUG
    if ((tmp = fopen(temp_xmit,"w+")) == NULL)
        return (pop_msg(p,POP_FAILURE,
            "Unable to create temporary message file \"%s\", errno = %d",
                temp_xmit,errno));

    /*  Tell the client to start sending the message */
    pop_msg(p,POP_SUCCESS,"Start sending the message.");

    /*  Receive the message */
#ifdef DEBUG
    if(p->debug)pop_log(p,POP_DEBUG,"Receiving mail message");
#endif DEBUG
    while (fgets(buffer,MAXLINELEN,p->input)){
        /*  Look for initial period */
#ifdef DEBUG
        if(p->debug)pop_log(p,POP_DEBUG,"Receiving: \"%s\"",buffer);
#endif DEBUG
        if (*buffer == '.') {
            /*  Exit on end of message */
            if (strcmp(buffer,".\r\n") == 0) break;
        }
        (void)fputs (buffer,tmp);
    }
    (void)fclose (tmp);

#ifdef DEBUG
    if(p->debug)pop_log(p,POP_DEBUG,"Forking for \"%s\"",MAIL_COMMAND);
#endif DEBUG
    /*  Send the message */
    switch (pid = fork()) {
        case 0:
            (void)fclose (p->input);
            (void)fclose (p->output);       
            (void)close(0);
            if (open(temp_xmit,O_RDONLY,0) < 0) (void)_exit(1);
            (void)execl (MAIL_COMMAND,"send-mail","-t","-oem",NULLCP);
            (void)_exit(1);
        case -1:
#ifdef DEBUG
            if (!p->debug) (void)unlink (temp_xmit);
#endif DEBUG
            return (pop_msg(p,POP_FAILURE,
                "Unable to execute \"%s\"",MAIL_COMMAND));
        default:
            while((id = wait(&stat)) >=0 && id != pid);
            if (!p->debug) (void)unlink (temp_xmit);
            if (stat.w_retcode)
                return (pop_msg(p,POP_FAILURE,"Unable to send message"));
            return (pop_msg (p,POP_SUCCESS,"Message sent successfully"));
    }
 
}
--
- Dan Kegel (dank@blacks.jpl.nasa.gov)
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 20:59:53 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting out of FIN-WAIT-2

In article <1992Jan29.170019.6259@phri.nyu.edu>, roy@alanine.phri.nyu.edu (Roy Smith) writes:
|> 	OK, but why would you want to?  What do you gain by doing a
|> half-close that you wouldn't by closing both sides of the connection?  Do
|> you save any significant network bandwidth, or host resources, or get
|> improved performance or reliability, or what?  In other words, is
|> deliberately generating a half-closed connection something the tcp
|> architects decided was important for some applications and thus made sure
|> the protocol supported, or is it just happenstance that you can do that?
|> Are there actually any applications that use shutdown() instead of close(),
|> or their equivalents on other systems?

Half-closed connections are a deliberate feature of TCP. There are
many cases where they're useful, especially in allowing applications
to close more gracefully than they might otherwise if a close simply
chopped both paths simultaneously. For example, a client can do the
logical equivalent of a "UNIX shell ^D" (i.e., send a FIN and go into
FIN-WAIT state) and the server on the other end can send a signoff
message with some reasonable assurance that it got back to the client
before it too closes its side of the connection. It's relatively simple
and quite elegant.

Phil


-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 22:06:53 GMT
From:      jra@lawday.DaytonOH.NCR.COM (John R. Ackermann x2966)
To:        comp.protocols.tcpip,comp.dcom.lans
Subject:   POP Clients -- Windows and NDIS compatible?


We're trying to determine if POP is a viable means of distributing email
to the PC users on our 10base-T LAN.  We have a Unix machine on the LAN
which is our local mail machine, and a number of PC servers running LAN
Manager (OS/2).

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

Is there a Windows POP client that will use NDIS drivers, or
alternatively a way to make the Clarkson driver work with NDIS?

Thanks...


-- 
John R. Ackermann, Jr.        Law Department, NCR Corporation, Dayton, Ohio
(513) 445-2966		      John.Ackermann@daytonoh.ncr.com
Packet Radio: ag9v@n8acv      tcp/ip: ag9v@ag9v.ampr [44.70.12.34]

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 22:42:26 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

marka@syd.dms.CSIRO.AU (Mark Andrews) writes:

>	George. ac.uk is not a seperate zone from the uk. There is no
>	requirement to delegate out at each level of the DNS. you only
>	need a new zone when you delegate authority for a sub domain
>	that you will not control.

Sorry, but I think this is utter bullsh. ac.uk and co.uk and mod.uk are
extremely distinct sub-domains of .uk -and in any case, several mail messages
and followups make it plain a ac.uk delegation is coming soon.

>	There are no name servers listed for ac.uk because all the
>	relevent information is in the uk zone.

Again, This is simply NOT true. I suspect "relevancy" is in the eye of
the beholder.

-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

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jan 1992 22:44:39 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over JANET [how long, oh lord...]

duncan@transition.mhs-relay.ac.uk (Duncan Rogerson) writes:
       ^^^^^^^^^^
A reference to "migration implies you can come back: transition is for ever?"

>In article <ggm.696824613@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
>>absense of suitable delegations  means people outside cannot "browse"
>>the DNS to find connected hosts.
>
>Yeah, but strictly speaking why should you need to browse ?  If
>someone advertises their machine for access, ten to one they'll
>also give you the IP address.  If you want to know at this stage
>if a site is connected, why not mail them and ask ?

There is a 9-11 hour timelag betwixt JANET and here. I regard 1 working
day turn-around for response to this kind of query as woefully slow. IP
is a "gimme now" network. You don't hassle somebody for info, you go and
find it out yourself.

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.

The whole point of the DNS and /dig/nslookup is that you can "walk" around
the delegations, and find out for yourself without having to hassle
people. My memories of pre-NRS lookup days, when you had to find the
regional NRS contact, ask to see the most recent listings of the data
from SALFORD, decrypt it, find it was wrong, go back (recurse recurse...)
are not good. 

>>It would be MOST USEFUL if the JIPS team would provide some DNS coverage
>>at this level, including .co.uk. 
>You have to appreciate that the JIPS is in its infancy.  

I beg to submit the gestation time was somewhat elephantine.  

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

>There are a lot of things that would be `MOST USEFUL'
>to do - we're working on them.  As it happens, .ac.uk. should soon
>be delegated.

Smashing! I look forward to it.

I apologize if I'm being a thorn in the flesh of those JIPSoids doing
the work under pressure. Like many others, I am immensly keen to see
false barriers into the uk eroded once and for all. 17,000 or so new IP
hosts to play with is a tempting feast!

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

	-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

END OF DOCUMENT