The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for October 1991 (434 messages, 261631 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/10.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 Oct 91 00:39:43 GMT
From:      kessler@hacketorium.Eng.Sun.COM (Tom Kessler)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets


>Sun/AT&T helped solidify this with their abysmal implementation of
>TLI in SunOS 4.1 (and their statement that all new applications
>were supposed to written to TLI).  Berkeley also helped solidify

Just to set the record straight there was an error in the SunOS release
4.1 documentation on TLI that implied all new applications should be
written to the TLI interface.  

In our next major release (Solaris 2.0) and in all subsquent releases for 
the forseable future, we will be supporting BOTH the TLI and sockets 
interface on an equal basis. We encourage our customers to use whichever 
interface to the networking code makes the most sense for them.  Where 
portability is an issue, it certainly makes a lot of sense to stick with 
sockets in your application programs.

--Tom Kessler
SunSoft Internet Engineering Group

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 01:07:49 GMT
From:      jra@lawday.DaytonOH.NCR.COM (John R. Ackermann)
To:        comp.sys.ncr,comp.sys.att,comp.protocols.tcpip,comp.sources.wanted,comp.unix.programmer
Subject:   POP2 for System V?

Help!  I'm trying to find a POP2 server that works on SysV machines.
I've got the pop2d package from (I think) Berkely, but it's purely BSD
and even after doing the best I can to straighten out the include files,
it still makes my compiler unhappy with some unknown definitions.

Can anyone point me in the right direction?  To be specific about the
implementation, it's SVR3 with WIN-TCP (using the WIN socket library).

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]

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 06:34:26 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert to legitimate network address

In article <01GB2XEZ025C000NRS@utrcgw.utc.com>, NEWKIRK@hsdwl.utc.com writes:
>  ...
>     Our current thoughts are to use a simple 255.255.255.0 subnet mask
> and perhaps start with Domain Name services.  But that's about where the
> ideas stop and speculation begins.  A wholesale replacement of bridges
> with routers isn't reasonable ($$), and a "midnight address-changing
> party" is sadistic.  In a nutshell, the overall need is for an orderly
> transisition from the old to the new....


Why not borrow a single workstation for a few weeks or months (you
better hope not years) and make it a gateway between your old class A and
the new class B?  Don't tell it anything about your subnet mask; just let
it route between two networks.  Physically, this router would be connected
only to your familiar cable plant.  You might get by with a single physical
interface, but it's probably simplest to stuff a second ethernet card
into the machine, hook it to the network, and turn on RIP and ipforwarding.

Then you can gradually convert small parts of your network and individual
hosts to the new numbers.  As things are converted, the traffic thru this
router will rise and then fall.  If necessary, you can use the wonders of
RIP "statistical" ("stochasitic"?) load balancing and use two or more such
temporary routers.  For a while, a lot of packets will see the same cable
twice, but most ethernets are in fact not bandwidth limited.

You may see minor oddities with broadcast packets, but nothing to worry
about during the temporary duration of the scheme.

I wrote "workstation" because you won't need it forever and probably don't
have enough "real," permanent routers for your new class-C-subnets.
(Besides, others have noted that a certain solar workstation outfit has a
larger installed base of "routers" than all of the "real router" vendors
combined.)  (That my employer sells workstations with network code I've
played with could not possibly be a factor.)

You can make cheap PC's into routers of varying power, perhaps enough for
such a use.


I've seen this done more than once, and done it more than once, both to
convert from illegal numbers, and to convert among legal numbers.  I've
done it on networks with hundreds of hosts.  It's far easier (read
"possible") than "big bang" conversions.


Vernon Schryver,   vjs@sgi.com

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 11:20:13 GMT
From:      PMW1@psuvm.psu.edu (Peter M. Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: UNSUBSCRIBING

In article <9109271420.AA01393@telesys.ncsc.navy.mil>,
mark@TELESYS.NCSC.NAVY.MIL (Williams) says:


>   Coordinator: Vivian Neou <Vivian@NIC.DDN.MIL>
>                            (415) 859-4781

I've check the Finger and SMTP VRFY/EXPN for vivian -- she doesn't
seem to have an account.  VRFY postmaster produced sysadm@nic
(which I would assume to be sysadm@nic.ddn.mil).

/Pete

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 12:38:24 GMT
From:      ipcmvm@suc1a.harris.com. (Michael Marrone)
To:        comp.protocols.tcp-ip
Subject:   SLIP - Where to get Information


     We are thinking of using SLIP in the very near future.  Unfortunately,
we have little info on it, except word of mouth.  Can someone tell me where
I can get some info on SLIP?

     Also, I've been seeing posts about PPP and comparisons between the two.
Is it similar?  (we are trying to network some machines over the phone lines
with software originally written for TCP-IP (which we don't feel like modifying)
but in a place with no ethernet connections.  We want to use SLIP inbetween
the software and the outside world, so our inhouse software won't know the
difference.)  Aside from any info, does SLIP sound like it would do the job?

Thanks in advance...
Mike Marrone

--
Don't you hate Mondays (and Tuesdays and Wednesdays and Thursdays,
and Friday mornings)?
ipcmvm@suc1a.harris.com

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 13:19:03 GMT
From:      remde@NCRONS.STPAUL.NCR.COM (Kevin Remde)
To:        comp.protocols.tcp-ip
Subject:   Re: Unsubscribe me please!!!

> 
> Please, Please remove me from the mailing list.
> I have sent several messages to tcp-ip-request@nic.ddn.mil and
> tcp-ip-request@nisc.sri.com. But, nobody has cared so far.
> 
> Thanks very much,
> Veera Prakash <prakash@sme.siemens.com>
> 
> 
Me too!!!
 Kevin Remde
 remde@ncrons.stpaul.ncr.com

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 14:26:07 GMT
From:      James_Yven.Herndon@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: unsubscribe

unsubscribe

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 14:52:16 GMT
From:      ja@dvnspc1.Dev.Unisys.COM (Jak Amado)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP over ISDN

I am investigating uses of TCP-IP over ISDN. Regarding this subject, I am
looking for information on any:
   - RFC
   - implementation
   - study
   - standard
   - draft standard
   - work under way
   - justification, market analysis
   - ideas, thoughts, bits of thoughts
   - etc.

To judge from the titles in the RFC index (as of August '91, i.e. up to
RFC 1243), there doesn't seem to be any RFC related to ISDN. Did I miss any?

Thanks in advance for any help on this subject.

Jak Amado
Staff s/w engineer
Unisys
P.O. Box 1874
Southeastern, PA 19398-1874  
USA
Tel: (215) 341-4708
Fax: (215) 975-3994

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 15:31:25 GMT
From:      HENRYM@SACUSR.MP.USBR.GOV
To:        comp.protocols.tcp-ip
Subject:   All of these UNSUBSCRIBE requests


People,
	A couple of days back, Mark Williams gave an excellent commentary
on the recent problems with a number of network users wishing to unsubscribe
to teh TCP-IP mailing list.  I would like to add a couple of points.

	First, as Mark mentioned, the proper method for addressing subscriptions
and problems for virtually every mailing list that I am aware of is to send
the message to: [mailing-list]-REQUEST@whatever-internet-host.whatever.dom.
Some people have been complaining that they have received to action.  It
is possible, however unlikely, that some messages have gotten lost, and I'll
go into that more, later.

	Secondly, some individuals have flooded the regular list with flames
about not getting off the list.  Many times.  Really, people, what do you
hope to accomplish by this?  Antognize many other people on the list with
this junk mail?  You've succeeded!  If there have been problems with getting
off the list in a timely manner, doesn't your mail reader have a DELETE
function?  Mine does, and believe me, I've used it a lot in the past few
days.

	Thirdly, are you sure your mail is being sent directly from the NIC,
or is it coming from a local mail exploder?  Many institutions employ
this method to cut down on Internet traffic, and attempt to administer some
control on the kind of mail traffic entering their domain.  Check with your
host administrator.

	Fourth, why don't you try contacting the list administrator directly
via email or phone?  Typically, the day-to-day functions of maintaining
the list are handled by the operations staff during times of lower activity.

	Fifth, in case you aren't aware of it, SRI has lost the NIC contract
to another agency, and the SRI group has been very busy the past few weeks
with coordinating the transfer of authority of the various databases and
document archives that the NIC is tasked to maintain.  There are other
situations involved, too, that I am not at liberty to disclose.

	So, people, please start exercising a little common sense and
courtesy.  It's bad enough with all the subscripton messages flying
to the entire list, but it has been more than enough with the juvenile
flaming that has followed.  It's been a LONG, LONG time since I gotten
into a flame war on the net, in fact it was the ARPANET back then, but
I have had it.  Give the folks some time.  With all the changes happening,
it's going to take a few weeks for all the dust to settle.  At least, in
the end, it will be easier to get off the list than some of the USPS mass
mailings!

	The above opinions are my own, as a former SRI-NIC employee, and not
necessarily those of my current employers.

-HWM
----------
Henry W. Miller
Assistant Systems Manager, Mid Pacific Region
U.S. Bureau of Reclamation
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS 460-5108
Inet:	"henrym@sacwms.mp.usbr.gov"
BITNET:	"hmiller@scu"

"Bad guys abuse public land, good guys save it."

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 15:50:27 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Unsubscribe me please!!!

Well, NIC.DDN.MIL and all of its services move to a different host and
company now.  Perhaps "minor" things like mailing-list maintenance and
so on had a low priority during the transition, and will work better now.

BillW
-------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 16:39:43 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Backups using rsh.


    Why don't all distributed filesystems simply use TCP/IP for data
    communication?

With any luck, we and Interstream (at least) will be demonstrating NFS over
TCP at Interop.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 16:42:08 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Williams)
To:        comp.protocols.tcp-ip
Subject:   SRI-NIC

Jim Solomon writes:

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

Just one stupid question:

>   The NIC has taken over the responsibility for the periodic update of the
>   TCP-IP implementations (the latest update can be obtained via FTP by
>   ANONYMOUS login from SRI-NIC file NETINFO:VENDORS-GUIDE.DOC).  We are

What is the actual name of the host containing this information?


And a not-so-stupid one:  is there source code for TCP/IP available that:
1)  Is not intended to be kernel resident;  and
2)  Has some reasonable comments in it?

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

I thought I'd put the answer on the net, in case anyone else was curious.
First, sri-nic is really nic.ddn.mil, which is a Sun of some kind running
SunOS 4.1.  Its ip address is 192.112.36.5 and it has all kinds of interesting
stuff on it.  A list of the contents of the netinfo subdirectory is at the end
of this message.

And, to show my capabilities, let me tell you that I can't answer the not-so-
stupid question (see, I thought the first question wasn't stupid, either.
Hmmm.)  Anyway, Jim, you probably need to specify what OS you're looking for.

And now, from NIC.DDN.MIL, the NETINFO subdirectory...

00netinfo-index.txt
alternate-domain-procedure.txt
alternate-domain-template.txt
asn-template.txt
asn.txt
blacker.doc
c30e-interface-guide.doc
domain-contacts.txt
domain-info.txt
domain-template.txt
domains.txt
foreign-tac-phones.txt
fyi-index.txt
hadminbyaddr.txt
host-location.txt
hosts.txt
hosts.txt-Z
hosts.version
hostserver-instructions.txt
ien-index.txt
ihost-template.txt
in-addr-template.txt
interest-groups.txt
internet-number-template.txt
kermit-info.txt
kermit-nicserver.txt
kermit-tac-info.txt
lost+found
mil-config.txt
mil-host-administrators-a-l.txt
mil-host-administrators-m-z.txt
mil-hosts.txt
mil-mailbridge-homings.txt
mil-nsc-template.txt
mil-nsc.txt
mil-psn-coord.txt
mil-tacacs-instructions.txt
network-contacts.txt
networks.txt
nic-pubs.txt
nsc-hadmin-duties.txt
nug.doc
nug.ps
protocols-dod.bib
protocols-dod.ps
rfc-by-author.txt
rfc-by-title.txt
rfc-index.txt
rfc-sets.txt
root-servers.txt
sendmail-cf-doc.txt
sendmail-generic.txt
sendmail-internet-generic.txt
simtel20.archives
sponsor-nets.info
tac-location.txt
tac-phones.list
tac-user.doc
test.ftp
us-domain.txt
usa-tac-phones.txt
user-template.txt
vendors-guide.doc
vendors-template.doc
wbs-notes-index.txt
what-the-nic-does.txt
who-ddn.txt
whois-info.txt
x25.doc

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 16:45:33 GMT
From:      spalleti@heman.intel.com (Sivasankar Palleti)
To:        comp.protocols.tcp-ip
Subject:   T3/T1 link encryptation - Help Needed


 
 Hi,

 What kind of encryptation is available for T3/T1 links? I would
 like to encrypt data on the links. Can any body suggests HW/SW
 available for this purpose?

 Thanks in advance

 Steve Palleti
 Networking Group
 (408) 765-4182

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 17:25:15 GMT
From:      NAM@EVAX2.ENGR.ARIZONA.EDU
To:        comp.protocols.tcp-ip
Subject:   Question on the loopback test.

Hi, I am doing some test with the TCP/IP socket.
I am not sure about socket activity at the following situation:

1)sender process and receiver process are reside in the same host,
  and sender sends a packet to receiver.
  Does this packet reaches to the ethernet?
  Is it just bounds back in the middle, then which layer?

2)When I setup the TCP/IP socket as loopback:
  IS the packet passed through loopback facility on the situation as above?

I appreciates any comment on this!

Thanks

Jiseung Nam
University of Arizona
Electrical and Computer Engineering
nam@evax2.engr.arizona.edu

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 18:05:48 GMT
From:      mandrews@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Specifying "wild" local IP addresses for UDP/TCP


I have been reading the UDP section of RFC1122 and am slightly confused
about "wild" IP addresses in the area of multihoming. The referenced
section (sect 4.1.3.5) states:

            An application program MUST be able to specify the IP source
            address to be used for sending a UDP datagram or to leave it
            unspecified (in which case the networking software will
            choose an appropriate source address).

I gather that if the source address is left unspecified, it is considered
"wild". How is this address represented; i.e. what is it's IP address?

Is an address considered wild if it does not match any of the IP addresses
assigned to the multihomed machine?

The only other reference I can find on "wild" addresses is in RFC1127,
the perspective on RFCs 1122 and 1123:

   -    Choosing a Source Address   [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]

        Require that an application on a multihomed host be able to
        either specify which local IP address to use for a new TCP
        connection or UDP request, or else leave the local address
        "wild" and let the IP layer pick one.

where CL is RFC1122.

It is not clear to me what "wild" means in the situation and how such an
address is represented.

Thanks for any clarification,

Mark
------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
Mail box: mandrews@alias.com

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 18:54:54 GMT
From:      nisc@NISC.SRI.COM (SRI NISC)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip list changes

This list is now administered by a new contractor.  The list has moved
from TCP-IP@NISC.SRI.COM to TCP-IP@NIC.DDN.MIL.  If you sent in an
address change request in the last week or so, it probably got lost in
the transition.  You should resend your request to TCP-IP-REQUEST@NIC.DDN.MIL.
The list maintainers do not generally read TCP-IP so it will do no good
to send your requests to the list.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:13:08 GMT
From:      dgreen@sti.com (Dan R. Greening)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and PPP compared

In article <1991Sep26.181205.15955@telebit.com> brian@telebit.com (Brian Lloyd) writes:

>There is another issue here: PPP will support other protocol stacks
>and SLIP will not.  If you are considering the possibility of running
>more than one protocol stack over your link you will want to consider
>PPP.  Also having the ability to negotiate anuthentication and IP
>addresses is a win.

The ability to quickly mask off control-character transmission
recently saved me on a PPP line (the other end was incorrectly
configured with XON/XOFF, but it was remote so I couldn't change it).

In this game, as a system administrator who uses both SLIP and PPP
every day, my main concern is reliability and usability.  There are
public domain SunOS versions of SLIP and PPP, and the PD PPP beats the
PD SLIP hands-down in reliability and usefulness.  

The SLIP implementation, when it isn't feeling good, likes to crash my
Sun (yes, I have the mcl-panic patches).  The PPP implementation handles
terminal-login/connection very well.  And so, I am happy with PPP.
-- 
____
\  /Dan Greening    Software Transformation   1601 Saratoga-Sunnyvale Rd, #100
 \/dgreen@sti.com   (408) 973-8081 x313       Cupertino, CA 95014

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:32:02 GMT
From:      shih@madrone.eecs.ucdavis.edu (Alan S. Shih)
To:        comp.protocols.tcp-ip
Subject:   PPP for 386 SVR4?

Hello all,

  Sorry to post such a novice question here; however, I cannot
  seem to find any answer from comp.protocols.ppp.

  I need PPP on my 386Unix station inorder to connect to school,
  however, I don't know what package/software I need.
  Is nos some thing I need? do I need to install my network
  pkg that come along with my unix?  Is there ppp pkg out
  there for 386SVR4 at all? if so, where can I get it?


  Anyinfo is greatly appreciated!
-- 
|   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."

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:37:46 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: communication servers and UUCP

pliuskon@intellistor.com (Saul Pliuskonis) writes:
>I would like to be able to use the Xyplex 
>for uucp, in addition to interactive dial-in, but I
>know very little about communication servers...

This posting is a week old without any responses.  I'm also interested in
the same information (hoping to bypass the problems associated with
setting up modems on an AIX system).  Are there any turnkey solutions to
the UUCP-over-a-network problem?

I'd like to plug a terminal server into our TCP/IP LAN and use it for,
among other things, dialup and UUCP from one or more Unix hosts.  Vendors:
e-mail only, no phone calls please.

-rich

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:38:12 GMT
From:      gritton@irvine.ee.byu.edu (Jamie Gritton)
To:        comp.protocols.tcp-ip
Subject:   FTP to the "new nic"

Is it just me, or has performance gone way down on FTP access to nic.ddn.mil
since it moved over to whatever that new company is? After waiting around a
few minutes, my FTP program responded: "the server host does not respond.
It may be overloaded." This was about 8:00 MDT, so 11:00 (or is it 12:00)
Eastern.

There wasn't any problem with SRI. I hope there won't be with these
new folks either.
--
- James Gritton - gritton@ee.byu.edu - I disclaim

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:45:26 GMT
From:      NAM@EVAX2.ENGR.ARIZONA.EDU
To:        comp.protocols.tcp-ip
Subject:   QUESTION ON LOOPBACK TEST

Hi, I am doing some test with the TCP/IP socket.
I am not sure about socket activity at the following situation:

1)sender process and receiver process are reside in the same host,
  and sender sends a packet to receiver.
  Does this packet reaches to the ethernet?
  Is it just bounds back in the network layer? If not, which layer?

2)When I setup the TCP/IP socket as loopback:
  IS the packet passed through loopback facility on the situation as above?

I appreciates any comment on this!

Thanks

Jiseung Nam
University of Arizona
Electrical and Computer Engineering
nam@evax2.engr.arizona.edu

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:51:07 GMT
From:      gritton@irvine.ee.byu.edu (Jamie Gritton)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <GRITTON.91Oct1203812@irvine.ee.byu.edu> I write:
> This was about 8:00 MDT, so 11:00 (or is it 12:00) Eastern.

I meant 8:00 pm MDT (i.e. late enough for such stuff)
--
James Gritton - gritton@ee.byu.edu - I disclaim

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 19:54:12 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: PD IBM PC Telnet/Ethernet terminal server s/w.

BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>Do you have the hardware needed to connect 20 terminals to a PC?
>
>My guess is that in order to do that, you step well outside of the "mass
>produced" PC peripherals, lose the cost advantages of the PC platform, and
>would be just as well off buying a commercial terminal server...

Not clear.  I'm about to start evaluating this problem myself:  do I
throw a bunch of multi-port cards into a 386 and something like ESIX
with TCP/IP on it, or do I buy a terminal server?

There are "mass-produced" 8-port cards for the AT bus which don't cost much
money at all.  There are probably 16-port cards as well.  The PC platform
certainly is attractively priced:  I can use a bare-bones 386 box for this
purpose.

The benefit of using the 386 box is that I then get an additional
Unix platform which can be used for validating our company's products.

How do commercial terminal servers compare?

-rich

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 20:06:12 GMT
From:      diro@edison.phone.North.DE (Dirk Rode)
To:        comp.protocols.tcp-ip
Subject:   Re: WD8013EP Packet Driver Question...

Shalom,

gooey@helix.nih.gov (Sean Graham) writes:


>	I was wondering if someone can tell me if the current packet
>	driver "WD8003E.COM   6535  03-28-91" supports the WD8013EP

 and when there is someone who knows this, is there also somebody
who knows a packet driver for the WD8003EBT Card? I search also the
(complete) source for such a packet driver and how to include it in
the KA9Q / NOS package.

         Dirk

P.S.: Same question - but for 3 Com 503 (Etherlink II) card ...

-- 
*  Dirk Rode              * dirk.rode@arbi.Informatik.Uni-Oldenburg.DE *
*  Zwischenahner Str. 64  * Bitnet:   077481@Doluni1.Bitnet            *
*  2910 Howiek            * Privat: diro@edison.phone.North.DE         *
* Die sich des Vergangenen nicht erinnern, sind dazu verurteilt,       *
*   es noch einmal zu erleben.                           Santayana     *

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 20:07:24 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell 386 3.11 to Internet / Telnet / FTP

rusek@pilot.njin.net (Robert John Rusek) writes:
>I have a Netware 3.11 server which I wish to connect to the internet.
>I require my workstations to be able to TELNET, FTP, and Mail to the 
>internet.  Does anyone know of a way to accomplish this.

Set up the Novell server as a router with two LAN cards:  one is
used for your Internet connection, and the other is the one you use for
your local subnet.  NetWare 3.11 doesn't provide any TCP/IP services
other than routing, unless you buy the NFS NLM along with it.  But you
can use client-side software on your DOS "workstations" and route traffic
via the Novell server without buying the add-on.

The public-domain way we do the rest at my site is via the Clarkson
package.  Get the packet driver distribution along with the CUTCP terminal
emulator program via anonymous ftp from omnigate.clarkson.edu.  You then
set up each person's PC to use the packet drivers, and assign each one
a TCP/IP address.  Set up the Novell router as a "gateway" (router, really)
in each user's CONFIG.TEL file, and then you're all set to go.

Note:  if you use NCSA TELNET, make sure you configure everyone with a
password file, because the default configuration allows incoming FTP
connections without a password.  (Whatever you do, think about security
before you go online.)  I recommend CUTCP over NCSA.

We do not currently use an SMTP-compatible mailer for DOS.  You can use
Charon (also on omnigate.clarkson.edu).

Of course, you could also use commercial products from any of a number
of companies.

-rich

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 21:38:00 GMT
From:      HENRYM@SACUSR.MP.USBR.GOV
To:        comp.protocols.tcp-ip
Subject:   RE: UNSUBSCRIBING


>In article <9109271420.AA01393@telesys.ncsc.navy.mil>,
>mark@TELESYS.NCSC.NAVY.MIL (Williams) says:


>>   Coordinator: Vivian Neou <Vivian@NIC.DDN.MIL>
>>                            (415) 859-4781
 
>I've check the Finger and SMTP VRFY/EXPN for vivian -- she doesn't
>seem to have an account.  VRFY postmaster produced sysadm@nic
>(which I would assume to be sysadm@nic.ddn.mil).
 
>/Pete

	That's because the NIC.DDN.MIL you FINGER'ed is the NEW NIC in
Virginia.  Whole new machine, whole net setup.  The OLD NIC is now known
as XNIC.DDN.MIL, and is still in Menlo Park.  Vivian's account is still
active there.

-HWM
----------
Henry W. Miller
Assistant Systems Manager, Mid Pacific Region
U.S. Bureau of Reclamation
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS 460-5108
Inet:	"henrym@sacwms.mp.usbr.gov"
BITNET:	"hmiller@scu"

"Bad guys abuse public land, good guys save it."

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 91 23:28:35 GMT
From:      spalleti@heman.intel.com (Sivasankar Palleti)
To:        comp.protocols.tcp-ip
Subject:   T1/T3 data encryptation



 Hi,

 What kind of data encryptation is available for T3/T1 links ? Can any
 body please suggests HW/SW available for this purpose?

 Thanks in advance
 Steve Palleti
 (408) 765-4182

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 01:01:03 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostby* routines

In article <9109272054.AA13335@ftp.com> hobbit@FTP.COM (*Hobbit*) writes:
>Is it really the case that most gethostbyaddr() implementations return only
>the canonical name in the hostent [hostinfo? whatever] struct, without filling
>in the aliases as well? 
>
>We further noticed that one can "work around" this by taking the one name you
>get back, and doing a forward gethostbyname() on *that*.  You then get
>back all the aliases.

I don't see how the DNS can give you "all the aliases". However,
gethostbyname() can give you all the ADDRESSES.

With DNS, you should ALWAYS be using the FQDN.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 04:40:02 GMT
From:      tkevans@fallst.UUCP (Tim Evans)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: communication servers and UUCP

In <1991Oct01.193746.9290@kronos.com> richb@kronos.com (Rich Braun) writes:

>pliuskon@intellistor.com (Saul Pliuskonis) writes:
>>I would like to be able to use the Xyplex 
>>for uucp, in addition to interactive dial-in, but I
>>know very little about communication servers...
 
>This posting is a week old without any responses.  I'm also interested in
>the same information (hoping to bypass the problems associated with
>setting up modems on an AIX system).  Are there any turnkey solutions to
>the UUCP-over-a-network problem?

Actually, I replied via e-mail to the poster...

Just add to your chat script all the necessary stuff to negotiate
through the terminal server.  Same expect-send sequences as you use
to get through a direct login.  Below is an actual example (system
name and real password X'd out, which logs into some kind of
terminal server, then accesses a UNIX system and starts up UUCP:


xxx Any ACU 2400 5555555 "" \d\r\d\r\d\r ts>-\r-ts> terminal\sflowcontrol\snone ts>-\r-ts> terminal\sdownload ts>-\r-ts> xxx ogin: xxx ssword: xxx

Note that this embeds spaces with '\s'

Hope this helps.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 04:58:15 GMT
From:      mark@comp.vuw.ac.nz (Mark Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"


In article <GRITTON.91Oct1203812@irvine.ee.byu.edu>, gritton@irvine.ee.byu.edu (Jamie Gritton) writes:
|> Is it just me, or has performance gone way down on FTP access to nic.ddn.mil
|> since it moved over to whatever that new company is?

There appears to be DNS problems there as well:

Oct  2 16:39:48 localhost: 18973 named:
  Lame delegation to '36.112.192.IN-ADDR.ARPA' received from 192.112.36.5
  (purported server for '36.112.192.IN-ADDR.ARPA')
  on query on name [5.36.112.192.in-addr.arpa]

192.112.36.5 is nic.ddn.mil

This is causing our DNS traffic to skyrocket due to binds lack of negative
caching and somethings desire to continually lookup the above.

cheers
mark

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 07:56:44 GMT
From:      CSP1DWD@mvs.oac.ucla.edu (Denis DeLaRoca)
To:        comp.protocols.tcp-ip
Subject:   Re: Prospero and Archie

What's "Prospero" and how does one get to it...

-- Denis

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 13:20:47 GMT
From:      ercm20@castle.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostby* routines

hobbit@FTP.COM (*Hobbit*) writes:
> Is it really the case that most gethostbyaddr() implementations return only
> the canonical name in the hostent [hostinfo? whatever] struct, without filling
> in the aliases as well? ...

As a relatively new DNS user I understood that this was feature - when
you look up an address there is no way for the NS to give the resolver
more than one name (unless the resolver does the deprecated inverse
lookup rather than looking in in-addr.arpa )

> We further noticed that one can "work around" this by taking the one name you
> get back, and doing a forward gethostbyname() on *that*.  You then get
> back all the aliases.  Sure, we can mung all our various Sun libraries to
> do this and hope all the executables call this same library, but it doesn't
> help us for all cases and I was wondering if there was a better way to make
> gethostbyaddr() work right for us.

I don't think so.  Sun in the mean time are actually doing it for you
(if you're using Sun's resolver code) and doing it wrongly, but not
telling you, but that's an old problem. 

Sam Wilson
Computing Service
The University of Edinburgh, Scotland

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 13:46:48 GMT
From:      jon@mxmsd.UUCP (Jon Fields)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   comparison of cisco and DEC routers

Hello,

I'm looking for comparisons of cisco routers (IGS, CGS, MGS) to
DEC WANrouters (100, 150, 250, 500).  Performance, reliability,
ease of configuration, etc. (I can compare functionality from
the product descriptions that I have.)

Any input will be greatly appreciated.

Thanks in advance.

--
 UUCP: ...uunet!mxmsd!jon         Jon Fields
Voice: (513)-825-3931 x-314       Measurex--Management Systems Division
  Fax: (513)-825-5393             1280 Kemper Meadow Drive
                                  Cincinnati, Ohio 45240

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 14:21:18 GMT
From:      Karl_Kleinpaste@godiva.nectar.cs.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

Another data point on the new NIC's problems, they've had mailer
difficulties, too -- a classic and trivial sendmail.cf error.

--karl
________________

Date: Mon, 30 Sep 91 09:19:50 EDT
From: Mailer-Daemon@diis.ddn.mil (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
To: <firearms-Request@N2.SP.CS.CMU.edu>

   ----- Transcript of session follows -----
Connected to NIC.DDN.MIL:
>>> HELO diis.ddn.mil
<<< 553 diis.ddn.mil host name configuration error
554 <jackson@nic.ddn.mil>... Service unavailable

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 14:35:00 GMT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Mach 3.0 sources (was LANCE bug)

To all who asked and will ask for source access to the code I mentioned,
here are the FTP instructions.
This is not for advertising, working code is better than a million
words of explanation.  The files in question are, in the default tape,
named kernel/chips/lance*
Have fun,
sandro-
-----------------------------------------------------------------------------

The only Mach sources that are available to sites not holding
BSD/AT&T licenses are the micro-kernel sources for Mach 3.0. The instructions
for FTP access to them follow:

The Mach 3.0 micro-kernel sources can be anonymously ftp'ed from
CMU as follows:

ftp cs.cmu.edu  or 128.2.222.173
Name: anonymous
Password: <name>@<site>
cd mach3

At this point standard ftp commands will work.v There are
several information files there and three compressed tar files:

The Mach3.info file gives a description of the current status
of Mach3 development work.

The READ_ME file gives a brief description of the source
file organization.

The VERSION file contains the version number of the
kernel sources in the tar files. Check it to see when 
you need to get a new copy of the sources.

FTP.inst is this file.

default.tar.Z (1506K)	The machine independent code
i386.tar.Z (117K)	i386 specific code
mips.tar.Z (470K)	DecStation 3100/5000 specific code

The files use relative pathnames and are designed to be 
extracted in the same directory. Use a standard tar extraction
command such as:
  /usr/ucb/uncompress default.tar.Z | tar -xvf -


The subdirectory src contains all the individual files which
can be ftp'ed separately if desired. They are indentical to
the contents of the tar files. The end of the file 
src/latest/MERGE_HISTORY describes the latest changes. 
 
Our perferred method of distribution is via a program called SUP. 
This program can be run on most Unix systems with an internet connection. 
Using SUP will get you a more up-to-date versions of the software and enable
you to get licensed files. 

To find out more about using SUP send mail to mach@cs.cmu.edu.

Mary Thompson
Project Mach Distribution Manager

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 14:37:24 GMT
From:      jwkhong@grand.waterloo.edu (James W. Hong)
To:        comp.protocols.tcp-ip
Subject:   CMIP/CMOT agent?

I am not sure if this was discussed in this newsgroup but I was wondering if
there is any CMIP/CMOT agent implementations (either PD or commercial)
available.

Any help would be greatly appreciated. 

-------------------------------------------------------------------------------
James Won-Ki Hong                              	     
Dept. of Computer Science              	             jwkhong@grand.waterloo.edu
Univ. of Waterloo				     jwkhong@grand.uwaterloo.ca
Waterloo, Ontario, CANADA         jwkhong%grand%waterloo.csnet@csnet-relay.arpa
Tel: (519) 888-4719          {allegra,decvax,utzoo,clyde}!watmath!grand!jwkhong

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 15:06:16 GMT
From:      sblair@upurbmw.dell.com (Steven C. Blair "Your Friendly Hostmaster")
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"


In article <1991Oct2.045815.14917@comp.vuw.ac.nz>, mark@comp.vuw.ac.nz (Mark Davies) writes:
> 
> In article <GRITTON.91Oct1203812@irvine.ee.byu.edu>, gritton@irvine.ee.byu.edu (Jamie Gritton) writes:
> |> Is it just me, or has performance gone way down on FTP access to nic.ddn.mil
> |> since it moved over to whatever that new company is?

There also appear to be *NO* NS pointers to them either. Bubba sez
checkout a nslookup, set type=NS, and nic.ddn.mil has *NO* ns pointer...

we now return to your regularly scheduled root.cache.....
-- 
Steve Blair	DELL UNIX NETWORK OPERATIONS sblair@upurbmw.dell.com
"Undercover of the sun, until the birds have flown away"--Erasure

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 16:06:38 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Subnetting

In looking through my TCP/IP documentation, I find no mention of how
one would split a Class C address into subnets.  There's plenty of stuff
written about splitting a Class B address.

Is it OK to use a net mask of 255.255.255.192 for each host on a subnet?
Will the routing tables be kept correctly by my hosts (AIX, SCO, and
Novell 3.11)?  Will a router keep track of differing subnet masks for
different nets?

Thanks,
-rich

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 16:21:14 GMT
From:      markus@edfd.uucp (Markus Gruenkorn)
To:        comp.protocols.tcp-ip
Subject:   Possibility to do FTP accounting on a Xenix-PC!

In our company we have a large TCP/IP network. In this TCP/IP network there is one Xenix-PC to which a
Laserplotter is connected. Different Unix-Workstations and PCs (MS-Dos) from different departments are sending Files with FTP to this Xenix-PC. Now i need to know the Source-Computer (IP/Address or hostname) of each File transfered to this
Xenix-PC. I examined the options of FTP on the Xenix Pc but I did not find a solution. Is there an easy
way to do this FTP accounting?

Thanks in advance for any help on this subject!

Markus Gruenkorn
engineer
Eckard Design
Fulda
Germany

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 16:37:52 GMT
From:      mmorse@NSF.GOV (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip list changes


> This list is now administered by a new contractor.  The list has moved
> from TCP-IP@NISC.SRI.COM to TCP-IP@NIC.DDN.MIL.  If you sent in an
> address change request in the last week or so, it probably got lost in
> the transition.  You should resend your request to TCP-IP-REQUEST@NIC.DDN.MIL.
> The list maintainers do not generally read TCP-IP so it will do no good
> to send your requests to the list.

One mystery is why maintaining Internet lists is so rarely automated.
The BITNET world may be pre-historic in terms of network technology,
but they've been automatically subscribing and un-subscribing folks for
years.  They still get some people sending the requests to the list
rather than the maintenance program, but that'll always be with us.
The BITNET system is far from perfect in that it only allows you to add
your own address to the list (the one in your "From:" field), but it
sure beats a human being doing repetitive, tedious, work in his/her
spare time.

--Mike

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 16:42:06 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

> Having looked over the slide and slither "rfcs", and the
> assoicated mail, I have cleverly decided to stay out of the
> philosophical discussion. 

Obviously not a bad strategic move.

			    However, there are a few mis-statements
> of "facts" that I feel compelled to respond to....
 
> Firstly, the idea of using (essentially) the ethernet encapsulation on
> serial line is tempting.  No need to write a new RFC for each new protocol,
> potentially better error checking, shared device driver code.  So you
> waste a few header bytes - it's a high speed line, it doesn't matter much.
> Ethernet has been areound for a while now, and everyone is familiar with it.
 
>     1) There is good evidence to believe that PPP is going to be
>        incompatible with the latest generation of serial chips which support
>        ether modes and with the latest generation of ether chips which
>        support serial modes.
 
>        ...if the serial chip has an interface to the host processor which
>        looks like the interface to a common ethernet chip, or if in fact
>        common ethernet chips can be programmed to do hdlc bit stuffing,
>        software development is a lot cheaper if the changing one or two lines
>        of the initialization code of the ethernet driver is sufficient to
>        turn the ethernet driver into a serial hdlc driver.
> 
> A) The fact that some ether/serial chips are capable of supporting both
>    formats does not make PPP "incompatible" with these chips.

Well, it does if you want to make use of the chips address
matching/filtering features.  Remember in a bridged environment frames
with unknown destination adresses will reach all hosts attached to the
communications subnet.  Also matching on some set of logical addresses
is probably reasonable as well, and the set of interest will differ
depending on whether the device of interest is a bridge or end host.

> B) Defining "standards" based on available chips is backwards, sort of.

Really, didn't the IEEE define the ethernet standard long after
ethernet chips were available?  In any case, the capabilities of
interface chips are definitely an input into defining a standard just
as the availability of memory protection hardware is rather necessary
before once can truly implement a multiuser computer system.
Generally people did not go out and fully specify multiuser operating
systems before the necessary hardware existed.

> C) I count only 1 (one) more chip familly supporting both (The Zilog).
>    The last generation of Intel chips (in fact, the 82586 was the first
>    second generation ethernet chip available) also supported many modes.
>    The AMD ILLAC does NOT support serial modes according to the latest
>    documentation I've seen.

The 82596 supports a sort of HDLC mode.  I have to admit that I
conflated the ILACC with a possible future serial chip which an AMD
engineer discussed with me.  I removed the ILACC from later versions
of the proposed standard.

> D) The interface device driver is such a small portion of the software
>    that makes up a modern multi-protocol multi-media bridge/router that
>    the cost savings of having a "single driver" are pretty small.

Actually, the interface device driver is an extremely critical portion
of the software in a wire-speed multi-media bridge, and speed-bumming
can eat up a lot of development time.  Being able to use the same
device driver across several interfaces is extremely useful, and I
assume this is part of the motivation for Chips and Technologies
ChipsLAN set which supports both token-ring and ethernet.  If I am not
mistaken Chips and Technologies is either in or getting into the
wire-speed bridging market.

> E) Those savings are offset by the overhead and difficulty of providing
>    unnecessary protocols for the serial line (eg ARP).

Actually, in a bridging environment, ARP'ing a host connected to a
bridge via a point to point serial line is quite reasonable.

> F) And it still doesn't help all those interfaces that are neither
>    HDLC nor EtherNet (TR, FDDI, T3, ULtraNet, ISDN, ATM, etc...)

But once the problem is solved for EtherNet the problem would be
solved for SLITHERNET unlike the case of PPP.

> G) No matter how hard one tries to pretend otherwise, a serial PtoP
>    link is NOT an ethernet.  Trying to treat it like one is probably
>    not a very good idea.

The main distinguishing feature between two hosts connected by a
megabit rate point-to-point non-self-clocking DTE/DCE type serial
connection and between two hosts connected by a point-to-point serial
connection lies in the half-duplex nature of the ethernet connection.
Interestingly enough some modern ethernet chips don't really care that
the medium be half-duplex and I know that at least one company has
built full-duplex ethernet.

>     2) Only the bridging version of PPP contains sufficient information
>        that sophisticated mesh topologies of serial links can be supported.
>        Such mesh topologies are often desirable when seeking high reliability
>        and availability in a network.
 
> I'm sure the router vendors who have been offering boxes that support
> "sophisticated mesh topologies" for the last 5 years will be surprised
> to hear this.  Or did you mean "only the bridging version of PPP contains
> sufficient information to to bridging"?

I mean the customer should be able to build a communications subnet
using MAC bridges as PSNs and point-to-point serial lines as
connections between bridges or as access media for end hosts.  By
definition routers can't do this.

>     3) Unfortunately, the bridging version of PPP contains variable length
>        goop in front of the MAC packet.  Many microprocessors, like the AM29k
>        or IBM ROMP (used in the RT/PC) have no real capabilities for dealing
>        with multiple allignments of data.  The Intel 80x86 microprocessors
>        can handle multiple allignments of data, but will produce much lower
>        performance when doing so.
 
> I re-read the RFC, because I didn't believe that Fred Baker (with the IETF
> looking over his shoulder) would do anything this stupid, and I was right.
> It looks to me like for an equivilent configuration, the PPP bridging spec
> "factors" out to a fixed packet format:
 
> A) There is an optional "LAN ID" word.  I'd assume that this is either
>    there on essentially all packets, or never, in a particular network.
>    In any case, it's 32 bits long, so it doesn't affect alignment.
> B) If you are bridging either 802.4 or 802.5, you can get packets with
>    another 16 bits of "stuff" in them.  I don't think that you can both
>    types of packets on the same link (otherwise SRT or 8209 style symantics
>    would come into play, converting the packets to one form or ther other).
>    Even if you could, I don't see how this would affect overall speed.  Since
>    you have to do table lookups of both source and destination "ethernet"
>    addresses, one of them is never aligned on 32 bit boundries...

Actually on the 29k this would effect overall speed because the
fastest way to do the comparison is to do the fastest possible
comparison with the allignment of the src and dst addresses known.

As for getting both types of packets on the same link that is
possible,

A token WAN bridge connects to a pure WAN bridge which also connects
to an ether WAN bridge.  The pure WAN bridge then forwards packets
from the token and ether bridge to a fourth bridge of unspecified
type.

The 16 bit allignment can be particularly bad in the case where the
ether or token chip requires 32 bit allignment and the processor is a
29k which cannot do reallignment very easily.  Even some CISC chips
which apparently have reallignment instructions do not have efficient
internal data paths for this operation and will consume lots of
valuable cpu cycles in reallignment.

>     4) PPP is too complex in other ways (primarilly the link control protocol)

5) I may have missed something in the spec, but I saw no easy way for
devices connected by PPP to negotiate the use of bridging format packets
versus the use of network format packets.

> This is probably true, although it is not too difficult to implement the
> "minimal subset" of PPP.  All during the period that PPP was being defined
> (two years!), there were occasional talks amoung router vendors about
> bypassing "all that async-oriented" stuff and coming out with a de-facto
> industry standard based on someone's (anyone's!) existing sync spec.  But
> we didn't...  You can always get stuck like the rest of us - run PPP when
> you need to talk to another vendor, and your own protocol when that won't
> work for some reason.

This is our strategy as well.  It makes PPP seem rather pointless
though and adds development time and cost to products.  But I guess if
customers don't mind paying more money without getting extra bang for
the buck, who am I to argue?

> BillW
> -------

Joachim Carlo Santos Martillo Ajami

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 16:52:24 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <GRITTON.91Oct1203812@irvine.ee.byu.edu> you write:
|> Is it just me, or has performance gone way down on FTP access to nic.ddn.mil
|> since it moved over to whatever that new company is? After waiting around a
|> few minutes, my FTP program responded: "the server host does not respond.
|> It may be overloaded." This was about 8:00 MDT, so 11:00 (or is it 12:00)
|> Eastern.
|> 
|> There wasn't any problem with SRI. I hope there won't be with these
|> new folks either.

This is not too surprising. Connectivity to the "old" NIC was via a fairly short,
all T-1 path through BARRNet and the NSFNet. It would appear that the "new" NIC
is solely connected to the MILNET, with all of the reliability and performance
that such a connection implies (as an example: sending a bunch of PING's to
NIC.DDN.MIL just a few minutes ago resulted in 16 of 18 packets dropped, with
RTT's of 6730 and 10683 ms for the two packets which survived...). Unless GSI
decides to get a non-MILNET Internet connection, I wouldn't expect performance
to improve any time soon (remember, though, that NIC.DDN.MIL's primary mission
is to support MILNET users, so perhaps this is intentional).

	--Vince

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 17:47:04 GMT
From:      sigurtho@kerfi.hi.is (Sigurdur Thorarinsson)
To:        comp.unix.programmer,comp.unix.questions,comp.protocols.tcp-ip
Subject:   UDP/IP


I have a question concerning the UDP/IP protocol.
I am using a datagram socket to broadcast messages on an ethernet.
But the messages seems to duplicate, that is for each message I send
there appear two on the network.  Is this normal, and if it is not,
why does this happen ?  I am working on a HP 9000/380 and using HP-UX 7.05.

Does any of you have a reasonable explaination to these questions ?
Please, let me know if you have any ideas.


     Sigurdur Thorarinsson
     Engineering Research Institute
     University of Iceland
     Iceland
     sigurtho@kerfi.hi.is

--------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 18:11:51 GMT
From:      jrjones@MR.Net (James R. Jones)
To:        comp.protocols.tcp-ip
Subject:   ip addressing

hello everybody,

At my company I am about to set up a large ethernet ip network.  I plan
on using a class B number.  Somewhere long ago I read that when you 
subnet a class b network the you should not start at 1 and go up but     
start at 248 and go down, or something like that.  Could someone please
refresh my memory on the issuses. 

jim

jrjones@mr.net

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 18:39:15 GMT
From:      leonard@arizona.edu (Aaron Leonard)
To:        comp.dcom.lans,vmsnet.networks.misc,comp.protocols.tcp-ip
Subject:   FYI: Results of terminal server evaluation

Greetings fellow networkers,

The University of Arizona has just completed an excruciatingly
protracted Request for Proposal for terminal servers.  (Actually,
we haven't *completed* it in the sense that there are still a
dozen or two bureaucrats' desks across which it still must pass,
but at any rate it's left *my* desk.)

Anyhow, we were looking for a comprehensive terminal server
solution, one that would offer good TCP/IP and LAT access, that
offered flexible wiring options, that was manageable and cost 
effective.  The evaluation process took several months and quite
a bit of personnel time.

So after doing all this work to evaluate these terminal
servers, I figured that it would be a nice gesture to offer our
results to the Net.  Thus I am posting a DRAFT version of our 
selection document.  (The actual dollar amounts have been censored,
but information about relative pricing is included.)

Disclaimers:

1. The closing date for responses on this RFP was in Jan. 1991, so
   some of the product info may be out of date by now.
2. This posting is just me, NOT official University of Arizona or 
   State of Arizona blah blah woof woof.  No applicability or
   suitability is expressed or implied, etc.
3. If you are a losing vendor, I don't want to see any whining mail
   or hear any pleading phone calls.
4. If you are an interested user and have questions about the terminal
   servers, please contact the vendors and not me.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Telecommunications, Tucson AZ 85721

 
Vendor phone #'s (Arizona-centric):

Xylogics - Sales: Bret Bergman (408)354-4122
Xyplex - Sales: Teresa Lamoureaux (303)277-9229
cisco Systems - Sales: Rick Balli (303)721-0408
Anixter/Synoptics+Racal Interlan - Sales: Tony Peredes (602)624-9945/968-7901
Hughes LAN Systems - Sales: James Marzola (602)820-9155
Synoptics - Sales: Pam Wolters-Mills (602)844-7332
BFA/Datability - Sales: Dick Leger (602)994-5400
Lantronix - Sales: Anthony M. Swanson (800)422-7022
Four Corners/Equinox+Emulex - Sales: Kim Patberg (602)998-4440
 
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 

                                  RFP 927-90
                            University of Arizona
                             Summary of Proposals
                               Terminal Servers

                                Aaron Leonard

                              September 24, 1991

1. The Selection.

CCIT-Telecommunications has evaluated a portion of the RFP 927-90.
The results of that evaluation are listed below.  This evaluation
is limited to terminal servers.

The RFP had specified two different categories of terminal servers: 
"Terminal Servers for use with dumb terminals" and "Terminal Servers
with modem leads for use with intelligent devices."  As the
capabilities of the latter are a superset of the former, we have
selected one terminal server, the Xylogics Annex 3, to fulfill both
categories.  Additionally, we have selected another terminal server,
the Xyplex, as an alternative, in order to meet requirements of
specialized applications

The recommended terminal server is the Xylogics Annex 3, as bid by
R-Squared. It met all of the requirements of both categories. 
Additionally,  in the maximal configuration, it has the lowest price
per port of any terminal server bid.  Our evaluation unit performed
with no hardware or software problems.

We award R-Squared the selection for the following Xylogics Annex 3
configurations.  All ports support modem control.

# ports   List price   Discount     Price/Per port   Price/Per port w/ LAT
-------   ----------   --------    ---------------   ---------------------
    8        
   16       
   32      
   64      

The Xyplex MAXserver 1000 terminal server, as bid by High-Tech
Associates, met all requirements of the RFP.  Our evaluation unit
performed with no hardware or software problems, except that it was
not able to support a binary file transfer from a PC to a Unix host.
(See sec. 5 below for details.)  We recommend the Xyplex MAXserver
1000 series for the following applications:

* Standalone units in support of low port density.  At the 16-port
  concentration level, the MAXserver 1000 is somewhat less expensive per 
  port than the Annex 3.
* Applications requiring reverse LAT or LAT application ports.  The Annex 3 
  only supports "forward" LAT (terminal connections).  The Annex cannot
  offer LAT services.
* Applications where a Unix host is not available to perform terminal
  server load services.  The Annex 3 requires that a Unix host be used
  to configure and load the terminal server.  The Xyplex MAXserver 1000
  may be loaded from Unix or VMS hosts, or from local floppy disk.

We select the following Xyplex MAXserver 1000 models as bid by
High-Tech Associates, for use in the above applicatons.  All units 
support limited modem control and have 16 ports.

Model #         LAT  TCP/IP  Memory  Floppy   List price    Price/Per port
----------      ---  ------  ------  ------   ----------    ---------------
MAX1820-E        Y     Y      2MB      Y      
MAX1800-E        Y     Y      1MB      Y      
MAX1520-E        Y     Y      2MB      N      
MAX1500-E        Y     Y      1MB      N      
MAX1120T-E       N     Y      2MB      N      
MAX1100T-E       N     Y      1MB      N      
MAX1120L-E       Y     N      2MB      N      
MAX1100L-E       Y     N      1MB      N          

MX-420-0177 - upgrade MAXserver 11x0 to 15x0      

 
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 

2. The selection process.

In response to RFP 927-90, we received thirteen different bids
(vendor/hardware combinations.)  After evaluating the price and
technical specifications of the products bid (which are summarized
in section 3 below), we selected four finalists based upon the
criteria given in section 4 below.  

For each of the four finalists, we asked for and received an
evaluation unit.  Each evaluation unit was installed and configured,
and then tested by Telecom staff, as well as by interested users
in other UofA departments.  The results of the evaluation period
are given in section 5 below.
 
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 

3. Summary of bid responses.

Following are the criteria established for the terminal servers
in the RFP:

The following criteria applied to both portions of the terminal 
server request for proposal ("dumb" and "smart")
SNMP                    "should"
TELNET                  "must"
rlogin                  "should"
LAT                     "must"
rackmount               "should"
accounting              "should"
TN3270                  "should"
warranty                the longer the better
price                   the lower the better
delivery schedule       the shorter the better

The following criteria applied to the "smart" portion only:
modem control           "must"
reverse connections     "should"
SLIP/PPP                "should"


The scorecard for each terminal server is given.  Pricepoints
are given for each terminal server (or family of terminal servers)
across the range from the smallest number of ports offered in a
server to the largest.  Where pricing differs for modem control
ports and non-modem control ports, both prices are given.

Vendor #1 - R Squared/Xylogics
SNMP                    yes
TELNET                  yes
rlogin                  yes
LAT                     yes
rackmount               yes
accounting              yes
TN3270                  no
warranty                1 year
delivery schedule       4 weeks
modem control           yes (standard)
reverse connections     yes (TCP/IP only)
SLIP/PPP                yes (SLIP)

Pricing:
Model #         MC?     # ports          Price          Per port (*)
------------    ---     -------         ------          --------
Annex 3         yes         8         
Annex 3         yes        16         
Annex 3         yes        32        
Annex 3         yes        64        
(*) $xx extra per port for LAT

Vendor #2 - High-Tech/Xyplex
SNMP                    yes
TELNET                  yes
rlogin                  yes
LAT                     yes
rackmount               yes
accounting              no
TN3270                  yes (option)
warranty                software: 1 year; hardware: 5 years
delivery schedule       3 weeks
modem control           yes (optional)
reverse connections     yes
SLIP/PPP                yes (SLIP)

Pricing (*):
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
MAXserv 1500    yes        16       
  (w/ TN3270)                       
MAX4500         yes        40       
  (w/ TN3270)                       
MAX4500         no         80       
  (w/ TN3270)                       
MAX5000         yes        96       
  (w/ TN3270)                       
                no        192       
  (w/ TN3270)                       
                yes       128       
  (w/ TN3270)                       
                no        256       
  (w/ TN3270)                       

(*) TN3270 option is $xxxxxx/8 ports and $xxx/16 ports.
    MAX4500 (5-slot chassis) is $xxxx.
    MAX5000 (16-slot chassis) is $xxxx.
    TSRVM-J8 (8-port MC board) is $xxxx.
    TSERV-J16 (16-port no MC board) is xxxx.

Vendor #3 - cisco Systems
SNMP                    yes
TELNET                  yes
rlogin                  yes
LAT                     yes (option)
rackmount               yes (ASM & MSM)
accounting              yes
TN3270                  future
warranty                software: 90 day; hardware: 1 year
delivery schedule       60 days
modem control           yes (standard)
reverse connections     yes
SLIP/PPP                yes (SLIP)

Pricing:
Model #         MC?     # ports          Price          Per port(*)
------------    ---     -------         ------          --------
STS-10          yes        10        
MSM             yes        16        
                           32        
ASM             yes        48        
                           96        
(*) $xx extra per port for LAT

Vendor #4 - Xyplex/Xyplex
- Xyplex bid the same product line as High-Tech did, but with 
  higher prices across the board (xx% discount vs. xx%.)

Vendor #5 Anixter/Synoptics
- Anixter bid a SynOptics part #3395 16-port MC line card
for $xxxx.  This part is the same as what SynOptics bid for $xxxxxxx.
Anixter did NOT bid a price for SynOptics hubs, so based upon this 
bid we could not configure a complete terminal server.

Vendor #6 - Anixter/Racal Interlan
- the capabilities of the product could not be discerned from the bid -

Pricing:
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
INX 5000-3C     ???        16       
                           48       
INX 5000-12C    ???        96       
                          192       

Vendor #7 - Hughes LAN Systems/HLS
SNMP                    yes
TELNET                  yes
rlogin                  yes
LAT                     yes
rackmount               yes (4296)
accounting              ???
TN3270                  no
warranty                software: 90 days; hardware: 1 year
delivery schedule       4 weeks
modem control           yes (standard)    
reverse connections     LAT only (?)
SLIP/PPP                yes (SLIP)

Pricing:
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
4208            yes         8          
4296            yes        32          
                           96          

Vendor #8: SynOptics/SynOptics
SNMP                    yes (extra cost)
TELNET                  yes
rlogin                  yes
LAT                     yes
rackmount               yes
accounting              ???
TN3270                  future (extra cost)
warranty                1 year
delivery schedule       ???
modem control           yes (standard)
reverse connections     yes
SLIP/PPP                yes (SLIP)

Pricing (*):
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
3030            yes        16        
                           48        
3000            yes        96        
                          176        
(note: SNMP and TN3270 are extra cost options and were not quoted.)

(*) 3030 (4-slot chassis) is $xxxxxx.
    3000 (12-slot chassis) is $xxxx.
    3333 (Ethernet AUI card) is $xxxxxx.
    3395 (16-port MC board) is $xxxxxxx.

Vendor #9: Digital/Digital
SNMP                    future
TELNET                  yes
rlogin                  no
LAT                     yes
rackmount               yes
accounting              no
TN3270                  no
warranty                1 year
delivery schedule       ???
modem control           no
reverse connections     yes
SLIP/PPP                future

Pricing:
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
DECserver 300   no         16           $ xxxx          $ xxxxxx

Vendor #10: BFA/Datability
SNMP                    yes
TELNET                  yes
rlogin                  yes
LAT                     yes
rackmount               yes (VCP-1000 - $xx extra)
accounting              no
TN3270                  no
warranty                1 year
delivery schedule       ???
modem control           yes (VCP/LC-32-RS423: partial [6 leads])
reverse connections     yes
SLIP/PPP                yes (SLIP)

Pricing:
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
VCP-200         full        8       
VCP-300         full       16       
VCP-1000        full       32       
                some       32       
                some       64       
                some      128       

Vendor #11: Lantronix/Lantronix
SNMP                    yes
TELNET                  yes
rlogin                  yes
LAT                     yes
rackmount               no
accounting              no
TN3270                  no
warranty                hardware: 2 years; software: 1 year update service
delivery schedule       ???
modem control           yes (6 leads)
reverse connections     yes
SLIP/PPP                no

Pricing:
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
EPS-4           yes     4s + 1p        
ETS-8           yes         8          
ETS-16          yes        16          

Vendor #12: Four Corners/Equinox
SNMP                    no
TELNET                  future
rlogin                  future
LAT                     yes
rackmount               option
accounting              no
TN3270                  no
warranty                hardware: 3 years
delivery schedule       ???
modem control           partial (4 leads)
reverse connections     yes (LAT)
SLIP/PPP                no

Pricing:
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
ELS-48          some       24        
                           48        

Vendor #13: Four Corners/Emulex
SNMP                    yes
TELNET                  yes
rlogin                  yes 
LAT                     yes
rackmount               yes
accounting              no
TN3270                  no
warranty                hardware: 5 year
modem control           P4000 - none (4 leads)
                        P8000 - partial (5 leads) or full
reverse connections     yes
SLIP/PPP                yes (SLIP)

Pricing: 
Model #         MC?     # ports          Price          Per port
------------    ---     -------         ------          --------
P4000           none        8        
                           16        
                           32        
P8000           some       64        
                          128        
                full       32        
                           64        

 
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 

4. First cut analysis of the bid responses.

The first cut of the evaluation process was to select "finalists"
from the thirteen bids.  Following is an explanation, for each of
the bids, of why it was or was not selected as a finalist.

Vendor #1: R Squared/Xylogics: FINALIST
Why:
* Met all required criteria
* Met all selective criteria but TN3270 
* Modem control standard
* Best price per port at maximum port density ($xxxxxx)

Vendor #2: High-Tech/Xyplex: FINALIST
Why:
* Met all required criteria
* Met all selective criteria but accounting
* Only vendor offering TN3270
* Good price per port at 16-port density ($xxxxxxxx)

Vendor #3: cisco Systems: NOT FINALIST
Why:
* Price per port not competitive at either maximum port density
  ($xxxxxxxx) nor at 10-port density ($xxxxxxxx)

Vendor #4: Xyplex/Xyplex: NOT FINALIST
Why:
* Prices for the same product line xx% higher across the board than
  Vendor #2

Vendor #5: Anixter/Synoptics: NOT FINALIST
Why:
* Unable to configure a complete terminal server based upon the bid

Vendor #6: Anixterm/Racal Interlan: NOT FINALIST
Why:
* Vendor did not provide sufficient information with the bid to enable
  us to figure out whether the product met our requirements.  (Besides,
  the prices were noncompetitive.)

Vendor #7: Hughes LAN Systems/HLS: NOT FINALIST
Why:
* Prices per port not competitive at significant port densities 
  ($xxx - $xxx).

Vendor #8: SynOptics/SynOptics: NOT FINALIST
Why:
* Vendor bid Xyplex cards in SynOptics chassis, but prices per port
  were worse at almost all price points than Xyplex MAXserver 1000s
  as bid by High-Tech
* SynOptics' implementation of Xyplex software lags behind Xyplex'
  own (e.g. no TN3270 available from SynOptics as of time of bid)

Vendor #9: Digital/Digital: NOT FINALIST
Why:
* No modem control available from vendor
* Product lacks most of the selective criteria: no SNMP, no rlogin,
  no accounting, no TN3270, no SLIP.

Vendor #10: BFA/Datability: FINALIST
Why:
* Met all mandatory criteria and all selective criteria but TN3270
  and accounting
* Good price per port at 16 ($xxx) and 128 ($xxx)

Vendor #11: Lantronix/Lantronix: FINALIST
Why:
* Met all mandatory criteria and some selective criteria 
* Best price per port at 16 ($xxx)

Vendor #12: Four Corners/Equinox: NOT FINALIST
Why:
* Did not meet mandatory criteria (no TELNET)

Vendor #13: Four Corners/Emulex: NOT FINALIST
Why:
* Low-end unit unit lacks sufficient leads for our modem
  control applications (4 not enough, we need 5)
* High-end unit not price competitive at under 128 ports

 
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 

5. Results of terminal server evaluation period.

From the thirteen bids, four were selected to be evaluated
on site: Vendors #1 (R Squared/Xylogics), #2 (High-Tech/Xyplex),
#10 (BFA/Datability) and #11 (Lantronix/Lantronix).  The following
evaluation units were sent to us:

Xylogics Annex 3 
Xyplex MAXserver 1820 
Datability VCP-1000 with 8-port MC board 
Lantronix ETS-16

We installed each of these units and cabled them to our IDX-3000
terminal switch for testing purposes.  Each was configured to run
both TCP/IP and LAT, and each was configured to support both 
"dialin" and "dialout" connections.  Once connected, we let
interested users on campus know how to access these units for testing.

The Datability VCP-1000 did not work properly.  When initially 
cabled and powered up, it responded to terminal activity, but 
soon after that it ceased functioning.  A week of phone calls 
to the vendor produced no satisfactory results, and so the product
was stricken from the list of finalists and was shipped back to
the vendor.

We managed to get the other three terminal servers functioning.

The Lantronix proved to be the least capable of the three.  While it
did provide TELNET, rlogin and LAT terminal connections, users 
reported some dissatisfaction with it.  

One item was that, in rlogin to a Unix host, some host applications
will set the terminal into "raw" mode.  The Xylogics and the Xyplex
honored the mode change, so that the application would have access to
characters (such as XON and XOFF) that would otherwise be reserved for
use by the terminal server.  However, the Lantronix would not toggle
into "raw" mode, so that a user running an application that requires
use of the full character set is required to escape back to the server
and manually change the port settings.

Another complaint about the Lantronix was that there did not appear 
to be a way to customize the local line-editing characters.  Again, 
both the Xyplex and the Xylogics provided such a capability.

Another, more minor problem with the Lantronix was that it did not
display LAT services in alphabetical order.

Once during our evaluation period, the Lantronix seized up and would
not respond to commands.  We were required to power cycle the unit in
order to restore it to service.

Due to these problems, plus the fact that it met the smallest set of
our selective criteria, we decided that the Lantronix was
unacceptable and returned the evaluation unit to the vendor.

We then focused our evaluation efforts on the Xylogics and the Xyplex.
Users found both products generally acceptable.  Both systems worked
flawlessly from a hardware standpoint.

Significant differences were seen in the following areas:

* The Xylogics was seen as being considerably more responsive to
  flow-control commands when running rlogin
* The Xylogics' documentation set was easier to follow than Xyplex'
* The Xylogics supports queued access to outbound rotaries, while
  the Xyplex does not
* The Xylogics supports the capability of defining different
  IP addresses for different outbound rotary sets, while the
  Xyplex does not.
* The Xyplex supports reverse LAT, while the Xylogics does not
* The Xylogics offers the ability to define macros and menus for
  the user interface, while the Xyplex does not
* The Xylogics can log connects to a host, for accounting and security
  purposes, while the Xyplex cannot
* With Xyplex' implementation of TCP, an attempted connect to an
  unsupported port on the Xyplex was met with a TCP-level timeout, 
  rather than an immediate "connection refused" as was the case with
  unsuccessful connect attempts to the Xylogics.

We did encounter one unresolved problem with the Xyplex.  The
application consisted of using ZMODEM to upload a binary file from a
PC running MS-DOS to a Sun, via an rlogin session on the terminal
server.  The transfer occurred flawlessly when using the Xylogics
Annex, but aborted when using the Xyplex in an otherwise identical
configuration.  Xyplex technical support was contacted but was unable
to solve the problem.

The Xyplex supports TN3270, while the Xylogics does not.  A member of
our IBM systems staff evaluated the TN3270 feature.  While she found
that it worked, she found the feature generally unsatisfactory, due to
its slow performance and the fact that it supports neither Kermit file
transfers nor non-ANSI terminals. In her judgement, the behavior of
the Xyplex TN3270 would be considered unsuitable by a user accustomed
to an IBM 7171 terminal protocol converter.  When we factor in the
additional $53 per port cost of the Xyplex TN3270 option, we cannot
recommend this feature as a solution for connecting terminals to
IBM mainframes.

On the basis of the Xylogics' superior manageability and
configurability, and its more featureful implementation of TCP/IP,
and also its better price at high port concentrations, we therefore
selected the Annex 3 as our terminal server of choice.  However,
recognizing that there are niches that it cannot fill, we selected the
Xyplex MAXserver 1000 series as an alternate.

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 18:55:38 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

I wrote:
>Is it OK to use a net mask of 255.255.255.192 for each host on a subnet?
>Will the routing tables be kept correctly by my hosts...?

Just to clarify why I'm asking this, here's what "netstat -r" reports if
I try to add network number "192.129.71.64" to my static routing tables
(using SMIT under AIX, which doesn't give you an option of setting the
flags though I did specify "Destination TYPE" 'net' rather than 'host'):

Destination          Gateway              Flags    Refcnt Use     Interface
192.129.71.64        192.0.0.80           UGH      0      0       en0

According to my doc, the "H" item under flags means this is a route to
a host rather than a gateway to a whole subnet.  I want the router
with backbone address 192.0.0.80 (or actually 192.129.70.80, once the
backbone is renumbered) to "own" host IP addresses 192.129.71.{65-126}.

Here's an example of an existing, properly configured router which has
a Class C address all to itself:

192.0.1              192.0.0.50           UG       0      4426     en0

Note the lack of the "H" flag.

Sign me, somewhat confused,
-rich

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 20:14:33 GMT
From:      scott@ryptyde.UUCP (Scott McClure)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

That's not all.  Have you tried to connect to the NIC for just a mailbox
look-up?  It is insane!  I tried several times during the day, and the
early morning (0530 PDT) I counted 15 minutes from the "SunOS UNIX (nic)"
message to the "@" prompt.  The old DEC-2060 was faster than that.
This is supposed to be a Sun SparcServer 470.  It seems more like a 3/50....
I suppose it is par for the course for transfering something that major
to a different site and all, but it *is* annoying.  

--
INTERNET:  scott@ryptyde.cts.com                     | "It's casual to the 
ARPANET:   ryptyde!scott@nosc.mil                    |  most obvious observer!"
UUCP:      {crash nosc}!ryptyde!scott                |    - C.R. Clement     

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 20:41:42 GMT
From:      eddjp@edi386.UUCP ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   Getting an Internet Number


Please excuse my gross ignorance, but what is the current email address
one should use in attempting to obtain Internet numbers ?

-- 
Dewey Paciaffi      ...!uunet!edi386!eddjp

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 21:10:58 GMT
From:      blknowle@aragorn.jdssc.dca.mil (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: Van Jacobsen's ``Fat Pipe'' modifications...

Folks,

    Sorry it took so long for me to summarise, I got busy for a while, and
then forgot that I had promised to summarise.

    Anyway, here is the info I have gotten:

    1.  This code is not yet intended for general consumption -- it is
	currently intended to be used to test TCP-IP throughput, and used
	by people like Dave Borman at Cray and Van Jacobsen himself.
	Maybe some day it will be intended for general consuption, but
	that day doesn't look like its anytime soon.

	My observation is that if you are a true TCP-IP Guru (with a
	capital ``G''), or TCP-IP Speed Demon, then you might be able to
	request the stuff from Van or Dave and have reasonable
	expectations of getting their code.  On the other hand, if you fit
	this mold, then you probably should have been conferring with Van
	and Dave for a long time before this and helped them write this
	stuff in the first place.

    2.  It's not really any good for speeding up Local Area Network TCP-IP
	throughput -- it's meant to squeeze the last ounce out of Wide
	Area Network throughput (like two or more Ethernet LANs connected
	by a 1.5Mbps T1 link or two or more FDDI LANs connected by a
	45Mbps T3 link).  If you are looking to boost LAN speed, then you
	should probably put the BSD 4.3 Reno networking code (which can be
	anonymously ftp'ed from uunet, but where it's hidden in their
	hierarchy I haven't the foggiest), or you should go to your Vendor
	and scream in their ear.  Either way, the Van Jacobsen code won't
	help you too much.

    Sorry if I got any hopes up.

 Please respond via e-mail.  I will summarize and re-post, if appropriate.
 _________________________________________________________________________
| Brad Knowles (ACM # 3351806) | Internet:  blknowle@frodo.jdssc.dca.mil  |
| System/Network Administrator |       Or:  blknowle@aeneas.jdssc.dca.mil |
| DISA/DSSO/JNSL               | Ph: (703) 693-5849   Fax: (703) 695-7234 |
| The Pentagon, Room BE685     |============== DSN: 223-5849 =============|
| Washington, D.C.  20301-7010 | Speaking from, not necessarily for DISA! |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NOTE:   Please do *NOT* use "R"eply or "A"nswerback -- one of our two
	nameservers is semi-broken and the mail may or may not get to me.
	Please use one of the two addresses supplied in my signature.

P.S.    I am CC:ing Dave and Van, with hopes that they will post a more
	official statement on the status of this code and its purpose(s).

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 21:35:46 GMT
From:      6600prao@ucsbuxa.ucsb.edu (Parik Rao)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Experiences w/ large-scale labs & routing


We have a few Macintosh Lab's and one PC lab we'd like to phase into the
Internet.  During the summer, we have tried various configurations and
met mostly with failure.  At this point, we are gathering suggestions
from other's who have had similiar problems or configurations.

First, the diagram:  

                      <---- backbone --->
                               |
                       buffered repeater
			       |		<-- ethernet
			   Router  (*) 
             ethernet ->    |  |		<-- ethernet
		   PC-lab___|  |
			       |
			   ____|_________
			  |         |    |	<-- still ethernet
		        PC Router  PCR   PCR		
 			 |  |      | |   | |__  <-- all localtalk
                         |  |      | |   |   |
                       Lab  Lab  Lab Lab Lab Lab

(*) = We tried putting a PC-Router here, but it chokes and dies.  I've
      been told its due to the large # of subnets below it.

Each "Lab" is its own subnet, and the ethernet side of the router's are all
on the same subnet (for a total of 8 subnets).
 
We're currently looking into replacing the top Router with a Cisco router,
but we are VERY open to suggestions.  

The bottom localtalk PC-routers function PERFECTLY -- they were each
placed behind the buffered repeater (in place of the master outer) and
were able to let the Macintosh's talk to the outside world thru Telnet (
AdminTCP is set to LocalTalk). 

If anyone has questions on PC-Routers, feel free to ask, we've sort of
become one with them.  :)  I'm hesitant for a software solution at this
point (i.e., FTP's router or Wallagongs or Vance Morrison's commercial
[vaporware]) as software hasn't been ideal so far.  We do have Cisco
AGS+'s placed around the campus and they work great.  But $11+k is $11+k...

Any responses will be archived for other's.
--
Parik Rao         [.]       prao@bluemoon.ucsb.edu, prao@hcfmail.ucsb.edu,
Major in Comp-Sci  |        prao@voltaire.ucsb.edu, 6600prao@ucsbuxa.ucsb.edu
and Sorcery        |        The world is coming to an end.  Please logoff. 

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 21:39:25 GMT
From:      dmc@DOC.LANL.GOV (dave clark)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove me from this mailing list.  dmc@doc.lanl.gov

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 22:14:08 GMT
From:      mkoblas@sun422.nas.nasa.gov (Michelle R. Koblas)
To:        ba.windows.x,comp.windows.x,comp.protocols.tcp-ip
Subject:   Graphical/Enhanced FTP??

Hi All!

I'm interested if anyone out there knows of any graphical (unix-based)
versions of ftp anywhere?  I'm starting a project to incorporate some
local enhancements (UltraNet modifications, multiple data channels,
etc.), as well as put a nice graphical interface on ftp for our users
here and I'd like to hear if there's anyone else working on a similar
such beast.

Also, if there are any ftp enhancements that you'd like to see (or
that someone's done), I'd appreciate hearing about them.  I'd like to
make a program that's useful to everyone and not just localized to our
site.

Thanks for any pointers or comments!! ;-)

Michelle

p.s.  Please send responses via e-mail.  I don't always manage to keep
      up with the newsgroups.
-------------------------------------------------------------------------
Michelle R. Koblas                      Internet: mkoblas@nas.nasa.gov
Computer Sciences Corporation
NASA Ames Research Center M/S 258-6     Phone:    415/604-4514
Moffett Field, California  94035

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 22:20:28 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: communication servers and UUCP

tkevans%fallst@wb3ffv.ampr.org writes:
>Just add to your chat script all the necessary stuff to negotiate
>through the terminal server.  ...Below is an actual example (system
>name and real password X'd out, which logs into some kind of
>terminal server, then accesses a UNIX system and starts up UUCP:

Can I somehow do this with my existing network, using 'rsh' across
TCP/IP?  We've got several Unix systems on a LAN, and only one of them
has modems on it.  What would the Devices and Dialers files look like
for a remote-shell?

(I gather from your example that installation of the given terminal server
creates remote "teletype" device files in /dev.  That's not the model
used for standard TCP/IP; you have to go through the socket library rather
than directly to a device file.)

-rich

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 91 22:49:22 GMT
From:      april@NISC.SRI.COM (April Marine)
To:        comp.protocols.tcp-ip
Subject:   List Transition


The TCP-IP mailing list has been moved.  As part of the transition
of NIC services from SRI to GSI, these lists were moved from the host
nisc.sri.com to the host NIC.DDN.MIL.  All normal list traffic should
now be redirected to that host, and requests for changes sent to
tcp-ip-request@nic.ddn.mil.  During the transition period from
26 September through 1 October, traffic on the list maybe have been
disrupted; we apologize for any inconvenience or delay this may have
caused.

Some people have mentioned that they have received multiple copies of
messages.  If the problem of receiving multiple copies of particular
messages is chronic and does not appear to cluster around the dates of
the transition, it is likely that you appear both on the general
mailing list and on some "exploder" list which receives input from the
general list and then remails to a list of users.  Check the
forwarding fields in the mail header for a "resent-from" field.  If
one exists in some copies of the messages, but not all, trying sending
mail to the postmaster at the responsible host listed in that field.

Please do not reply to this message.  Direct all further list
maintenance business to tcp-ip-request@nic.ddn.mil.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 00:15:50 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <1991Oct2.165224.16234@CSD-NewsHost.Stanford.EDU> vaf@Valinor.Stanford.EDU (Vince Fuller) writes:
>Connectivity to the "old" NIC was via a fairly short, all
>T-1 path through BARRNet and the NSFNet. It would appear that the "new" NIC
>is solely connected to the MILNET, with all of the reliability and performance
>that such a connection implies (as an example: sending a bunch of PING's to
>NIC.DDN.MIL just a few minutes ago resulted in 16 of 18 packets dropped, with
>RTT's of 6730 and 10683 ms for the two packets which survived...).

Ironic, isn't it?

Just a couple of months ago the SIMTEL20 DEC-20 moved off Milnet to
Westnet.  The line is still 56KB, but the difference is that instead
of being unreliable it's merely slow.  There's been some talk of
fractional T-1 but with politics going on who knows.

Now NIC has moved onto Milnet and become a SUN-4 (a CPU that should be
4 times faster than a DEC-20); with the result that it has become slow
even more unreliable that SIMTEL20 at its pre-June '91 worst, and
handles few users.

Win one, lose one.  I guess it's called progress.

 -+-+-   | -++-  --|--    /__ Mark ("Gaijin") Crispin "Gaijin!  Gaijin!"
+-|-|-+ -+-++++  +-|-+   /  / R90/6 pilot; DoD #0105  "Chigau. Omae ha gaijin."
+-+-+-+  |\||||  |===|  /  /  Atheist & Proud         "Iie, boku ha nihonjin."
 --|--  /| |/\| -+===+-   /\  (206) 842-2385/543-5762 "Souka. Yappari gaijin!"
  /|\    | |__|  /   \   /  \ FAX: (206) 543-3909
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanakute mo shiranai yo.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 01:58:14 GMT
From:      jrjones@MR.NET (James R. Jones)
To:        comp.protocols.tcp-ip
Subject:   class b question



hello everybody,

At my company I am about to set up a large ethernet ip network.  I plan
on using a class B number.  Somewhere long ago I read that when you 
subnet a class b network the you should not start at 1 and go up but     
start at 248 and go down, or something like that.  Could someone please
refresh my memory on the issuses. 

jim

jrjones@mr.net

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 03:49:38 GMT
From:      sean@sdg.dra.com
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <186@ryptyde.UUCP>, scott@ryptyde.UUCP (Scott McClure) writes:
> That's not all.  Have you tried to connect to the NIC for just a mailbox
> look-up?  It is insane!  I tried several times during the day, and the
> early morning (0530 PDT) I counted 15 minutes from the "SunOS UNIX (nic)"
> message to the "@" prompt.  The old DEC-2060 was faster than that.
> This is supposed to be a Sun SparcServer 470.  It seems more like a 3/50....
> I suppose it is par for the course for transfering something that major
> to a different site and all, but it *is* annoying.  

Grrr. Why are you blaming the GSI's Sun SparcServer?  GSI may well be performing
perfectly fine, but some network provider elsewhere not under their control
is losing packets left and right.  I know when I get complaints like this, it
usually turns out to be some gateway half-way across the country, maybe even
a different country.

Its damn annoying for everyone, but its even more annoying to get blamed
for something that isn't your fault.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@sdg.dra.com, Voice: (Work) +1 314-432-1100

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 03:55:48 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP over ISDN

In article <1991Oct1.145216.13897@dvnspc1.Dev.Unisys.COM>
ja@dvnspc1.Dev.Unisys.COM (Jak Amado) asks about TCP/IP over ISDN and says:
 > To judge from the titles in the RFC index (as of August '91, i.e. up to
 > RFC 1243), there doesn't seem to be any RFC related to ISDN. Did I miss
 > any?

Let me rephrase your question: Are there any RFC's about running TCP/IP
over telephone lines?

The questions are the same.  ISDN is just another way to access the public
telephone network.  RFCs that are appropriate include RFC1172 (PPP) and
RFC1055 (SLIP).  The key here is that the public data network is not an IP
network and IP is not part of ISDN.

ISDN does include X.25 and I can believe that some day you'll be able to get a
nailed up B channel running Frame Relay.  The IPLPDN (IP over Large Public
Data Networks) working group is hashing out IP over Frame Relay now.

Since most ISDN services are switched services there is an issue of when do
you make a call and how do you make the call.  This problem has been solved
with modems for accessing the analog network, there's no reason similar
solutions won't work on the digital network.

// marc
-- 
marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 04:26:14 GMT
From:      bvj@ESD.3Com.COM (B.V. Jagadeesh)
To:        comp.protocols.tcp-ip
Subject:   Silicon Valley Networking Conference - 92 Call for Papers


                    Silicon Valley Networking Conference - 1992
		    -------------------------------------------
			   Call For Papers

Papers are solicited for the Silicon Valley Networking conference (SVNC-92)
to be held April 27th to 29th 1992 at Santa Clara convention center,
Santa Clara CA 95052, USA. 

Papers are solicited in the following areas.

Distributed Systems
Internetworking
Network Management
X-windows
Advanced File servers
High Speed Networking
Standards activities (IEEE, CCITT, IETF etc ) 
Network Monitors
WireLess Networking

SVNC typically attracts over 400 engineers every year and is a nice forum
to discuss system design architecture and solutions to complex networking 
problems.

If you are interested in presenting a paper, please send me an abstract
of the paper before Oct-23rd 1991. If accepted for submission, a rough draft 
of the paper should be submitted before Dec 15th 1991 and camera ready copy
should be submitted before Jan 25th 1992. 
Please include your Address, Tel number and Fax Number in the abstract.

Thanks
/Jagadeesh
bvj@3Com.com
(408)-764-5169

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 06:03:06 GMT
From:      bob@morningstar.com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   PPPointless? (was: Using Wide-Area Point-to-Point Links for Computer Networking (I))


   From: martillo@azea.clearpoint.com (Joachim Carlo Santos Martillo)
   Date: Wed, 2 Oct 91 12:42:06 EDT

      From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
      Date: 30 Sep 91 14:53:58 GMT

      ...You can always get stuck like the rest of us - run PPP when
      you need to talk to another vendor, and your own protocol when
      that won't work for some reason.

   This is our strategy as well.  It makes PPP seem rather pointless
   though and adds development time and cost to products.  But I guess
   if customers don't mind paying more money without getting extra
   bang for the buck, who am I to argue?

The point of PPP is inter-vendor interoperability.  It may(*) add
development time and cost when compared with the inter-router and
inter-bridge protocols you already have implemented, and it may not
already do everything your own protocol does as well as your protocol
does it.

But the extra bang for the buck that the customer is paying for comes
in the ability to talk to boxes made by just about any other vendor
you find, provided everyone else can also talk PPP.  No single vendor
can provide solutions at every point along the price/performance
curve, so the existence of other compatible products enhances the
usefulness of each.

cisco sells more routers into hubs because sync PPP exists for the
leaf nodes that have only a few UNIX machines, but who still want
leased-line bandwidth.  Telebit sells more NetBlazers and modems into
hubs because on-demand dialup PPP exists for low-budget remote sites.
The IP connectivity vendors see increased demand for their services
because standard protocols make it easier for potential customers to
get on the air.  The customer wins all around because she has a wider
field of complementary choices.

(*) PPP may actually reduce development time and cost, if
interoperation is an explicit goal of your development effort.  For
example, our sync PPP succeeded completely on the first try with
routers from three different vendors so far, which makes us optimistic
about more.  Our async PPP has been tested against six async
implementations, and the only major protocol problem in recent memory
(dealing with Merit's dialup dynamic IP address assignment) was easily
fixed within minutes.  Once we got PPP basically right, it became
easier and easier to work with each new peer, because most require no
more changes to our end.  We're looking forward to Interop, where we
hope to test against several others, including Clearpoint.

This sort of "my connection list is bigger than yours" competition
isn't just macho chest-beating, it's the reality of life in the modern
networking business.  We were able to bring our product to market far
sooner because of the previous existence of a well-defined and popular
protocol.  In fact, it's probably safe to say that if PPP hadn't
already existed, we wouldn't have entered the market at all, because
we would have needed to implement each vendor's proprietary protocol
in order to be useful at all, which would have been prohibitively
expensive.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 06:05:06 GMT
From:      brian@ray.lloyd.com (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   PPPointless? (was: Using Wide-Area Point-to-Point Links for Computer Networking (I))

Sr. Martillo:

It is clear that you do not like PPP.  Fine.  It is also clear that
many of us believe that PPP is very important.  Equally fine.  I also
suspect that neither side of this argument is likely to convince the
other.  Given that this argument re the relative merits of PPP vs.
slither/slide is unproductive, why don't we relinquish the bandwidth
taken up on the ietf-ppp and comp.protocols.tcp-ip mailing lists?  If
this conversation is interesting to a sufficient number of people I
will be willing to create PPP-flame and SLIDE-flame mailing lists.

Brian Lloyd, WB6RQN                                     Lloyd and Associates
Network Architect                                       3420 Sudbury Road
brian@ray.lloyd.com                                     Cameron Park, CA 95682
voice (916) 676-1147

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 08:53:45 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Cart before the Horse

> IEEE did not define the Ethernet.  They redefined parts of it.  The Ethernet
> was defined by Digital Equipment Corporation, Intel, and Xerox.  The
> definition of the 10-megabit Ethernet far preceeded any silicon.  In fact,
> some of the arguments over how it was to work considered whether sufficient
> silicon could be projected as available in a practical time frame, but the
> design remained optimistic and future-looking.  The first full-power Ethernet
> chips came from Intel and AMD/Mostek.  When I got involved in Ethernet
> specification work for Ethernet version 2, around 1980, Intel was just getting
> to the point where they weren't interested in considering changes to the
> specification.  It was only at that point that a not-quite-existing chip had
> any direct effect, and that was limited and somewhat resented.  The AMD/Mostek
> chip came later, partly in reaction to Intel's stubborness.  Other chips that
> came out in the early 80s were minimum function and had no effect on the
> design.
 
> I was a latecomer to the process, and I remain impressed by the accomplishment
> of the original designers.  Their foresight was impressive, their mistakes
> relatively few, and their effect on the industry enormous.
 
> 	Bob

I assume you mean the definition of Ethernet preceded the development
of custom ethernet chips or chip sets, neither of which are necessary
to the implementation of ethernet.

I was under the impression that ethernet was based on work done at MIT
when some hardware hackers wanted to connect computers together using
coaxial cable which had been abandoned by a cable TV firm.  Also there
was a lot of input from some work done at the University of Hawaii.  I
would argue that you really cannot design beyond the capability of the
technology and that the known capabilities of hardware should guide
and sometimes defines what can be architected.  Designing ethernet
chip sets might have pushed the limits of integration technology at
the time but ethernet was certainly within the range of already
existent technology at the time it was designed.

In this case of PPP, I detect know awareness of some of the serial
communications controller design trends.  Also, I am disturbed that
few of the people who worked on the standard seem to have investigated
earlier attempts like Cypressnet which dealt with the problem of
intergrating point-to-point serial communications links into the DOD
Internet Architecture.

Joachim Carlo Santos Martillo Ajami

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 09:11:21 GMT
From:      martillo@azea.clearpoint.com (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: PPPointless? (was: Using Wide-Area Point-to-Point Links for Computer Networking (I))

>    From: martillo@azea.clearpoint.com (Joachim Carlo Santos Martillo)
>    Date: Wed, 2 Oct 91 12:42:06 EDT
 
>       From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
>       Date: 30 Sep 91 14:53:58 GMT
 
>       ...You can always get stuck like the rest of us - run PPP when
>       you need to talk to another vendor, and your own protocol when
>       that won't work for some reason.
 
>    This is our strategy as well.  It makes PPP seem rather pointless
>    though and adds development time and cost to products.  But I guess
>    if customers don't mind paying more money without getting extra
>    bang for the buck, who am I to argue?
 
> The point of PPP is inter-vendor interoperability.  It may(*) add
> development time and cost when compared with the inter-router and
> inter-bridge protocols you already have implemented, and it may not
> already do everything your own protocol does as well as your protocol
> does it.

PPP provides a very low grade, low performance, relatively expensive,
relatively inflexible sort of interoperability.

> But the extra bang for the buck that the customer is paying for comes
> in the ability to talk to boxes made by just about any other vendor
> you find, provided everyone else can also talk PPP.  No single vendor
> can provide solutions at every point along the price/performance
> curve, so the existence of other compatible products enhances the
> usefulness of each.

But in fact PPP does not provide a solution if a router is to
connect to a bridge over a point-to-point link because there is
no way to tell the router within PPP that it should send bridging
frames rather than networking frames. 

> cisco sells more routers into hubs because sync PPP exists for the
> leaf nodes that have only a few UNIX machines, but who still want
> leased-line bandwidth.  Telebit sells more NetBlazers and modems into
> hubs because on-demand dialup PPP exists for low-budget remote sites.
> The IP connectivity vendors see increased demand for their services
> because standard protocols make it easier for potential customers to
> get on the air.  The customer wins all around because she has a wider
> field of complementary choices.

Clearpoint makes a line of 4 ether 1 WAN port bridges which plug into
EISA and VME busses.  They are really cheap and since leaf nodes
rarely remain leafs and using unix boxes as packet switches is not a
cost effective approach with flexibility or growth potential, I would
recommend that anyone with this particular connectivity problem look
into this particular product line or similar products from other
vendors.

> (*) PPP may actually reduce development time and cost, if
> interoperation is an explicit goal of your development effort.  For
> example, our sync PPP succeeded completely on the first try with
> routers from three different vendors so far, which makes us optimistic
> about more.  Our async PPP has been tested against six async
> implementations, and the only major protocol problem in recent memory
> (dealing with Merit's dialup dynamic IP address assignment) was easily
> fixed within minutes.  Once we got PPP basically right, it became
> easier and easier to work with each new peer, because most require no
> more changes to our end.  We're looking forward to Interop, where we
> hope to test against several others, including Clearpoint.

How do you handle the bridging versus network packet negotiation problem?

> This sort of "my connection list is bigger than yours" competition
> isn't just macho chest-beating, it's the reality of life in the modern
> networking business.  We were able to bring our product to market far
> sooner because of the previous existence of a well-defined and popular
> protocol.  In fact, it's probably safe to say that if PPP hadn't
> already existed, we wouldn't have entered the market at all, because
> we would have needed to implement each vendor's proprietary protocol
> in order to be useful at all, which would have been prohibitively
> expensive.

PPP does not address a whole host of connectivity problems which are
sine qua non to wan connectivity. Now if your own proprietary
protocols address these problems then you are merely using PPP to get
a foot in the door so that you can lock your customer into a
proprietary system.  I actually believe PPP is useful for this, but I
would hardly argue that this procedure is equivalent to providing
interoperability.

Joachim Carlo Santos Martillo Ajami

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 10:27:49 GMT
From:      tony@mpg.phys.hawaii.edu (Antonio Querubin)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <1991Oct2.165224.16234@CSD-NewsHost.Stanford.EDU> vaf@Valinor.Stanford.EDU (Vince Fuller) writes:
>all T-1 path through BARRNet and the NSFNet. It would appear that the "new" NIC
>is solely connected to the MILNET, with all of the reliability and performance
>that such a connection implies (as an example: sending a bunch of PING's to
>NIC.DDN.MIL just a few minutes ago resulted in 16 of 18 packets dropped, with
>RTT's of 6730 and 10683 ms for the two packets which survived...). Unless GSI
>decides to get a non-MILNET Internet connection, I wouldn't expect performance
>to improve any time soon (remember, though, that NIC.DDN.MIL's primary mission
>is to support MILNET users, so perhaps this is intentional).

I have found over the past year that routes on MILNET are extremely unreliable.
It isn't necessarilly equipment that is bad.  It's the people running the 
machines who seem to misconfigure them as a general rule.  Contributing to the
problem is the fact that it's not easy trying to figure out who to report the
problem to.  And if you do, there's no guarantee that the person receiving the 
message will understand it's importance or what needs to be done about it.  
This past year I spent a few weeks trying to figure out why connections to a 
particular MILNET host were always being dropped in the middle of a session.  
Along the way, I ran into some incorrectly configured nameservers, an
incorrectly configured interface on the remote host, unresponsive (or 
unintelligent) system managers, and then finally a bunch of intervening routers
that seemed to changed the route to the remote host every so many minutes (or
just make it plain unreachable).

Somewhere between GSI and DCA there ought to be someone empowered to clean up 
the mess.  The poor connectivity to a major nameserver is just one symptom of a
very ill network.
-- 
Antonio Querubin  
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 11:07:52 GMT
From:      matthew@ooc.uva.nl (Matthew Lewis)
To:        comp.protocols.tcp-ip
Subject:   Netgroups equivalent with NIS?

Hello,

We are converting from 3Com to BW NFS for out DOS machines, using a SPARC
2 as server.  We do not care to run NIS, but are starting to get a rather
horrible looking exports file.  My question is, has anyone come up with a
way to do the equivalent of wildcarding in /etc/exports?  Or to simulate
netgroups?  I want to permit any machine that reverse resolves to my own
domain to mount the user volumes, without letting just anyone mount.

I will summarize if people respond via e-mail.

Thanks,

Matthew Lewis

-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 12:10:48 GMT
From:      ercm20@castle.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostby* routines

In reply to:
> hobbit@FTP.COM (*Hobbit*) writes:
> > Is it really the case that most gethostbyaddr() implementations return only
> > the canonical name in the hostent [hostinfo? whatever] struct, without filling
> > in the aliases as well? ...

I wrote:
> ... there is no way for the NS to give the resolver
> more than one name (unless the resolver does the deprecated inverse
> lookup rather than looking in in-addr.arpa )

A colleague pointed out that even with an inverse lookup it would still
require a search of the entire DNS tree to give back *all* aliases to a
name.  Logically it's the equivalent of looking in all the world's hosts
files to see if anyone has any private aliases for your address.  The
DNS can't do that either. 

Sam Wilson
Computing Service
The University of Edinburgh, Scotland

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 13:27:09 GMT
From:      cohenj@silicon.cs.unc.edu (Jonathan Cohen)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.unix.questions
Subject:   network monitoring tools


I'm looking for some ways to monitor network statistics on an ethernet of
workstations.  For example, I'd like to know how much traffic is going 
across the net and possibly how much this effects the workstations that
are not the intended recipients of the packets.

Does anyone know of some common tools that might be useful for such
things?

Jonathan Cohen

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 13:42:35 GMT
From:      dengholm@IASTATE.EDU (Daniel M Engholm)
To:        comp.protocols.tcp-ip
Subject:   Re: WD8013EP Packet Driver Question...

From the file INSTALL.DOC which comes in the WD8003PKDR distribution:

2. The driver will operate with the following 8003/8013
   family LAN adapters:

   Ethernet     8003E
                8003EBT
                8003EB
                8003EP
                8013EBT
                8013EW
                8013EP

  Ethernet Twisted Pair:

                8003WT
                8003W
                8013EW
                8013W

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 13:46:14 GMT
From:      blknowle@aragorn.jdssc.dca.mil (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

Well,

    I haven't had any problem at all -- in fact, response time has greatly
improved for me.  I think this is because the "new nic" is located
somewhere here in Northern Virginia, relatively close to where I am.
Since it has moved away from Hawaii (which is where I believe Brigham
Young University is, please correct me if I'm wrong), it is not surprising
that response time should be lower for folks from the left coast.

    Perhaps we should ask these guys to maintain both a left coast and a
right coast presence, thus keeping response times reasonable for everyone
in the U.S.?
 _________________________________________________________________________
| Brad Knowles (ACM # 3351806) | Internet:  blknowle@frodo.jdssc.dca.mil  |
| System/Network Administrator |       Or:  blknowle@aeneas.jdssc.dca.mil |
| DISA/DSSO/JNSL               | Ph: (703) 693-5849   Fax: (703) 695-7234 |
| The Pentagon, Room BE685     |============== DSN: 223-5849 =============|
| Washington, D.C.  20301-7010 | Speaking from, not necessarily for DISA! |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NOTE:   Please do *NOT* use "R"eply or "A"nswerback -- one of our two
	nameservers is semi-broken and the mail may or may not get to me.
	Please use one of the two addresses supplied in my signature.

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 14:39:45 GMT
From:      Y.Murayama@CS.UCL.AC.UK ("Yuko Murayama ", +44-71-387-7050 ext.3721)
To:        comp.protocols.tcp-ip
Subject:   measurement of the Ethernet ARP operation


Has anyone done measurement of the ARP Request and Rply 
transaction over the Ethernet?

Since I am not on this list, please include my address in your reply.

Yuko
Y.Murayama@cs.ucl.ac.uk

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 15:55:58 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <1991Oct3.102749.25009@news.Hawaii.Edu> tony@mpg.phys.hawaii.edu (Antonio Querubin) writes:
   Somewhere between GSI and DCA there ought to be someone empowered
   to clean up the mess.  The poor connectivity to a major nameserver
   is just one symptom of a very ill network.

Is it time yet for the worldwide Internet to stop depending upon the
good graces of the US DoD for a very visible and critical single point
of failure?  Is it time yet for the root of the domain tree (and the
whois server, and the registrar of names and dispenser of addresses,
and the home of the mailing list about the networking technology
itself) be entrusted to some other entity?

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:06:40 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Securing system on network.

I've got a system that is accessed by the outside would and I would like
to prohibit it from accessing the rest of the network but still allow
other systems on the network to access it.  Does anyone know of a paper
or book that would explain how I can do this.  I just want to make sure
I don't miss anything.  Thanks and ttyl.

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

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:18:45 GMT
From:      art@OPAL.ACC.COM (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Cart before the Horse

>I was under the impression that ethernet was based on work done at MIT
>when some hardware hackers wanted to connect computers together using
>coaxial cable which had been abandoned by a cable TV firm.  Also there
>was a lot of input from some work done at the University of Hawaii.  I
>would argue that you really cannot design beyond the capability of the
>technology and that the known capabilities of hardware should guide
>and sometimes defines what can be architected.  Designing ethernet
>chip sets might have pushed the limits of integration technology at
>the time but ethernet was certainly within the range of already
>existent technology at the time it was designed.

Let`s try to keep the history straight.  Ethernet was born in the
Silicon Valley at Xerox PARC.  Bob Metcalfe and Dave Boggs were
adapting some of the broadcast technology of the Aloha Packet Radio
System to coax cable (not hackers, but true pioneers of today's
technologies).  The original Ethernet ran at 3 Mb/s and had 8 bit
addresses, but was basically the same access protocol we have
today.  This happened in the mid 70s.  Research on ring technologies
(notably the Cambridge ring) started about this time.  Then Digital,
Intel and Xerox (DIX) collaborated on the first successfull open LAN
standard, Ethernet V1.  This standard was updated within a couple of
years to Ethernet V2 with minor changes.  At about the same time as
Ethernet V2, IEEE was looking at defining THE LAN standard.  IEEE eventually
adopted several LAN technologies, including 802.3.  802.3 is directly
evolved from Ethernet, and is compatible enough to be run with
V2 Ethernet on the cable and most hardware, but they really are
different protocols (both in electronic details and protocol details).

>In this case of PPP, I detect know awareness of some of the serial
>communications controller design trends.  Also, I am disturbed that
>few of the people who worked on the standard seem to have investigated
>earlier attempts like Cypressnet which dealt with the problem of
>intergrating point-to-point serial communications links into the DOD
>Internet Architecture.

Also, remember that PPP was originally (and still is) a response to
the shortcomings of SLIP.  Somewhere along the way PPP got expanded
to also cover Synchronous links.  Whether this was a good decision
can be argued both ways and is now history.  The replacement for SLIP
was definitely needed.

>Joachim Carlo Santos Martillo Ajami

Art

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:29:57 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <9110021642.AA09113@azea.clearpoint.com> martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo) writes:
>> B) Defining "standards" based on available chips is backwards, sort of.
>
>Really, didn't the IEEE define the ethernet standard long after
>ethernet chips were available?

No, DEC/Intel/Xerox defined the Ethernet standard well before any chips
for it were available.  IEEE blessed the result (with minor changes) after
it was already a roaring success.

Note that it often makes sense to set standards based on well-proven
existing practice rather than trying to invent them out of thin air.
-- 
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:37:29 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Specifying "wild" local IP addresses for UDP/TCP

In article <9110011805.AA09950@dino.alias.com> mandrews@alias.com (Mark Andrews) writes:
>            An application program MUST be able to specify the IP source
>            address to be used for sending a UDP datagram or to leave it
>            unspecified (in which case the networking software will
>            choose an appropriate source address).
>
>I gather that if the source address is left unspecified, it is considered
>"wild". How is this address represented; i.e. what is it's IP address?

Why do you think it has to be represented?  The application program must
be able to tell the networking software, *somehow*, that it doesn't care
what source address is used.  This is not necessarily done by giving some
magic "don't care" value for the address; it may be done by setting a
separate flag in some manner.

The only place where the representation must be fixed is on the network,
and the issue doesn't arise there, because the networking software will
have picked one of the host's IP addresses in response to the application
saying "I don't care which one you use".
-- 
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:40:44 GMT
From:      I.G.Batten@fulcrum.bt.co.uk (Ian G Batten)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert to legitimate network address

In article <mtnbicg@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> Why not borrow a single workstation for a few weeks or months (you
> better hope not years) and make it a gateway between your old class A and
> the new class B?  Don't tell it anything about your subnet mask; just let

We did this when converting from a bogus class A to a legitimate class
C.  Because I couldn't quickly see how to get a Sun 3/50 (one interface
only) to route between two networks on the same cable I used slip
between a pair of machines on the same wire.  Transitioned thirty-odd
machines over two days and then unplugged the slip.

ian

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:45:30 GMT
From:      diro@edison.phone.North.DE (Dirk Rode)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP over ISDN

Shalom,

ja@dvnspc1.Dev.Unisys.COM (Jak Amado) writes:

>I am investigating uses of TCP-IP over ISDN. Regarding this subject, I am
>looking for information on any:
>   - RFC
not yet issued

>   - implementation
several implementations (not compatible)

>   - study
>   - standard
see above

>   - draft standard
 available from ftp.informatik.uni-dortmund.de (isdn Draft)

>   - work under way
 they are working on this standard. First talks were in March (I think).
If you need more informations, you have to contact - for example - 
ms@unido.uucp
 We use our own implementation. It works fine and is defined mostly along
the PPP.

>   - justification, market analysis
>   - ideas, thoughts, bits of thoughts
>   - etc.

 Products are available for example by BinTec in Nuernberg (W-8500, Germany).

Dirk
-- 
*  Dirk Rode              * dirk.rode@arbi.Informatik.Uni-Oldenburg.DE *
*  Zwischenahner Str. 64  * Bitnet:   077481@Doluni1.Bitnet            *
*  2910 Howiek            * Privat: diro@edison.phone.North.DE         *
* Die sich des Vergangenen nicht erinnern, sind dazu verurteilt,       *
*   es noch einmal zu erleben.                           Santayana     *

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 16:55:00 GMT
From:      Sabo@DOCKMASTER.NCSC.MIL
To:        comp.protocols.tcp-ip
Subject:   gethostbyaddr Utility Anyone?


Does anyone know of a utility program in the public domain which can
return a domain name given an IP address?  This would be sort of a
reverse nslookup.  I know about etherhostprobe which uses gethostbyaddr
but I was looking for a more generic utility.


L.  Michael Sabo SSDS, Inc.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 17:00:06 GMT
From:      backman@FTP.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: Distributed file systems and TCP


 >> Overhead!!


Nope; the overhead of TCP's code path is probably not much greater than the
overhead of the IP reassembly code required for 8K UDP packets.  The
additional fraction of a microsecond the code might take is irrelevent
compared to the total end to end time of the packet.

 >> It is quite clear that distributed file systems can live very well
 >> without TCP. In most cases (if not all) the reply to the file system
 >> call acts as the acknowledgement also and this renders the specific ack
 >> to the call as required by TCP unnecessary. In most distributed file 
 >> systems completion of the call is the responsibility of the client and
 >> so the client can always make an extra call in case of a lost reply.
 >> Things being so, I feel that distributed systems are well off without TCP
 >> and the extra traffic.
 >> 
 >> Isn't NFS good enough with just UDP?
 >>
Nope;  and here's why..

------------------start of included message---------------------------

tests were run from a 386/20 with OS/2 1.21 against a Sun Sparc running
Something.  The test is a benchmark program run from the DOS box of
OS/2 so the performance numbers are somewhat low.  The hiccups in the UDP
read timings are a known problem with my machine due to a piece of junk
3C503 being overrun by a fast Sun sending me 4 or 8K reads or writes.

In all cases values are number of seconds to move a 1 Meg file between
OS/2 and the Sun.  Lower is better!

The pocket analysis is as follows:
NFS/TCP is 10-20% slower than NFS/UDP when everything is going well.
However; when the net turns lossy; as demonstrated by the UDP 4K
random reads & 8K sequential reads, TCP is a clear winner.



LAN  Name: somewhere
Test Type: LAN Benchmark TIMED Test
Load Type: milk8 (UDP/NFS)
Evaluator: Joe Blow
Comment  : 
File size:    1 Mbytes

Record size (bytes):    1 Kbytes    2 Kbytes    4 Kbytes    8 Kbytes   16 Kbytes
Append to file     :       108.0        62.0        33.0        17.0        17.0
Sequential read    :        18.0        11.0        76.0     ***35.0**       5.0
Sequential write   :        39.0        26.0        14.0         9.0         8.0
Random read        :        20.0        12.0    ***196.0**       5.0         5.0
Random write       :        61.0        32.0        17.0        10.0         8.0
  Total            :       246.0       143.0       336.0        76.0        43.0

Total test time    :  844.0 seconds



====  PC MAGAZINE Labs LAN Benchmark Program V2.00  ====

LAN  Name: somewhere
Test Type: LAN Benchmark TIMED Test
Load Type: TCP/NFS Milk8
Evaluator: Joe Blow
Comment  : 
File size:    1 Mbytes

Record size (bytes):    1 Kbytes    2 Kbytes    4 Kbytes    8 Kbytes   16 Kbytes
Append to file     :       117.0        66.0        39.0        19.0        18.0
Sequential read    :        22.0        16.0        11.0         6.0         6.0
Sequential write   :        47.0        26.0        14.0        11.0         9.0
Random read        :        23.0        14.0        11.0         6.0         6.0
Random write       :        63.0        34.0        18.0        11.0         9.0
  Total            :       272.0       156.0        93.0        53.0        48.0


Total test time    :  622.0 seconds


---------------------------end of included message---------------------------

If anyone is still with me; look at the 4K UDP random read & 8K UDP sequential
read (marked by star's).  The Sun was blazing out back to back fragments
faster than my circa-1984 design 3C503 could handle.

In any case; while UDP averaged out 10-20% faster for most cases, consider
what happened to it in the worst case.  Consider also that for the 195
seconds it took to move 250 4K UDP packets in the worst case scenerio
above my PC caused the Sun to generate a whole load of extra 4K UDP packets;
making it a lousy network neighbor due to my PC's inability to handle
the back to back packets.

That in a nutshell is why NFS/TCP is useful.  Networks are lossy especially
as the number of hops from end to end increase. Networks are lossy when you
have a fast transmitter and a slow receiver.  I wonder how well all those
old Sun 3's do reading from a Sparc with 8K read size?

I'm not quite the religious NFS/TCP zealot that James is, but there certainly
are good reasons for running NFS over TCP in certain situations.  On the
other, if you have a workgroup of Sparc's on a LAN stick with UDP.  In any
case before making statements like "it is quite clear..." please give me
some empirical data as part of the opinion.


                                        Larry Backman
                                        backman@ftp.com




-------

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 17:00:46 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Cart before the Horse

IEEE did not define the Ethernet.  They redefined parts of it.  The Ethernet
was defined by Digital Equipment Corporation, Intel, and Xerox.  The
definition of the 10-megabit Ethernet far preceeded any silicon.  In fact,
some of the arguments over how it was to work considered whether sufficient
silicon could be projected as available in a practical time frame, but the
design remained optimistic and future-looking.  The first full-power Ethernet
chips came from Intel and AMD/Mostek.  When I got involved in Ethernet
specification work for Ethernet version 2, around 1980, Intel was just getting
to the point where they weren't interested in considering changes to the
specification.  It was only at that point that a not-quite-existing chip had
any direct effect, and that was limited and somewhat resented.  The AMD/Mostek
chip came later, partly in reaction to Intel's stubborness.  Other chips that
came out in the early 80s were minimum function and had no effect on the
design.

I was a latecomer to the process, and I remain impressed by the accomplishment
of the original designers.  Their foresight was impressive, their mistakes
relatively few, and their effect on the industry enormous.

	Bob

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 17:01:30 GMT
From:      gmc@PREMISES1.QUOTRON.COM (Greg Christy)
To:        comp.protocols.tcp-ip
Subject:   class b question

Also sprach James R. Jones:
 > 
 > 
 > hello everybody,
 > 
 > At my company I am about to set up a large ethernet ip network.  I plan
 > on using a class B number.  Somewhere long ago I read that when you 
 > subnet a class b network the you should not start at 1 and go up but     
 > start at 248 and go down, or something like that.  Could someone please
 > refresh my memory on the issuses. 
 > 
 > jim
 > 
 > jrjones@mr.net
 > 

I believe you are referring to RFC 1219 by Paul Tsuchiya.  It
details a method of assigning host and subnetwork numbers such that
the subnet mask can be shifted at a later date with minimal impact to
the assignments.

Greg

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 17:14:00 GMT
From:      stern@nssdca.gsfc.nasa.gov (For your reading endurement)
To:        comp.protocols.tcp-ip
Subject:   Cisco router - DECnet commands?

Anyone know of the various DECnet commands allowed on a cisco router with the
nonprivileged password?  Unfortunately they're not documented in the online
help.  So far I've come across 

show decnet route   (like traceroute)
show decnet traffic  (stats)


Dave Stern

################################################################################
#           NSI/DECnet Routing Center Manager  (Formerly SPAN)
#           Goddard Space Flight Center
#
# DECnet-   BYPASS::STERN
# INTERNET- STERN@128.183.104.17
# BITnet-   STERN@DFTBIT
# SNAILmail-Code 930.4   Bldg 26 Rm 115
#           Goddard Space Flight Center
#           Greenbelt, MD 20771
# Audio-    301-286-6079
################################################################################

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 18:00:22 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Cart before the Horse

The 10-megabit Ethernet was based on a 3-megabit CSMA cable system designed
and used at the Xerox Palo Alto Research Center (PARC).  I believe the
Alohanet work in Hawaii was influential on the Xerox work.  That same time
period also gave us the windowed look in high-resolution bitmap displays
attached to powerful personal workstations with shared file servers.  I'm
talking middle 70s, here.

I know for a fact the Ethernet designers were pushing technology.  They
weren't being ridiculous, but when they decided on 10 megabits, they weren't
quite sure how it was going to work, but they believed it would.  Their major
item of faith was that the silicon would become cheap enough to make the
technology practical (the Ethernet implementations were pretty expensive).
The price goals actually took a little longer than they had hoped, but it
happened.

As far as the fore and back vision of the PPP folks, I can't say.  I haven't
been involved in that one.  They'll have to defend themselves.

	Bob

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 18:09:01 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Specifying "wild" local IP addresses for UDP/TCP

In article <9110011805.AA09950@dino.alias.com> mandrews@alias.com (Mark Andrews) writes:
>I have been reading the UDP section of RFC1122 and am slightly confused
>about "wild" IP addresses in the area of multihoming. The referenced
>section (sect 4.1.3.5) states:
>
>            An application program MUST be able to specify the IP source
>            address to be used for sending a UDP datagram or to leave it
>            unspecified (in which case the networking software will
>            choose an appropriate source address).
>
>I gather that if the source address is left unspecified, it is considered
>"wild". How is this address represented; i.e. what is it's IP address?

This is left up to the implementation.  There is no standard API for UDP
(or any other layer of the TCP/IP suite).  And even if there were a
standard API, it would be different for every programming language (that's
the nature of APIs).  The RFC is specifying the interface at a conceptual
level, not specifying actual calling sequences for real implementations.

There are a number of common ways to do this.

1) Provide two different calls, one which takes a source address parameter
and another that doesn't.

2) Use 0.0.0.0 as the wildcard address (this is the value of IPADDR_ANY in
BSD sockets).  This is guaranteed not to be the actual address of any
interface, so it's safe.

3) In a language that supports optional arguments, make the source address
optional, and have the default be wild.

4) Use a separate flag parameter, or make the address data type a
discriminated union.

>Is an address considered wild if it does not match any of the IP addresses
>assigned to the multihomed machine?

There's nothing invalid about such an implementation, but I don't think it
would be a good idea.  A caller that specified a completely random address
is probably broken (it's probably using an uninitialized variable, in which
case there's the slight possibility that it might accidentally use a valid,
but inappropriate, address).  It would be better to report an error in such
a case, to aid in debugging.

-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 18:13:07 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: PPPointless? (was: Using Wide-Area Point-to-Point Links for Computer Networking (I))
To: bob@morningstar.com (Bob Sutterfield)
Date: Thu, 3 Oct 91 14:13:06 EDT
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
In-Reply-To: <9110031403.AA04475@volitans.morningstar.com>; from "Bob Sutterfield" at Oct 3, 91 6:03 am
X-Mailer: ELM [version 2.3 PL11]

> The point of PPP is inter-vendor interoperability.  It may(*) add
> development time and cost when compared with the inter-router and
> inter-bridge protocols you already have implemented, and it may not
> already do everything your own protocol does as well as your protocol
> does it.
>....... 
> 
> This sort of "my connection list is bigger than yours" competition
> isn't just macho chest-beating, it's the reality of life in the modern
> networking business.  We were able to bring our product to market far
> sooner because of the previous existence of a well-defined and popular
> protocol.  In fact, it's probably safe to say that if PPP hadn't
> already existed, we wouldn't have entered the market at all, because
> we would have needed to implement each vendor's proprietary protocol
> in order to be useful at all, which would have been prohibitively
> expensive.

Amen!  One of the biggest problems that I am having is the LACK of
interoperability with some of the newer vendor's boxes.  They seem to
be quite happy talking within their own product line and could care less
if they are interoperable with someone else's widget.

You can spend your entire life waiting for the ultimate solution OR
get on with it, and hopefully build something useful.  I believe that
PPP probably falls in this category - anything designed by a committee
where n>3 is probably the result of compromise.  :-)

Fortunately, IMHO, the market will speak and weed out these products, or
said vendors will clean up their act.  Our best weapon is a free-market
economy - "natural selection" will take care of the rest (short of another
Chrysler bailout!)...

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 18:16:00 GMT
From:      bob@KAHALA.SOEST.HAWAII.EDU (Bob Cunningham)
To:        comp.protocols.tcp-ip
Subject:   Re: Cart before the Horse


>Let`s try to keep the history straight...

Metcalfe & Boggs' original paper describing ethernet, which has been
reprinted many times, is still an excellent source of information
on ethernet, and local area network ideas in general:

	Robert M. Metcalfe and David R. Boggs.  Ethernet: Distributed
	Packet Switching for Local Computer Networks.  CACM v.19,
	no. 7, July 1976, pp 395-404.


Here's some interesting quotes from it:

	Ethernet design started with the basic idea of packet collision
	and retransmission developed in the Aloha Network [...] We saw
	promise in the Aloha approach to distributed control of radio
	channel multiplexing and hoped that it could be applied effectively
	with media suited to local computer communication.  With
	several innovations of our own, the promise is realized.

	Ethernet is named for the historical luminiferous ether
	through which electromagnetic radiations were once alleged
	to propagate.  Like an Aloha radio transmitter, an Ethernet
	transmitter broadcasts completely-addressed transmitter-
	synchroneous bit sequences called packets onto the Ether
	and hopes that they are heard by the intended receivers.
	The Ether is a logically passive medium for the propagation
	of digital signals and can be constructed using any number
	of media including coaxial cables, twisted pairs, and
	optical fiber.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 19:24:33 GMT
From:      steven@pita.cns.ucla.edu
To:        comp.protocols.tcp-ip
Subject:   performance analysis of fddi routers

i am interested in getting pointers to an analysis of the performance
issues of high-speed network routers, i.e. the relationship between, say,
clock CPI, memory bandwidth, I/O throughput, physical memory, etc,
and routing performance (whatever that is :-).  for example, all other
things being equal, would you expect a 41.7 MHz system with a SPECmark
of 72.2 and 64 Mb of memory to substantially outperform a 25 MHZ system
with a SPECmark of 43.4 and 32 Mb of memory as a router between several
100 Mbs FDDIs and 16 Mbs token rings? what are the calculations involved in
such an evaluation?

________________________________________________________________________________

steven stovall
steven@pita.cns.ucla.edu
(213) 825 7405

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 19:41:54 GMT
From:      jzwiebel@page-ossmmc.com (John Zwiebel (303)971-6788 jzwiebel@page-sys.den.mmc.com)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Sanity check on network configuration

In article <1991Sep30.200128.14362@kronos.com>, richb@kronos.com (Rich Braun) writes:
|> First, a simplified diagram of our in-house net:
|> 
|> 	+----+-----+-----+------+-----+   ---X~~~~~~(The Great Beyond)
|> 	A    B     C     D      E     F
|> 	|    |           |      |
|> 	+G   +H          +I     +J
|> 	+K               +L     +M
|> 			 +N
|> 
|> Boxes A through F are on the backbone.  C and F only have one Ethernet
|> interface; A, B, D, and E each have two Ethernet interfaces and run IP
|> routing.  This second interface is hooked up to a subnet (mostly of
|> DOS PC's running CUTCP).  Eventually box X (a router of some sort)
|> will connect the backbone with the Internet At Large.
|> 
|> Right now, every system in the whole LAN is set up with a 24-bit subnet
|> mask (24 bits of address, 8 bits of host number).  Because I can guarantee
|> that each subnet won't ever have more than 62 nodes, I'm thinking of
|> switching to a 26-bit subnet mask (6 bits for the host number) for the
|> subnets while keeping a 24-bit (Class C) subnet mask for the backbone.
	
	This won't work.  The routers will require that the whole
	network have the same subnet mask.  Also you have 5 networks
	shown.  The 2 bits of subnet mask you are proposing won't make it.
	One of my biggest headaches is having machines that refuse to 
	boot correctly with the right netmask.  If C was not on a subnetted
	physical net then when it tries to talk to those systems that are
	it will look into its routing table and find

		192.1.1.0	C	en0
	
	and so would dump the packet on the directly connected network and
	it wouldn't get to the subnets.  Remember C first has to send
	out an ARP to find the physical address.  Since you have routers
	(and not brouters, right) The broadcast request is not propogated
	to the other networks.  The routers ignore the request because 
	it's not for them.  (Actually, even if they do pick up the request
	They have the same problem is the host you are trying to reach on
	the 192.1.1.0 network or the 192.1.1.128 network -- boy is this
	going to get ugly when it comes to figuring out whose who.)

|> 
|> Is this the most sensible way of setting things up, so as to avoid
|> having to go out and get another Class C network number every time we
|> add a router to the network?  (We'd have plenty of expansion space if
|> we could put 4 routers into each Class C network.)  Am I right to assume
|> that I need to have a unique "network number" for each router interface
|> card?
	YES

	It might be easier to think of networks rather than routers.
	With 2 bits of subnet you can have only 4 subnets.
	Are you sure that you can't use 3 bits and have 30 hosts per network?

If your diagram shows all of the hosts that are currently on your network then
you could use 3 bits (or maybe even 4) for your subnet.  The important thing
is to try to have only one network number advertised through router X.  (That
would be your class C number without the subnets.  That makes it easier for
people to find your network.  And makes it easier on the internet routers.
(This is not required of course but would keep NIC happy.)

You could look at bridges for some of your network isolation and then
you might not have to worry about running out of subnets.  Especially if...

... If you are going to have more than 254 hosts on your network then think about
applying for a class B net.  You might get it.  Or you might have a special 
reason for wanting to keep routing in place or setting up the correct physical
nets may not be practical.

Your set up also depends on the traffic patterns.  As a
for instance, if 'C' is a server that _all_ of the other hosts on the network
have to access to get information then that would interfere with traffic to
the internet.  In such a case you might want to put C on a separate backbone
net and have internet access on another.  Sort of like:

	--------R---------------R---------------R----- X - To Internet
		|		|		|
 -H	      H-|-H	      H-|-H
		|		|		|
	--------R---------------R---------------R-----
                        |
		     C Server

Of course this is 5 networks and so would require more than 2 bits of 
subnet.

Yes each router interface needs its own network address.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 19:51:46 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"


    (remember, though, that NIC.DDN.MIL's primary mission is to support
    MILNET users, so perhaps this is intentional).

This is an interesting point.  I suspect that the old NIC was exploited
to a larger extent by non-DDN customers than by the people who were
actually paying for it.  It's not surprising that someone managed to
underbid them!  Perhaps NIC services that are not explicitly DDN
oriented (eg thetcp-ip mailing list, rfc depository) should be
moved or duplicated somewhere with NSFNet connectivity.

BillW
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 19:59:49 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: class b question


    At my company I am about to set up a large ethernet ip network.  I plan
    on using a class B number.  Somewhere long ago I read that when you
    subnet a class b network the you should not start at 1 and go up but
    start at 248 and go down, or something like that.  Could someone please
    refresh my memory on the issuses.

The theory is that it is hard to decide exactly how big your subnet mask
will need to be.  Dividing the 16 bits available in half is a common
compromise, but is sledom the best choice.

In order to provide the ability to change the subnet mask at a future date,
you want to avoid using the central bits.  One way to do this is to start
assigning your host numbers from the low bits, and your network numbers
from the high bits:

first host, first net:		x.x.128.1	(1000 0000.0000 0001)
second net, second host:	x.x.64.2	(0100 0000.0000 0010)
third net, first host:		x.x.192.1	(1100 0000.0000 0001)
  etc.

Until your field actually meet in the middle (or wherever), you can move
the subnet mask around without having to change ANY of the host addresses.

This may change somewhat when variable subnet masks become more widely
defined and implemented.

BillW
-------

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 20:25:35 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <1991Oct2.224938.33@sdg.dra.com> sean@sdg.dra.com writes:
>perfectly fine, but some network provider elsewhere not under their control
>is losing packets left and right.

I think that it might be called MILNET.  Here are two traceroutes.
One to a company that has its feed on MILNET and the other is the new
nic.ddn.mil.  I think it is generally a MILNET problem, rather than a
GSI problem.  When I used to work for this company, outgoing telnet
sessions were usually unusable due to network congestion and excessive
packet retransmissions.  Notice the HUGE jump in transit times near
the end of both of these paths.  Looks like the typical MILNET
congestion that I was used to...

Warner

solbourne> traceroute 192.112.36.5
traceroute to 192.112.36.5 (192.112.36.5), 30 hops max, 38 byte packets
 1  solbourne-gw (141.138.2.1)  0 ms  0 ms  0 ms
 2  ucb-sol.east.westnet.net (129.19.254.133)  40 ms  20 ms  20 ms
 3  ncar-cu.east.westnet.net (129.19.254.45)  20 ms  40 ms  20 ms
 4  ncar-nss.ucar.edu (192.43.244.7)  20 ms  40 ms  20 ms
 5  * * *
 6  * * *
 7  * 129.140.15.76 (129.140.15.76)  60 ms 129.140.15.12 (129.140.15.12)  80 ms 8  129.140.77.15 (129.140.77.15)  100 ms  100 ms  140 ms
 9  129.140.13.16 (129.140.13.16)  200 ms  160 ms  180 ms
10  129.140.13.130 (129.140.13.130)  120 ms  140 ms  200 ms
11  * * *
12  GSI-GW1.DDN.MIL (26.25.0.201)  2600 ms  1580 ms  2320 ms
13  * * 192.112.36.5 (192.112.36.5)  1760 ms
solbourne> traceroute twg.com.
traceroute to twg.com (26.5.0.73), 30 hops max, 38 byte packets
 1  solbourne-gw (141.138.2.1)  0 ms  0 ms  20 ms
 2  ucb-sol.east.westnet.net (129.19.254.133)  40 ms  20 ms  40 ms
 3  ncar-cu.east.westnet.net (129.19.254.45)  120 ms  20 ms  20 ms
 4  ncar-nss.ucar.edu (192.43.244.7)  100 ms  40 ms  40 ms
 5  129.140.7.75 (129.140.7.75)  40 ms 129.140.7.11 (129.140.7.11)  40 ms 129.140.7.75 (129.140.7.75)  40 ms
 6  129.140.79.7 (129.140.79.7)  60 ms  60 ms  40 ms
 7  129.140.15.12 (129.140.15.12)  40 ms  60 ms 129.140.15.76 (129.140.15.76)  60 ms
 8  129.140.77.15 (129.140.77.15)  120 ms  120 ms  140 ms
 9  129.140.13.16 (129.140.13.16)  120 ms  140 ms  180 ms
10  129.140.13.130 (129.140.13.130)  120 ms  140 ms  140 ms
11  * MOFFETT-FLD-MB.DDN.MIL (192.52.195.1)  120 ms  280 ms
12  TWG.COM (26.5.0.73)  2460 ms  1420 ms  940 ms

	129.140.rrr.rrr	NSFNET-BB	NFSNET-BACKBONE
-- 
Warner Losh		imp@Solbourne.COM	  MMP to DoD #882
"Red hair is caused by sugar and lust," the woman, who was blond, confided.
"Highly evolved beings do not indulge in sugar and lust." -- Tom Robbins

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 21:10:26 GMT
From:      152smith2@gw.wmich.edu
To:        comp.protocols.tcp-ip
Subject:   IP #address for Mac.archive.umich.edu?

Hello. Does anyone know the numeral IP address for
mac.archives.umich.edu
thanks

Eric

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 23:40:48 GMT
From:      cliff@garnet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP over ISDN

In article <1209@dumbcat.sf.ca.us>, marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
|> In article <1991Oct1.145216.13897@dvnspc1.Dev.Unisys.COM>
|> ja@dvnspc1.Dev.Unisys.COM (Jak Amado) asks about TCP/IP over ISDN and says:
|>  > To judge from the titles in the RFC index (as of August '91, i.e. up to
|>  > RFC 1243), there doesn't seem to be any RFC related to ISDN. Did I miss
|>  > any?
|> 
|> Let me rephrase your question: Are there any RFC's about running TCP/IP
|> over telephone lines?

I don't think the question is exactly the same.  ISDN provides a real
out-of-band channel which might offer some interesting uses.  For example,
if the calling phone number is delievered over the D-channel one could
use it to avoid some other start-up authentication and negotiation by
basing startup parameters on the this number.  Also (as you pointed out)
the potential use of IP over Frame Relay over ISDN is pretty exciting
for folks who expect to be "hub" sites (ie targets of lots of incoming
calls).

	Cliff Frost
	UC Berkeley

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 91 23:42:54 GMT
From:      kwang@eng.vitalink.com (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   PING to NIC.DDN.MIL




Dear Folks:

	Does anyone have better idea to get equal response time from 
NIC.DDN.MIL for everybody in U.S. ? Thanks.


					Kwang Sung
					kwang@ENG.Vitalink.COM


P.S. Here is PING Info from Fremont Area, CA.

PING nic.ddn.mil(192.112.36.5): 64 data bytes.
------- nic.ddn.mil PING Statistics ------------
16 packets transmitted, 6 packets received  62% packet loss
Round-trip (tick) min/avg/max = 0/62/75 

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 01:03:57 GMT
From:      jmb@ideas.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   duplicate mailings


So, this problem is not local to this  host!
i've been getting duplicate mailings for over a month now!
recently, the quantity has increased noticably.
to whom should copies of the duplicates's headers be sent so
that this problem can be fixed?

any help?

jon bresler

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 02:26:54 GMT
From:      jnford@argos.weeg.uiowa.edu (Jay Ford)
To:        comp.protocols.tcp-ip
Subject:   Re: class b question

In article <9110030158.AA21090@MR.Net>, jrjones@MR.NET (James R. Jones) writes:
|> At my company I am about to set up a large ethernet ip network.  I plan
|> on using a class B number.  Somewhere long ago I read that when you 
|> subnet a class b network the you should not start at 1 and go up but     
|> start at 248 and go down, or something like that.  Could someone please
|> refresh my memory on the issuses. 

The trick is to assign the bits in the host part from the right, and the bits
in the subnet part from the left.  This leaves the middle bits 0 as long as
possible, allowing you to change the subnet mask without requiring the
renumbering of hosts.  The subnet mask will have to be adjusted on every host,
but that's less visible than changing the address.

See RFC 1219 for the official treatment of this by P. Tsuchiya of Bellcore.  He
is widely credited with coming up with this clever technique.  It's too late
for me to take advantage of it here, but I strongly suggest that any new nets
be set up accordingly to this scheme.

------------------------------------------------------------------------
Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242
jnford@handlebar.weeg.uiowa.edu, 319-335-5555

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 04:07:31 GMT
From:      jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa)
To:        comp.protocols.tcp-ip
Subject:   Re: Cart before the Horse


    I was under the impression that ethernet was based on work done at MIT
    when some hardware hackers wanted to connect computers together using
    coaxial cable which had been abandoned by a cable TV firm.

This is utterly incorrect. (I should know, since I was doing local networking
at MIT in 1977, although I was part of the group at LCS doing the 1Mbit ring
prototype, not the CHAOSnet people, who were in the AI Lab a few floors up.
LCS didn't originally want the ring, DARPA conned them into using it, but
that's another story.)

The MIT work on CHAOSnet, which was a 4Mbit/second (I think I got that speed
right) was based on the prototype Ethernet at Xerox PARC, a 3 Mbit/second
system. It was basically similar, except that it used CATV cable and coax
connectors, instead of stingers into coax cable. One interesting difference
was a complicated clock system with host numbers that were based on cable
position, which was supposed to minimize collisions. Everyone was all scared
about collisions in those days; it was a big bone of contention between
the ring and ether camps.

One length of CATV cable it used was a spare that had been pulled under the
street from the MIT main campus to Tech Sq when MIT ran its internal cable TV
system.

	Noel

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 07:42:06 GMT
From:      torkel@bibsyst.UUCP (Torkel Hasle)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SCO TCP/IP DevSys incompatiblity

We have developed a print routing program for printing
over TCP/IP networks. It is linked with version 1.0 of SCO
TCP/IP Dev.Sys (socket library), and runs fine when using 
TCP/IP RT v. 1.1.1

But when we installed TCP/IP RT version 1.1.3, the programs does not
work, just hangs. 

We have contacted our SCO distributor, but they say that there
is no newer version of the TCP/IP DevSys available.

Investigating some of the binaries shows that version 1.1.3 is
based on LAI (Lachman) version 4.1 Unix V STREAMS source, and
the version 1.1.1 is based on version 3.1 or 3.2.

If this is true, it is no surprise that the old socket lib.
does not work,  and there should be a new version available. 

What do we do? Can anybody give us a clue?

Torkel Hasle

+----------------------------------------------------------------------+
!   Torkel Hasle, Bibliotek-Systemer A/S, N-3250 Larvik, Norway        !
!   uucp: ...nuug!bibsyst!torkel        Tel: +47 34 82 202             !
!            torkel@bibsyst.no          Fax: +47 34 85 185             !
+----------------------------------------------------------------------+

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 09:03:41 GMT
From:      dejonge@latcs1.lat.oz.au (Marco de Jonge)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   PC/IP package problems with WD8003 ethernet card

hello,

	I have obtained a PC IP package from a public FTP site and have tried
to install it. I have a Stand alone PC with a Abell-EN-016 Ethernet card
which is WD8003E compatible. The ethernet card is set up for
        IRQ = 3
        Base I/O address 280 (hex)
        Boot ROM address C400 (hex)

I have compiled all the SRCLIB files and that was fine. Then I compiled the 
CUSTOM program with the NETDEV.SYS file. I then compiled the PING program
for the 3COM library and for the WD8003 library with all the debugging
features on.  I set the NETDEV.SYS file
up to the best I knew how, with the IRQ set to 3, and the I/O address to 280.
The ethernet address is worked out according to the hardware. Also the DMA
channels for transmit and receive were set  to 1.

Now when I tried to run the Western Digital PING program the following results 
were produced. I have tried changing the NETDEV.SYS file as much as possible.
but it had little affect. 

Is there anybody whom has had similar problems, or would someone know possible
solutions to my problem.

Please email any ideas or solutions.   Thanks..

Marco de Jonge
email: dejonge@latcs1.lat.oz.au


c:> ping 131.172.42.21        produces the following output !

Initializing Tasking.
IP: setting handler for protocol 17
UDP: Opened InterNet connection.
IP: setting handler for protocol 1
ICMP: Opened ip conn
IP: setting handler for protocol 3
GGP: opened ip con
in_write: pkt[264] prot 1 to 131.172.42.21, route 131.172.5.250
icmp: can't send echo request
Couldn't send (net address unknown?) on try 0
Ether Stats:
My ethernet address: 00.00.C0.C9.8B.10
   0 ints	   0 pkts rcvd	   1 pkts sent	   0 ints lost
   0 underflows	   0 colls	   0 16 colls	   1 rdys
   0 FCS errs	   0 overflows	   0 dribbles	   0 shorts
   0 missed	   0 unknown
   0 refused	   0 too big	   0 dropped	   0 multi
max q depth 0
   1 ARPs sent	   0 ARP reqs rcvd	   0 ARP reps rcved
   0 ARP reqs not for me	   0 bad ARPs
   0 unexpected replies	   0 bad lengths
IP Stats    0 pkts rcvd	   1 pkts sent
   0 pkts dropped because of:	   0 bad xsums	   0 bad protocols
	   0 bad vers	   0 bad lens	   0 not for me
	   0 ttl expired	   0 frags
   0 destination unreachables rcvd
Packet stats:   10 free packets now
Min depth:    8	Max depth:   10
netclose() called

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 09:28:22 GMT
From:      ercm20@castle.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

imp@solbourne.com (Warner Losh) writes:
> In article <1991Oct2.224938.33@sdg.dra.com> sean@sdg.dra.com writes:
> >perfectly fine, but some network provider elsewhere not under their control
> >is losing packets left and right.
> 
> I think that it might be called MILNET. ...

I'm involved in setting up an IP and DNS service in the UK.  Before the
move, during the morning here (the wee small hours at the NIC, wherever
in the US it might be situated) the connection to MILNET was often (>50%
of attempts?) broken due to routing loops.  These took minutes to clear,
during which time the NIC and its NS were out of contact.  It has
improved slightly since the move - now I more often get network
unreachable for the new NS address.

Sam Wilson
Computing Service
The University of Edinburgh, Scotland, UK

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 12:42:49 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Origins

Ethernet was conceived by Bob Metcalfe, who wrote his thesis ("Packet
Communication") in 1973 while at MIT's Project MAC.  Bob published a
description of the Ethernet concept in January 1975, and developed the
idea at Xerox PARC with Dave Boggs. The Xerox/Intel/DEC agreement on a
common standard was a critical event in development of the Ethernet
market, but lets not forget that it is individuals who invent the ideas.
[Of course, this is not to deny that Bob was in a larger community - the
ARPANET Network Working Grop and the MIT Project MAC Group - which had
major influence on his thinking; still it was Bob, not a committee or
community, that invented Ethernet.]

Alex McKenzie
 

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 13:23:31 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Securing system on network.

In article <1991Oct3.160640.2585@homecare.COM>, jessea@homecare.COM () wrote the following:
>I've got a system that is accessed by the outside would and I would like
>to prohibit it from accessing the rest of the network but still allow
>other systems on the network to access it.  Does anyone know of a paper
>or book that would explain how I can do this.  I just want to make sure
>I don't miss anything.  Thanks and ttyl.

I've had a couple people suggest that this is a little vague so I'll
elaborate.  I've got one system that is on the net and is accessible
from the outside by modem.  This system is on our company ethernet
network and I want to make this system completely untrusted by the other
systems on our company network.  This one system will basically be used
by two people, but I need network access to that system because it is
also the print server for the network.  So I need the system isolated
from the network in that it would be difficult to get out into the
network, but I need everyone else on the network to have access to it if
needed.  I've heard this called a "firewall" because it creates a buffer
between the non-trusted system and the rest of the network.  Does this
make sense and are there any security related documents that would help
with this process?

I've already changed the permissions on rwho, finger, telnet, rlogin,
ftp, tftp, netstat, rcp, rdist, rsh, rup, ruptime, and ruser so that
they are only executable by root.  I could completely remove them, but
I'm not sure I want to do that.  Did I miss any, BTW?

One thing I haven't been able to figure out is how to _disallow_ access
for a particular user.  I would like, for example, to disallow access by
root to any other systems, but .rhosts really doesn't do that.  It just
requires that a password be given and that the process is not automatic.
I would _really_ like to explicitly disallow access to every login on that
system, but I can't seem to do that (except by removing the above
mentioned programs).

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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 13:29:52 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Williams)
To:        comp.protocols.tcp-ip
Subject:   HOST LOOKUP UTILITY

L.  Michael Sabo SSDS, Inc. writes...

Does anyone know of a utility program in the public domain which can
return a domain name given an IP address?  This would be sort of a
reverse nslookup.  I know about etherhostprobe which uses gethostbyaddr
but I was looking for a more generic utility.

Does this look like the kind of thing you're looking for?


command: 

host 26.1.0.172


response:

Name: DOCKMASTER.NCSC.MIL
Address: 26.1.0.172
Aliases:

If so, let me know.  It's a PD program called host.c, but I don't remember
where I got it from.  Here's the header to the code...

/*
 * Copyright (c) 1986 Regents of the University of California
 * All Rights Reserved
 *
 * Redistribution and use in source and binary forms are permitted
 * provided that this notice is preserved and that due credit is given
 * to the University of California at Berkeley. The name of the University
 * may not be used to endorse or promote products derived from this
 * software without specific prior written permission. This software
 * is provided ``as is'' without express or implied warranty.
 */

/*
 * Actually, this program is from Rutgers University, however it is 
 * based on nslookup and other pieces of named tools, so it needs
 * that copyright notice.
 */

Let me know if you want the thing.  If anyone else is interested or knows
what the download source for this program is, please let me know.

Mark L. Williams
Head, Telecommunications Branch
Code 7630
Naval Coastal Systems Center
Panama City, FL 32407-5000
(904)235-5153
(mark@telesys.ncsc.navy.mil)

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 13:41:21 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Williams)
To:        comp.protocols.tcp-ip
Subject:   PPP TECHNO-RELIGIOUS WARS

Is it just me, or is anyone else getting really tired of the continuing
tirade about PPP being conducted in this forum?  I think I'm losing patience
with the thread because I see no contribution to problem-solving here; we
are being presented with a blizzard of ever-lengthening "well, it should
be like this because..." and "Well, your 'because' isn't right!" and "Oh,
yeah, it is, too!" [Ooo, a flame-provoker of my own!!]  Anyway, gentlefolk,
let's ask the interest group for feedback.  All those in favor of encouraging
the PPP-ers to fffind a different ffforum, please make your pack-pack-packets
heard!  If there's enough concurrence, maybe the discussion can be taken 
into private mail.

BTW, irritating your companies' potential customers can destroy the pseudo-
protection most disclaimer notices provide.  Let those who have ears, hear.

Mark

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 13:41:30 GMT
From:      geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.sys.ibm.pc.misc
Subject:   Re: Using "mount" and SOSS

Quoth richb@kronos.com (Rich Braun) (in <1991Sep30.190515.17012@kronos.com>):
#kxb@math.ksu.edu (Karl R. Buck) writes:
#>How can I allow a certain user (or failing that anyone from a certain client) 
#>to be able to mount a file system on SOSS?
#I didn't know the NFS protocol allows for specifying a list of allowed or
#disallowed user-names for mount requests.  Does it?

It's not a protocol issue, it's a server implementation issue.
First, a mount request comes from a machine, not a user, so all
a server can do is decide whether that machine is allowed to
mount a file system. In implementations derived from Sun source, this
is handled by mountd using the netgroups facility. Once a file system
has been exported, clients make requests which include the uid and
gids corresponding to the process executing on the client system.
The server can choose to perform any mapping of userid's that it wants
to, with as great or little complexity (global, per mount, per mount per
client, etc.) as it chooses. No protocol issues arise: this mapping
is not (directly) visible to the client.

Geoff

--Geoff Arnold, PC-NFS architect(geoff@East.Sun.COM or geoff.arnold@Sun.COM)--
------------------------------------------------------------------------------
--       Sun Technology Enterprises : PC Networking group                   --
--                (a Sun Microsystems Inc. company)                         --

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 14:43:54 GMT
From:      dcarr@hobbit.gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In <9110021642.AA09113@azea.clearpoint.com> martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo) writes:

>The 82596 supports a sort of HDLC mode.  

Yah, some mode.  HALF DUPLEX, YOU MUST TOGGLE CRS BETWEEN FRAMES ON RX, ...

Use a SCC (8530) or USC (16C30) if you want to do HDLC.  You'll also save
about $40 US.

>The main distinguishing feature between two hosts connected by a
>megabit rate point-to-point non-self-clocking DTE/DCE type serial
>connection and between two hosts connected by a point-to-point serial
>connection lies in the half-duplex nature of the ethernet connection.
>Interestingly enough some modern ethernet chips don't really care that
>the medium be half-duplex and I know that at least one company has
>built full-duplex ethernet.

NOT USING A 82596 !

-- 
Dave Carr               | dcarr@gandalf.ca       | If you don't know where  
Principal Designer      | TEL (613) 723-6500     | you are going, you will
Gandalf Data Limited    | FAX (613) 226-1717     | never get there.

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 15:12:52 GMT
From:      albright@LAGER.CISCO.COM (Bob Albrightson)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostbyaddr Utility Anyone?

> 
> Does anyone know of a utility program in the public domain which can
> return a domain name given an IP address?  This would be sort of a
> reverse nslookup.  I know about etherhostprobe which uses gethostbyaddr
> but I was looking for a more generic utility.

Nslookup can do it for you.  Lookup 128.95.1.4 in this example:

nslookup
Default Server:  lager-fddi.cisco.com
Address:  131.108.13.55

> set q=ptr
> 4.1.95.128.in-addr.arpa.
Server:  lager-fddi.cisco.com
Address:  131.108.13.55

4.1.95.128.in-addr.arpa host name = june.cs.washington.edu
>

 -bob

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 15:47:29 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   New Beholder Produkt: The Gobbler!!!

Hi,

We have made a new Beholder product, The Gobbler. Tirza has worked
hard to combine Netview and NetCapt and make it run like hell. She has
also improved the Filter capabilities of the system.

Try It!

I include the read.me file.

Collect The Gobbler using anonymous FTP.
from: dutepp0.et.tudelft.nl
path: Gobbler
file: Gobbler.zip

greetings Alfred

----------- READ.ME ---- cut here ----------------
4 october 1991, Delft, The Netherlands

This directory contains the files needed to run The Gobbler, a 
ethernet packet grabber. 
The Gobbler is a direct relative of The Beholder, and is a software
product of the DNPAP group. It is the successor of the Netview/NetCapt
program.

You can run The Gobbler on a standard PC containing an ethernet card
for which there exists a packet driver. Install the packet driver before
you try to run The Gobbler.

You will need the Gobbler.zip file. Unpack this file and read the ascii
file gobbler.asc. This file contains a user manual.

We take no responsibility for the correct operation of The Gobbler, nor
for the correct use. We are willing to listen to any comment you may have.

You can use this software without pay. The only thing we ask is that you send
us your bug-reports.
-- 
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 15:48:34 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Cart before the Horse

In article <9110031800.AA09720@xap.xyplex.com> rlstewart@eng.xyplex.com (Bob Stewart) writes:
>The 10-megabit Ethernet was based on a 3-megabit CSMA cable system designed
>and used at the Xerox Palo Alto Research Center (PARC)...

Ahem.  The 3-Mbps "experimental Ethernet" was full CSMA/CD, using essentially
the same protocols as modern Ethernet.

Arguably it is a real pity that the speed got changed from 3 to 10.  While
there is no doubt that the extra throughput is useful, 3Mbps was a lot
easier to implement.  If they had stuck with 3, we would certainly need
a faster network for major interconnections, but Ethernet might be well
on the way to replacing RS232 as the cheap common-denominator way of
hooking things up.  (No, it is nowhere near that state today, as witness
the number of laser printers with RS232 vs. the number with Ethernet.)
-- 
Programming graphics in X is like       | Henry Spencer @ U of Toronto Zoology
finding sqrt(pi) using Roman numerals.  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 15:53:00 GMT
From:      LIANE%VORTEX.UFRGS.BR@UICVM.UIC.EDU
To:        comp.protocols.tcp-ip
Subject:   E1/RS-449 convertor



My University have just installed 3 PBX (Ericsson MD-110). Now we are buying a
radio digital system to interconnect them because the local PTT failed to
provide us the 2 MBPS connections. We would like to use the same radio digital
system to interconnect Ethernet LANs in the 3 campi. The radio digital system
(possibly Ericsson MINI-LINK II) has the interface CCITT G.703 (E1) and the
cisco router has the interface V.35 or RS-449 for 2 MBPS. We use TCP-IP as *the*
protocolol in the network.

So my problem is concerned the G.703 to RS-449 convertor. Could someone help
me indicating a product able to do that convertion?

Liane Tarouco
UFRGS-University Federal of Rio Grande do Sul
Porto Alegre - RS - BRAZIL

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 16:08:52 GMT
From:      vsp@hpcupt3.cup.hp.com (V. Shankar Prasad)
To:        comp.protocols.tcp-ip
Subject:   Re: QUESTION ON LOOPBACK TEST

/ hpcupt3:comp.protocols.tcp-ip / NAM@EVAX2.ENGR.ARIZONA.EDU / 12:45 pm  Oct  1, 1991 /
>Hi, I am doing some test with the TCP/IP socket.
>I am not sure about socket activity at the following situation:
>
>1)sender process and receiver process are reside in the same host,
>  and sender sends a packet to receiver.
>  Does this packet reaches to the ethernet?
>  Is it just bounds back in the network layer? If not, which layer?
>
>2)When I setup the TCP/IP socket as loopback:
>  IS the packet passed through loopback facility on the situation as above?
>
>I appreciates any comment on this!
>
>Thanks
>
>Jiseung Nam
>University of Arizona
>Electrical and Computer Engineering
>nam@evax2.engr.arizona.edu
>----------
In most implementations of TCP/IP, a packet meant for the same host never
reaches the ethernet - in fact, without some help from the ethernet
controller driver / firmware, a host never receives any packets which it
transmits.  The packet reaches the lower IP layer (network layer) which selects
a link layer (ethernet, slip etc) depending on the destination address.  At
this stage, the loopback packet is detected and sent up through the protocol
stack.  Sometimes, a pseudo-loop driver is used for this purpose (BSD does it).

About point 2) I do not know what you mean by "setting up TCP/IP socket as
loopback" - so I cannot comment on it.

Shankar Prasad

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 16:31:29 GMT
From:      jjohnson@HNS.COM (Jayne Johnson)
To:        comp.protocols.tcp-ip
Subject:   TCP connection failure detection

I have noticed that when a TCP client sends a message to a TCP server and
the TCP server has crashed , I do not get an error from TCP . Is this normal? 

I was using the following scenario:

 1. TCP client and TCP server establish a connection
 2. TCP client sends a message to the TCP server.
 3. TCP server receives the messages and sends a message back to the TCP    client.
 4. steps 2 and 3 continue
 5. TCP server crashes ( caused a hardware exception manually )
 6. TCP client sends a message to the TCP server. No errors returned from
    TCP.

I noticed however when I reset the TCP server , I get an error from TCP client
send() after the reset occurs. Interesting. 

Has anyone seen this? Any suggestions? Should I look into the TCP protocol
control block's state field  to determine that the connection is half broken?
Thanks again in advance.

Jayne Johnson
Hughes Network Systems
email : jjohnson@hns.com
 

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 16:42:09 GMT
From:      mckee@SMILEY.MITRE.ORG ("H. Craig McKee")
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Addressing Issues

>From: Doug Nelson <08071TCP@msu.edu>
>
>The only reason for using a separate IP address for each interface is to
>present an appropriate address to use for packet routing. ...  However, 
>this can be circumvented in a number of cases.  
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What are the cases?  How does KA9Q work with a single IP address?  
Does ISO CLNP permit a SLIP-like connection?  Does anybody have pointers 
to a tutorial discussion of address/interface versus address/host? 
Or is this a religious issue, not fit for innocent ears?
Hopefully - Craig

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 17:39:38 GMT
From:      rouilj@ra.cs.umb.edu (John P. Rouillard)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Securing system on network.


What you are looking for is the description of creating a firewall.

I have used the hosts_access package with some success.  What this
package does is disable connections from a host or set of hosts.  So
you set up all of the machines on your ethernet with the host_access
package, and set up the files so that any attempt to use a tcp service
from your gateway is canceled.

This sort of protection is necessary if your gateway is connected to the
internet.  Disabling the programs you listed makes the machine pretty
useless for ftp, and rlogin.

If anybody has any info about building firewalls, I would appreciate
seeing it.  I requested info on it a month or so ago, and didn't get
anything.

-- John

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 19:21:56 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <9110031346.AA13212@aragorn>, blknowle@aragorn.jdssc.dca.mil (Brad L. Knowles) writes:
> Well,
> 
>     I haven't had any problem at all -- in fact, response time has greatly
> improved for me.  I think this is because the "new nic" is located
> somewhere here in Northern Virginia, relatively close to where I am.
> Since it has moved away from Hawaii (which is where I believe Brigham
> Young University is, please correct me if I'm wrong), it is not surprising
> that response time should be lower for folks from the left coast.
> 
>     Perhaps we should ask these guys to maintain both a left coast and a
> right coast presence, thus keeping response times reasonable for everyone
> in the U.S.?

Sorry, but physical location is not the issue. The logical location and the
path between them is. The old NIC was tied by a 56Kb line to BARRNET, the
Northern California NSFnet regional. The new one is on the MILNET. The only
links between the two is a major bottleneck know as the FIX. There are two of
these, one in Maryland and the other in California. Whjile the FIX is OK in
general, the link to the MILNET makes use of some very limited hardware. The
traffic load is much greater than this HW can handle, and this causes the
delays and dropped packets.

Mr. Knowles is directly connected to the MILNET, so he now has a good path to
the NIC where he was previously running through a FIX. The NIC could have been
sitting right in Reston, but if it was tied to the other side of the FIX, it
still would be far away from him.

An obvious solution is a link to the NIC from both the MILNET and the NSFnet.
But there are security restrictions on the MILNET that make this difficult if
not impossible. A second NIC would solve this, but the task of synchronizing
things would make life VERY difficult.

Finally, what does BYU (which is in Provo, Utah with a satellite campus in
Hawaii) have to do with this? The NIC was operated by SRI International in
Menlo Park, CA. That's about 20 miles south of San Francisco in Silicon Valley
for those not geographically inclined.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman@icaen.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.

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 19:32:18 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   DNS problem.

I know this has been asked before so I apologize for the repeat.  But
I'd like to get DNS to recognize hostname by themselves as well as their
fullname.  I'd like to say "hbmc" instead of having to say
"hbmc.homecare.com" and have DNS recognize it.  I tried CNAME but that
didn't work.  Can someone tell me how I can do this?

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

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 19:52:32 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.unix.aix,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Output of finger command

Early versions of "finger" used to report last login time and the status
of a user's e-mail.

Newer versions, as shipped with AIX and SCO Unix, don't seem to do this.

Why not?

-rich
P.S.  Is there a publicly-available "finger" which provides the old
ARPAnet-standard output?

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 21:12:14 GMT
From:      vatsan@risky.Convergent.COM (Srivatsan)
To:        comp.protocols.tcp-ip
Subject:   Re: QUESTION ON LOOPBACK TEST

In article <911001124526.302@EVAX2.ENGR.ARIZONA.EDU>, NAM@EVAX2.ENGR.ARIZONA.EDU writes:
> Hi, I am doing some test with the TCP/IP socket.
> I am not sure about socket activity at the following situation:
> 
> 1)sender process and receiver process are reside in the same host,
>   and sender sends a packet to receiver.
>   Does this packet reaches to the ethernet?
 NO.
>   Is it just bounds back in the network layer? If not, which layer?
	At loopback driver. The data goes out of IP as a normal IP packet
	layer and will reach the loopback driver instaed of ethernet
	driver. ( IP has two providers, loopback and ethernet )
> 
> 2)When I setup the TCP/IP socket as loopback:
>   IS the packet passed through loopback facility on the situation as above?

	The destination is checked against it's own address and then the
	provider is selected.
> 
> I appreciates any comment on this!
> 
> Thanks
> 
> Jiseung Nam
> University of Arizona
> Electrical and Computer Engineering
> nam@evax2.engr.arizona.edu



vatsan.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 22:21:59 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting an Internet Number

In article <181@edi386.UUCP> eddjp@edi386.UUCP ( Dewey Paciaffi ) writes:
>Please excuse my gross ignorance, but what is the current email address
>one should use in attempting to obtain Internet numbers ?

Is now, always has been, HOSTMASTER@NIC.DDN.MIL.  There was a changeover
to a new contractor this month but that doesn't affect the e-mail
address.  There's a directory of files available on that system containing
the forms you should use.

Service might not be as responsive as in the past until the transition
is complete--that much I've figured out from loud complaints voiced
recently on this newsgroup.

-rich

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 22:28:28 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: class b question

...So I take it from this that you wouldn't start your subnet numbers
at 255 (or 248) and count downward, but rather start them at 128, then
use the 64 bit (subnets 64 and 192), then the 32 bit (32, 96, 160, and
224), and so on.

Sounds like a pretty good idea.

-rich

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 91 23:20:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   FTP to the "new nic"


    Perhaps NIC services that are not explicitly DDN oriented (eg
    the tcp-ip mailing list, rfc depository) should be moved or
    duplicated somewhere with NSFNet connectivity.

Just prior to the cutover, we updated our "mirror" of the SRI-NIC
documentation directories, and we carry the same aliases as SRI-NIC.
We are dual-homed indirectly to MILNET and to NSFnet via WESTNET, both
currently at 56Kbps.  I'd be interested in seeing comparative stats
between us and the new nic.ddn.mil for ANONYMOUS FTP accesses via
MILNET and NSFnet sites.

The files should also be available via standard LISTSERV and TRICKLE
requests using our filename syntax (one level deeper than SRI-NIC's).

If formally requested by DISA, I'm sure we can make arrangements to
carry the TCP-IP and other mailing lists using our auto-digest scheme
to off-load that traffic from the new nic...

Here are the aliases, suitable for use with ANONYMOUS FTP only:

ddn-news: => PD4:<NICDOCS.DDN-NEWS>
ien: => PD4:<NICDOCS.IEN>,PD4:<NICDOCS.NETINFO>
ietf: => PD4:<NICDOCS.IETF>
internet-drafts: => PD4:<NICDOCS.INTERNET-DRAFTS>
netinfo: => PD4:<NICDOCS.NETINFO>,PD4:<NICDOCS.IEN>,PD4:<NICDOCS.RFC>
protocols: => PD4:<NICDOCS.PROTOCOLS>
rfc: => PD4:<NICDOCS.RFC>,PD4:<NICDOCS.NETINFO>
scc: => PD4:<NICDOCS.SCC>

--Frank

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 00:17:30 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

Not to be pedantic, but I'd like to correct a couple of minor points in this
message...

In article <1991Oct4.112156.1@ptavv.llnl.gov>, oberman@ptavv.llnl.gov writes:

|> Sorry, but physical location is not the issue. The logical location and the
|> path between them is. The old NIC was tied by a 56Kb line to BARRNET, the
|> Northern California NSFnet regional. The new one is on the MILNET. The only
|> links between the two is a major bottleneck know as the FIX. There are two of
|> these, one in Maryland and the other in California. Whjile the FIX is OK in
|> general, the link to the MILNET makes use of some very limited hardware. The
|> traffic load is much greater than this HW can handle, and this causes the
|> delays and dropped packets.

The old NIC.DDN.MIL was at SRI, which is connected via a direct T-1 (1.544Mb)
line to Stanford. From there it's two Ethernet hops to the NSFNet backbone.

|> An obvious solution is a link to the NIC from both the MILNET and the NSFnet.
|> But there are security restrictions on the MILNET that make this difficult if
|> not impossible. A second NIC would solve this, but the task of synchronizing
|> things would make life VERY difficult.

I doubt that security restrictions are at issue here. The old NIC.DDN.MIL was
connected both directly to the MILNET (with address 26.x.x.x) and to network
192.67.67, which is/was advertised into both the NSFNet and the MILNET.

	--Vince

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 00:39:28 GMT
From:      ed@lvw6.lvw.loral.com (Ed Allen)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Securing system on network.

Me too, please!
--
Never trust a man who wears white shoes.           | Ed Allen
Vote Libertarian...     Scare the Hell out of 'em. | Loral Command & Contr. Sys.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 01:54:21 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.windows.x,comp.protocols.tcp-ip
Subject:   X Windows load on server, network?

How much load do X terminals typically place on networks and servers?
One of our projects would really like to take 500 dumb-terminal users
and give them X terminals instead, with a big hulking server in the middle,
or possible a few dozen medium-sized workstation servers plus a DBMS
and some routers.

Of course we're not sure about the real application mix, but it's
presumably the "typical" combination of word processing, xterms, spreadsheet,
and DBMS clients, potentially with the window managers moved to the Xterminals.
How unrealistic a network load is this?  Do people with large installations
get ok performance with 100 X terminals per LAN? 200? 50?

Also, how much server resource do you need?  Lacking any real information,
the folks are planning on ~ 1 MB RAM per user plus maybe double the
horsepower required for the DBMS load.  Is this realistic, or is it
going to be swap city?
		Thanks;  Bill
-- 
				Pray for peace;      
					Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# No, that's covered by the Drug Exception to the 4th Amendment

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 02:02:57 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using Wide-Area Point-to-Point Links for Computer Networking (I)

I would like to try to very briefly summarize what I've seen in this thread,
since I feel that one or two useful tidbits may have been lost in the shuffle,
and then I too agree to shut up on the topic on the PPP or TCP lists:

1. With "SLITHERNET/SLIDE", <martillo@azea.clearpoint.com> introduced a
   cute hack: If you have an extended "LAN" consisting of a bunch of bridges
   with only one (or a few) host(s) on each actual local LAN, it is tempting
   to consider whether the host(s) could profitably connect to the bridges
   via the same serial protocol the bridges use to talk to each other, thus
   eliminating the "local LANs" entirely.

   Effectively, <martillo@azea.clearpoint.com> thus re-invented what is
   called (in the currently fashionable buzz-phrase) "switching-fabric
   networks". This is what we had (and the *only* thing we had) before LANs
   were invented! Still, he came at it from a somewhat entertaining direction.

2. Since PPP has been extended with an option to support Remote Bridging,
   it was thus reasonable to ask whether PPP -- as it stands -- is adequate
   as *the* link protocol for a switching-fabric network, a la SLITHERNET
   (or even 802.6, for that matter).

3. Then came criticism of bridge-based networks, which were a bit off the
   mark since what was really being proposed was a switching-fabric network
   that just happened to be implemented with "PPP Bridging" as the data
   link layer.

4. In another subject thread, <emv@ox.com> noted, "If you want broadcast
   or multicast there's other options out there in roughly the same protocol
   space (at least for higher speed lines), namely frame relay and SMDS."

   But frame relay is (currently) only by pre-negotiation, and neither it
   nor SMDS (that I know of) contain provisions for dial-up links.

I am *still* interested in an answer to the question implied by point #2.
I don't feel I've seen a completely satisfactory one quite yet. But for me
the issue is no longer PPP per se, but rather, well,... let me phrase it
as a question:

Given the existence of (or at least, work on) Frame Relay, SDMS, IPLPDN,
ATM, etc., is it reasonable to consider yet another link-layer standard
for a switching-fabric network, which would provide the following features?

	- interoperability among equipments manufactured by many people
	  (including both manufacturers and individual researchers)
	- ability for "ordinary hosts" to be switch nodes, if desired
	- both dial-up and hard-wired
	- both async and sync (and fiber and ...)
	- multi-protocol and/or non-protocol (MAC-level) multiplexing
	- authentication
	- dynamic node identification and/or address allocation

In sum, all the features we associate with (or hope for in) PPP.

I don't know the answer, or at least, not a good enough one. It may or may
not be reasonable to do it in the context of "yet another NCP for PPP", plus
a specification for the switching algorithm. [Simple spanning-tree bridging
is *not* good enough for a switch-based network!] If anyone wants to carry
on such development, perhaps a mailing list could get started, I dunno.

If anyone knows that this duplicates work being done in other arenas, please
give a pointer to those efforts.

Thanks,


-Rob

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

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 06:27:52 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip,cmc.tech
Subject:   Re: Question on the loopback test.

In article <911001102515.179@EVAX2.ENGR.ARIZONA.EDU>
   NAM@EVAX2.ENGR.ARIZONA.EDU writes:
>Hi, I am doing some test with the TCP/IP socket.
>I am not sure about socket activity at the following situation:
>
>1)sender process and receiver process are reside in the same host,
>  and sender sends a packet to receiver.
>  Does this packet reaches to the ethernet?
>  Is it just bounds back in the middle, then which layer?

It depends on (a) the implementation (b) which address you use (c) what
specific network media that address belongs to.

Every host has at least two addresses (usually loopback and ethernet
plus one or more of SLIP, X25 etc). If you use the loopback address,
the packet will never leave the host. If you use a "real" network
address, the packet will usually get down to the media-dependent device
driver, which may or may not have special case handling for the local
address. In the case of ethernet, there MUST be special handling of the
local address, since the ethernet cannot send and receive at the same
time. The driver writer may, however, have decided to send it out to the
network at the same time he sends it back up, because this is a neat
test feature. In the case of X.25, it is really neat to not have special
handling, but to send it out and let the network route it back.

On the other hand, some implementations detect the local address at TCP
level and route it back without even going down to IP. (Makes it hard to
test the network attachment when the first host is put on the network.)

One implementation that I have worked on, had local host routes to the
loopback interface for all local addresses. That way, the device drivers
needed no special code for local addresses.

>2)When I setup the TCP/IP socket as loopback:
>  IS the packet passed through loopback facility on the situation as above?

I am not sure what you mean. There is no setsockopt(loopback) option.
I think you mean "if my host has a loopback driver, and I write to my
own ethernet address, does the packet go to the loopback driver rather
than the ethernet driver?". As explained above, some systems do that,
some don't.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 07:04:03 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP over ISDN

I am hosting a BOF at the upcoming IETF meeting in Santa Fe about this
exact subject.


-- 
Brian Lloyd, WB6RQN                                     Lloyd and Associates
Network Architect                                       3420 Sudbury Road
brian@ray.lloyd.com                                     Cameron Park, CA 95682
voice (916) 676-1147

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 91 15:14:49 GMT
From:      droid@POPLAR.CRAY.COM (Andy Nicholson)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Van Jacobsen's ``Fat Pipe'' modifications...

>Folks,
>
>    Sorry it took so long for me to summarise, I got busy for a while, and
>then forgot that I had promised to summarise.
>
>    Anyway, here is the info I have gotten:
>
>    1.  This code is not yet intended for general consumption -- it is
>	currently intended to be used to test TCP-IP throughput, and used
>	by people like Dave Borman at Cray and Van Jacobsen himself.
>	Maybe some day it will be intended for general consuption, but
>	that day doesn't look like its anytime soon.
>
>	My observation is that if you are a true TCP-IP Guru (with a
>	capital ``G''), or TCP-IP Speed Demon, then you might be able to
>	request the stuff from Van or Dave and have reasonable
>	expectations of getting their code.  On the other hand, if you fit
>	this mold, then you probably should have been conferring with Van
>	and Dave for a long time before this and helped them write this
>	stuff in the first place.
>

Hopefully Dave or Van will respond to your posting with more information
regarding the ultimate distribution of the TCP expanded windows code, but
since they have not posted anything, I'd like to clarify a few points now.

The expanded windows code, in Dave's and Van's separate implementations, are
part of the process of getting the RFC's defining how to do it on a
standards track.  This process has been stalled somewhat by some problems
which have been discovered in the RFC's (1185 and 1072).  This will be
rectified at a working group meeting at the next IETF (November 18-22 in
Santa Fe).  This working group will produce an RFC for TCP expanded windows
which will then (hopefully) go on the standards track.

The idea behind all this is to make it fairly easy for anyone with reasonable
understanding of TCP to be able to use the RFC to make their own
implementation.  However, I am sure that the prototype implementations will
be available in one way or another.  Some Cray Research Inc. customers
have been running the code for some time now  (as reported in "High Speed
Networking at Cray Research", Nicholson, et. al., _Computer Communications
Review_, January 1991).  It is part of UNICOS 6.1, the latest release of
our operating system, which many of our customers are running.  It will
continue to be available in future releases.

I would hate to think that you have to qualify as a TCP/IP "Guru" to take 
part in the learning process involved in using TCP expanded windows.  
Cray Research as a company and Dave Borman personally have made quite an
investment in time and effort to make TCP expanded windows something that
everyone can use and take advantage of.  That investment is wasted if no
one takes advantage of the effort.

>    2.  It's not really any good for speeding up Local Area Network TCP-IP
>	throughput -- it's meant to squeeze the last ounce out of Wide
>	Area Network throughput (like two or more Ethernet LANs connected
>	by a 1.5Mbps T1 link or two or more FDDI LANs connected by a
>	45Mbps T3 link).  If you are looking to boost LAN speed, then you
>	should probably put the BSD 4.3 Reno networking code (which can be
>	anonymously ftp'ed from uunet, but where it's hidden in their
>	hierarchy I haven't the foggiest), or you should go to your Vendor
>	and scream in their ear.  Either way, the Van Jacobsen code won't
>	help you too much.

I must disagree with the statement that it isn't really any good for
speeding up a LAN.  TCP expanded windows will improve throughput any time
the round trip time equals or exceeds the time it takes for a host to fill
a peer's window.  Certainly WAN's with long RTT's are the obvious case.
But the world is making a transition to faster backbones (like FDDI) such
that the signalling rate makes it possible to fill the window in one RTT or
less.  At the 100 Mbps signalling rate, it takes a little over 5ms to fill
a 64k window.  And I know that RTT's in excess of 5ms are not uncommon on
FDDI lans, especially on campus-wide nets with a router or two in the path.
LANs where TCP expanded windows are useful will become fairly common in the
next few years.  TCP expanded windows anticipates and satisfies this need.

If I seem to be overreacting, I'm sorry.  But there are still a lot of people
out there who think TCP is not good enough to solve real-world long-term
internetworking problems.  In the Byte Magazine special issue that just
came out, Bob Metcalfe, (inventor of Ethernet, etc.) is quoted as saying
(not exact, it's at home) "TCP has reached it technological limits", and that
TCP must give way to "real" standards such as OSI (Really, that what it says!)

-- 
Andy Nicholson				droid@cray.com
Cray Research, Inc.			(612)683-5473
655F Lone Oak Drive, Eagan, MN  55121

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 91 03:35:21 GMT
From:      Karl_Kleinpaste@godiva.nectar.cs.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: gethostbyaddr Utility Anyone?

Sabo@DOCKMASTER.NCSC.MIL writes:
   Does anyone know of a utility program in the public domain which can
   return a domain name given an IP address?

archive.cis.ohio-state.edu:pub/nameserver/host.[1c] and thank Chuck
Hedrick.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 91 10:20:08 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostbyaddr Utility Anyone?

In article <911003165556.452149@DOCKMASTER.NCSC.MIL>, Sabo@DOCKMASTER.NCSC.MIL
 wrote:
>Does anyone know of a utility program in the public domain which can
>return a domain name given an IP address?  This would be sort of a
>reverse nslookup.  I know about etherhostprobe which uses gethostbyaddr
>but I was looking for a more generic utility.

The following are three solutions I found...

...Sam
_______

Solution #1 (the general one):

/*
    revlu.c - REVerse LookUp an IP address

    Usage:  revlu IpAddress

    Given an IP address, output the host name corresponding to it.

    <skl@wimsey.bc.ca>
*/

#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>

void main(argc, argv)
int argc;
char *argv[];
{
	int address;
	struct hostent *h;
	char *p;

	if ((p = strrchr(argv[0], '/')) != NULL)
		argv[0] = ++p;
	if (argc != 2) {
		printf("usage: %s IP_Address\n", argv[0]);
		exit(1);
	}
	address = inet_addr(argv[1]);
	if ((h = gethostbyaddr(&address, sizeof address, AF_INET)) != NULL) {
		printf("%s = %s\n", argv[1], h->h_name);
	} else {
 printf("name not found for %s\n", argv[1]);
	}
 exit(0);
}
_______

Solution #2 (for SunOS/NIS fans):

    /bin/ypmatch WWW.XXX.YYY.ZZZ hosts.byaddr
_______

Solution #3 (for the fast typists):

    nslookup
    set q=ptr
    ZZZ.YYY.XXX.WWW.in-addr.arpa.
    ^D
_______
-- 
<skl@cs.sfu.ca>

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 91 16:07:45 GMT
From:      dlgover@dlgsys.cuc.ab.ca (Donald L. Gover)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   ESIX 5.3.2-d Sockets how????


  I'm currently running ESIX 5.3.2-d and am attempting to move over some
BSD code that uses sockets. There seems to be socket stuff included
and infact the links can be complete with out error. However, after the
successful completion of the socket and bind calls the listed call
allways results in a bus error. I have talked to ESIX support and they
claim there is some magic needed to make 5.3.2-d support sockets and
this magic is reveiled in the ESIX streams programmers manual. Well
I don't have one of those. Dose any one have a working piece of code
using sockets under ESIX 5.2.3-d that they could send me????

  Thanks  Don...


-- 
=============================================================================
Donald L. Gover                              New Era Systems Services
UUCP:      uunet!dlgsys!DLGover              PHONE: (403) 237-6141
INTERNET:  DLGover@dlgsys.cuc.ab.ca

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 91 19:59:15 GMT
From:      diro@edison.phone.North.DE (Dirk Rode)
To:        comp.protocols.tcp-ip
Subject:   Re: PING to NIC.DDN.MIL

Shalom,

kwang@eng.vitalink.com (Kwang Sung) writes:

>	Does anyone have better idea to get equal response time from 
>NIC.DDN.MIL for everybody in U.S. ? 
>P.S. Here is PING Info from Fremont Area, CA.
 
>PING nic.ddn.mil(192.112.36.5): 64 data bytes.
>------- nic.ddn.mil PING Statistics ------------
>16 packets transmitted, 6 packets received  62% packet loss

 hmmm ... get to another country :-)))
From us (University of Oldenburg / Germany) Ping statistics says
something about 102 packets sends, 13% packet loss.

 Think thats good for us :-))))

 But the time for fremont area CA is very bad because nic.ddn.mil is
located in Menlo Park, CA. If possible, you should route over hawaii,
you enter there the fast NASA network and get a fast connection to
nic.ddn.mil. This is no joke, in Germany you can better route via 
Switzerland to Munich then over unido - the German EuNet Node.

with best wishes
          Dirk

 
-- 
*  Dirk Rode              * dirk.rode@arbi.Informatik.Uni-Oldenburg.DE *
*  Zwischenahner Str. 64  * Bitnet:   077481@Doluni1.Bitnet            *
*  2910 Howiek            * Privat: diro@edison.phone.North.DE         *
* Die sich des Vergangenen nicht erinnern, sind dazu verurteilt,       *
*   es noch einmal zu erleben.                           Santayana     *

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 91 22:33:50 GMT
From:      pushp@nic.cerf.net (Pushpendra Mohta)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostbyaddr Utility Anyone?

In article <CMM.0.90.2.686589172.albright@lager.cisco.com> albright@LAGER.CISCO.COM (Bob Albrightson) writes:
>
>Nslookup can do it for you.  Lookup 128.95.1.4 in this example:
>
>nslookup
>Default Server:  lager-fddi.cisco.com
>Address:  131.108.13.55
>
>> set q=ptr
>> 4.1.95.128.in-addr.arpa.
>Server:  lager-fddi.cisco.com
>Address:  131.108.13.55
>
>4.1.95.128.in-addr.arpa host name = june.cs.washington.edu
>>

If you have a *nix box, and need to look up this information often, 
you may find the following "USEnet retrieved" aliases useful.

-pushpendra
CERFnet

alias cname	"(" echo set q=CNAME ";" echo \!\* ")" "|" nslookup
alias mx	"(" echo set q=MX ";" echo \!\* ")" "|" nslookup
alias hinfo	"(" echo set q=HINFO ";" echo \!\* ")" "|" nslookup
alias ns	"(" echo set q=NS ";" echo \!\* ")" "|" nslookup
alias any	"(" echo set q=ANY ";" echo \!\* ")" "|" nslookup
alias soa	"(" echo set q=SOA ";" echo \!\* ")" "|" nslookup
alias ptr	echo \!$ \| awk -F. \'\{printf \"set q=PTR\\n%s.%s.%s.%s.in-addr.arpa\\n\",\$4,\$3,\$2,\$1\}\' \| nslookup

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 01:43:37 GMT
From:      johnksun@cbnewse.cb.att.com (john.k.sun)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.unix.sysv386,comp.windows.x
Subject:   Re: ESIX 5.3.2-d Sockets how????

From article <1991Oct6.160745.4876@dlgsys.cuc.ab.ca>, by dlgover@dlgsys.cuc.ab.ca (Donald L. Gover):
> 
>   I'm currently running ESIX 5.3.2-d and am attempting to move over some
> BSD code that uses sockets. There seems to be socket stuff included
> and infact the links can be complete with out error. However, after the
> successful completion of the socket and bind calls the listed call
                                                         ^^^^^^you mean
listen()?

	Yes, I 've the same problem when compiling X11R5 on ESIX 5.3.2D
with TCPCONN in x386.cf.   The X server died in listen() with a bus
error.

> allways results in a bus error. I have talked to ESIX support and they
> claim there is some magic needed to make 5.3.2-d support sockets and
> this magic is reveiled in the ESIX streams programmers manual. Well
> I don't have one of those. Dose any one have a working piece of code
> using sockets under ESIX 5.2.3-d that they could send me????
> 
>   Thanks  Don...

	I don't have a copy of ESIX streams programmers guide either.
Would some kind soul out there send me a working short example piece
of code "me too" ?

						Thanks,

						-----John
						jksun@ihlpl.att.com

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 02:23:09 GMT
From:      jason@cs.utexas.edu (Jason Martin Levitt)
To:        comp.benchmarks,comp.protocols.tcp-ip
Subject:   Changes to ttcp.c for SVR4 Version 3. Comments?


  Yo folks,

      I tried to run the ttcp benchmark under SVR4/386 Version 3 and it
failed handily. The following fixes were necessary to get it to
work. These fixes were done by Dave McCracken of Dell Computer.
      These changes were made on the version of ttcp.c with a last fix date
of 16-oct-85. 

     1. Skip bind() call for tcp_client case

       if(!trans || udp)
          if (bind(fd, &sinme, sizeof(sinme)) < 0)
                 err("bind");


     2. Call listen() with a positive value for backlog, instead of 0

       listen(fd, 1);


      Without these changes, SVR4 says something like "Address family
not supported by protocol family" or maybe it's the other way
around. :-) 
      Does anyone know if the problem is a bug in SVR4 or some kind of
functional change in these calls for SVR4?

       ---jason   jason@cs.utexas.edu

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 11:00:18 GMT
From:      wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Securing system on network.

rouilj@ra.cs.umb.edu (John P. Rouillard) writes:

>I have used the hosts_access package with some success.  What this
>package does is disable connections from a host or set of hosts.  So
>you set up all of the machines on your ethernet with the host_access
>package, and set up the files so that any attempt to use a tcp service
>from your gateway is canceled.

The most recent version now also supports access control and monitoring
of UDP and RPC requests. Available from ftp.win.tue.nl (131.155.70.100), 
file /pub/security/log_tcp.shar.Z.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 13:05:54 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP DevSys incompatiblity

In <399@bibsyst.UUCP> torkel@bibsyst.UUCP (Torkel Hasle) writes:

> We have developed a print routing program for printing
> over TCP/IP networks. It is linked with version 1.0 of SCO
> TCP/IP Dev.Sys (socket library), and runs fine when using 
> TCP/IP RT v. 1.1.1
> 
> But when we installed TCP/IP RT version 1.1.3, the programs does not
> work, just hangs. 
> 
> We have contacted our SCO distributor, but they say that there
> is no newer version of the TCP/IP DevSys available.

They are wrong.

Version 1.1.0 is available.  In particular ODT 1.1 contains TCP/IP RT
version 1.1.3f, and TCP/IP DS version 1.1.0d.  I also just checked the
software shelf :-) and found a copy of 1.1.0d packaged as a standalone
product.

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

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 14:31:00 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection failure detection

In article <9110041631.AA01418@hns.com> jjohnson@HNS.COM (Jayne Johnson) writes:
> 5. TCP server crashes ( caused a hardware exception manually )
> 6. TCP client sends a message to the TCP server. No errors returned from
>    TCP.

In many TCPs, the data you send() is bufferred in the client and the send()
call returns before the data has been sent and acknowledged. So, you get
no error from the send() because your client has not yet discovered that
there is a problem with the server.  It only makes that discovery after
it has tried sending the client's data several times.

The client will eventually decide that the server is not going to answer.
Any send()s you do after that point will get error returns.
In addition, it may be possible to get some kind of asynchronous notification
from the kernel as soon as TCP discovers the problem.
The details depend on your particular implementation.

>I noticed however when I reset the TCP server , I get an error from TCP client
>send() after the reset occurs. Interesting. 

If you kill the server process without crashing the server host, then
the server's kernel notifies the client TCP right away that something is dead.
The client then doesn't have to work to discover this fact.
Obviously, if the entire server machine dies, no such notice is possible.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 14:46:18 GMT
From:      root@utoday.com
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.os.misc,comp.misc,comp.std.misc
Subject:   Question for net.views column in UNIX Today!


QUESTION #10:

	If you could invent a computing standard, what would it be?



------------------------------------------------------------------------
	This question is being posted to gather responses for a regular
column in UNIX Today! called "net.views". The purpose of the column
is to generate user response to questions of importance in the Unix
industry. 
	By sending an e-mail reply to the above question, you are
granting UNIX Today! permission to consider your comments for
publication. A summary of *all* e-mail responses to this post will be
posted in this two weeks from today.
	/* Please include a daytime telephone number! */
------------------------------------------------------------------------

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 15:03:18 GMT
From:      pxv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.windows.x,comp.protocols.tcp-ip
Subject:   remote execution and shell. Question

Hi folks !

I have an application that runs on a workstation on the net and users on
a mac can use it by going thru MacTCP. The way mac talks to the
workstation (running hp-ux 7.0x) is it sends over a "command "(set-up on
the mac side) thru a TCP port to hp-ux, where the rexecd takes care of
it. The way rexecd works is it runs  sh -c  "command". where "command"
is the command that the user passed from mac.

Now here is the problem...

In my case here the command I send is ".profile  DISPLAY" where .profile
is in my home directory and DISPLAY is the hostname:0.3 for the mac.
(For the people in tcp news group ignore the details about DISPLAY, I
think it does not relate to actual problem).

My actual problem is that there is NO tty associated with this process.
This leads to the problem of me not been able to use some keys (notably
the backspace ie Delete key on the mac). I treid the following and it
didn't work :

1) Put stty command in .profile. I get an error message saying that
there is no tty asscociated with the process.

2) run a dummy .cshrc file in which I put stty commands (which shouldn't
have made any difference, I suspected) and the same effect as 1 above.

Is it possible to come out of this problem ?.

Any clues will be appreciated. Please send me an e-mail since I dont get

to read posting as much.

I would be more than happy to provide any other info in this direction.

Thanks a bunch...

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 15:18:03 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: WD8013EP Packet Driver Question...

In article <178@edison.North.DE> diro@edison.phone.North.DE (Dirk Rode) writes:
>gooey@helix.nih.gov (Sean Graham) writes:
 
>>	I was wondering if someone can tell me if the current packet
>>	driver "WD8003E.COM   6535  03-28-91" supports the WD8013EP
 
> and when there is someone who knows this, is there also somebody
>who knows a packet driver for the WD8003EBT Card? I search also the
>(complete) source for such a packet driver and how to include it in
>the KA9Q / NOS package.

I'm using the current Clarkson packet driver with 8003EP and EBT boards;
it should work with the 8013 series as well. If SMC will ever call me
back, now that they've bought the product line from WD, maybe I'll order
some and find out.

>P.S.: Same question - but for 3 Com 503 (Etherlink II) card ...

No idea about those; all we have are WDs (at the moment--if we don't
get calls returned, though, I may have to look elsewhere).

-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
Become a pheresis donor. Loan your blood to the Red Cross for a couple
of hours. They, and cancer patients, will appreciate it.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 15:47:00 GMT
From:      mikeh@hpindda.cup.hp.com (Mike Haag)
To:        comp.protocols.tcp-ip
Subject:   stuck in FIN_WAIT_2

Hi,

I'm working on a problem involving the need to record successful completions
(printing off a TS) and unsuccessful completions. There appears to be a
state that TCP goes into where there is no timer involved. This is the
FIN_WAIT_2 state. Looking at Comer, Internetworking with TCP-IP Vol II,
page 198 (FIN-WAIT-2 State Processing) the only way to clear a connection
hung in this state is by establishing a NEW connection or by a RESET.

I am concerned with this state because if the server experiences a power
failure (no UPS here) and the entire print job was in the buffer, it is lost
and I don't have a mechanism that can report this. The problem only occurs
in the above situation (where FIN_WAIT_2) is the state that I am in. All
other situations send events that are trapped and reported (SIGPIPE,SIGCHLD).  

What solutions are there for me? Any suggestion would be appreciated.  

Thanks, in advance.

Jim O'Shea
HP Atlanta
jwo@hpuerca.atl.hp.com

 

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 16:35:41 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   TCP disconnection problem

This is in response to a question about whether a client TCP should notify
the user when the server has crashed.

When the client sends a segment to the server after the server has crashed
it will obviously not get a response and its retransmission timer will expire.
According to RFC 1122, the client should retransmit some number of times 
before giving up. The application program MUST be able to set the this value.
The RFC even mentions setting the value to infinity which allows the 
application to decide when to give up. Two possibilities occur to me which
would explain what you are seeing. 1) the client TCP is still retrying and has
not given up yet, or 2) the application has set the retransmission value to
infinity and it has not yet given up.

The comment about getting a message on the client when the server has recovered
is explained by the fact that the server will respond to the retransmitted 
segment, with a TCP abort (RST) and the client will then inform the user that
the connection is gone.

Kurt Matthys
Unisys Corp.

Standard disclaimer applies 

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 16:57:02 GMT
From:      gopher@boombox.micro.umn.edu
To:        comp.protocols.tcp-ip
Subject:   internet Gopher: a distributed campus-wide information system

The internet Gopher protocol and software is designed to implement
a distributed campus wide (or Internet wide for that matter) 
information retrieval system.  Folks with information to publish can
run Gopher servers (implementations are available for UNIX boxes and
Macs).  Users wishing to access the servers can use client software
available for UNIX (simple curses based client and a NeXT client),
Macs (using MacTCP), and DOS boxes.  Index servers are also available
for generic UNIX boxes and NeXT boxes (the latter takes advantage of NeXT
digital librarian index capability); these can provide full-text indexing of
documents on the distributed system.

We are working on connecting our Gopher system to the WAIS system.  

Interested folks can try out the curses based UNIX client via telnet to
consultant.micro.umn.edu [128.101.95.23]; log in as gopher with no password.
All the gopher client and server software is available for anonymous ftp
from boombox.micro.umn.edu [128.101.95.95]; look in ~ftp/pub/gopher.
Questions, problems, feedback or bug reports may be directed to the
development team at  gopher@boombox.micro.umn.edu. 

There is a mailing list "gopher-news" where we announce bug fixes or new
versions of gopher software. If you would like to subscribe to gopher-news,
please send e-mail to gopher-news-request@boombox.micro.umn.edu.

- The internet Gopher development team.
  gopher@boombox.micro.umn.edu

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 17:25:47 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   RFS on SunOS

This is the second time I've posted this. Apologies if you get a duplicate.

I have been trying to get RFS up on SunOS 4.x on a SparcStation 2.
Unfortunately, Sun has decided to quit shipping users and system
administrator's guides and the online manuals don't cover what I need
to know. We have Answerbook on order, but in the meantime I need to
get RFS up to talk to our intel boxen.

I have the intel box set up with an rfmaster that looks like:

ficc	p	ficc.bridge
ficc	s	ficc.cheetah
ficc.bridge	a	\x00020401C0000142
ficc.cheetah	a	\x00020401C000015C

"bridge" is the intel box, "cheetah" is the Sparcstation. I set up the
files on the Sparc size the same way, using the intel docs because that's
all I have. The manual pages seem identical, but it doesn't seem to be on
the network. Here's what I did:

	nlsadmin -i tcp
	nlsadmin -a 105 -c /usr/net/servers/rfs/rfsetup -y rfsetup tcp
	nlsadmin -l '\x00020401C000015C' -t '\x00020402C000015C' tcp
	nlsadmin -s tcp

This worked just fine, so far as I could see.

	dname -D ficc
	dname -N tcp

When I tried

	rfstart -p bridge

And

	rfstart -p '\x00020401C0000142'

In both cases it sat there about a minute and said it wasn't on the network.
What did I do wrong?
-- 
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 18:36:12 GMT
From:      mmccorm@d.cs.okstate.edu (McCormick Martin)
To:        comp.protocols.tcp-ip
Subject:   comp.protocols.tcp-ip archive site


If there is an archive site for this group, plese tell me where it is.

Thank you very much.

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

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 18:58:54 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   unix, tcp-ip, and token ring


  I have to set up a network on which there should be at least two
Unix machines. The network will be a token ring and I will run 
TCP-IP on it. I am familiar with Suns etc - you can alway get
a unix box that runs some sort of socket stuff on top of
ethernet, but I have no idea what Unix/Unix box runs the socket,
IP, etc over token ring. I will take any Unix/Unix box combination
but I would prefer a BSD flavor. Any pointers would be appreciated.

                                   Jerry Freedman,Jr

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 19:16:41 GMT
From:      tob@raider.RAIDERNET.COM (Tom Barron)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Securing system on network.

Rfc 1244 discusses security.  If you don't have it, it can be ordered by
sending mail to 

	mail-server@nisc.sri.com

with a text body of

	send rfc1244.txt
	end

It discusses firewalls in a fairly general way, perhaps not providing the
level of detail you guys are interested in.  However, there may be other
documents available from the mail server that would address your needs.
-- 
| Tom Barron       | tob@raider.raidernet.com | "Never try to convert the
| Technology Group | CIS:  70700,3044         |  zealots -- stick to the
| ENVOY Coporation | voice: (615) 872-4867    |  tourists"   -- Bill House

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 20:00:54 GMT
From:      tek@pram.cs.ucla.edu (Ted Kim (Random Dude))
To:        comp.protocols.tcp-ip
Subject:   Packet Reflection?

Some folks in our research group wish to test the impact of network
performance on their application. One person claims to have heard that
there is a way to "reflect" packets off of remote internet hosts. As
far as the application was concerned, communications appear perfectly
normal, except that packets take a lengthy diversion along the way.
The point of doing this is to have realistic network conditions
without having to convince someone far away to run a big package. 

Does anyone know of provisions to support this sort of thing in TCP/IP?

Does anyone know if the SUNOS implementation provides a way to set
this up?

Please respond by e-mail.

My apologies, if this subject has been discussed before.

Thanks,

-- 
Ted Kim                           Internet: tek@pram.cs.ucla.edu
UCLA Computer Science Department  UUCP:     ...!{uunet|ucbvax}!cs.ucla.edu!tek
3804C Boelter Hall                Phone:    (213)206-8696
Los Angeles, CA 90024             FAX:      (213)825-2273

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 21:58:55 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   WAVE: A New Executable Protocol for TCP-IP


 A research project at Lockheed as resulted in an implementation of
 waves, a distributed language which operates over LANs and WANS.  This
 language is pseudo code based and propagates into the network, executing
 at each node, replicating parts of itself and re-propagating on the
 outgoing links.  The language can carry variables with it, update variables
 at each node, or execute system specific system calls at each node. 

 The pseudocode sits upon a simple (OSI) transport layer, and moves about on
 a simple path layer, whose path tables are accessible as a general
 variable space to the executable code.  At each node there exists a copy
 of the peudocode interpreter and a system dependent transport and system level 
 interface.  

 The system allows the software engineer direct access to the switching
 systems of the new generation of fast packet switches.  Thus she can develop
 routing software, conferencing software, distributed data bases, roving
 network control robots, all by building logical trees, spanning nets, directed 
 graphs and the like.  The path layer is compatible with the ATM cell format,
 but includes extensions.  Thus wave software will have direct access to the
 switching tables of the new high speed cell relay switching fabrics.

 The waves reach a link in the network, and under program control may 
 re-propagate part of their structure on the outgoing links, and upon reaching
 a leaf, echo back, the echoes being collected at each node and being returned
 back down the incoming link, thus synchronizing the wave function.

 The system is based upon work by P. Sapaty (waves) EJ Chang (Echo algorithms),
 and myself (making the path tables part of the general variable space).  
 Contact Matt Young Lockheed, (408) 741-1944.  Our current effort centers on
 finding a consensus on the pseudo code format so that many researchers can
 proceed with unique and powerful languages, as well as interpreters for a 
 variety of hardware.

Waves was developed as an experimental language for general concurrent
processing by Peter Sapaty.  At Lockheed we recognized the language as a
tool to manage multi-process simulations because of its ability build
logical trees and initiate sequenced activity at each of the nodes.  The
language was then recognized as a potential control system for the virtual
path layer in the new breed of multi-media cell relay switches and hubs being 
developed for comercial use, and also as a network management language,
supplementing SNMP.

As a LAN/WAN protocol the language is best described as an active network
layer, or an intelligent source routing layer.  The language views the
network as a series of inteconnected links which may be traversed by
specifying a path id (VCI).  The language may explore the links, looking for
specific nodes, and as it explores it can collect a traversed path directly in
the language itself, allowing it to store a route in a form directly
executable.  

Additionally the language can read and write the path tables, so that it can
build multi-hop routes which it can then traverse as part of its application.
For instance, the language may search out the shortest path between the
current node and a destination.  When a connection is later required to the
destination, the wave can quickly traverse the learned route, updating the
path tables using the available channel ID's.  Then a temporary path is laid
for subsequent data delivery.  This application is a variant of a wide variety 
of powerful path building activities.  


  The name Waves was used by Peter Sapaty at the Ukranian Academy of Sciences
to describe a language system he developed, the main characteristic of which
is that the language travels over the network, and can replicate portions of
itself for re-propagation.  My interest in it started as a requirement for
multi-process simulation control over our VAX LAN.  We needed a simple mechanism
to set up the VAXES in a logical graph for the distribution of simulation data,
which moves down a production tree in regular time steps, undergoing 
modification at each node.  The wave system appealed to us in its ability to
move intelligently through a logical tree, branching off to execute special
functions at any node as required by the simulation.  However, Lockhhed cannot
use such a product until it has been "productized" by a University or commercial
company. (We are an applications company, not a tool maker).

  Additionally, the Open Architecture Fast Packet Consortium recoginized the
path building properties of WAVE algorithms as allowing third party 
applications developers to directly control the public domain fast packet 
architecture. The public domain architecture is a cell relay switch whose 
technology is well known, and having a publically defined line card standard.  
Any vendor can build the platform, and line cards built to the standard can be 
used for direct connection between voice/data; public/private; multi-media 
networks with a wide variety of interfaces and software available.  

  Thus, at this time the current view of WAVEs seems to be as an executable
path building protocol.  I will mail out some descriptions we have to any
interested parties.  The WAVE system has quite a bit of support among 
communications vendors and work station vendors, but is far from being
commercially available.  There is actually quite strong demand for such a 
technology because it opens up the new multi-media networks to a whole range
of new applications for the desktop.  The pseudo code for Waves needs to
be de-facto standardized.


Future Generation Computer Systems, 1988 Vol 4,Issue 1
Wave-1: A New Ideology for Distribute Processing on Networks and Graphs
Peter Sapaty, Ukranian Academy of Sciences

Here is a starting reference for the Wave system.  This reference postulates 
a language designed for loosely coupled processor arrays.  The wave
analogy derives from the movement of a wave packet to a node, where it may
propagate out multiple links, like waves on a pond.  A wave front is a single
step in an executable wave, executed at a single node and having the subsequent
fronts of the wave re-propagated according to the instructions in the wave.

Wave functions have embedded waves as their arguments.

My view is that waves offer a new form of network protocol, the active
protocol or executable protocol.  In the form of a well known pseudo code,
the Waves allows application specific protocols, which can be implemented
aver any network whose nodes have a copy of the interpreter for the pseudo
code.  When the network protocol stack contains a path layer (like a simple
network layer) then the path tables can be made part of the wave variable
space, allowing for path building as part of the wave process.  The result 
is a sophisticated form of source routing.

In the pseudo code format, a single atomic unit of the wave system might be
an eight byte unit with the following parts: 1) A key: this modifies the
operation, and is a bit field, each bit having some well known meaning.
2) A loop count, indicating how many times this atomic operation should
be executed. 3) An operator code, and operand space.  The operands point
to variables, either in the wave itself, or in the node at which the wave
is currently executing.  Variables may be another wave or data.  In the
pseudo code, the variable space would follow the executable portion, and
as a front is executed, the remaining fronts may be propagated as a single
unit without re-structuring, resulting in efficient migration.

Actually the concepts are well formed and powerful.  The power increses when
communications vendors include the wave interpreter within their communication 
products and when compiler vendors include higher language support for the 
pseudo code.  However, waves have immediate application for network management,
data base systems, and LAN based simulation.  Clearly its a new technology
protocol which must be tested in the market.

Please drop me a note (foot mail) and I'll mail you the documents we have
produced so far, including a hypothetical WAVE format for standardization.

  Contact:
       Matt Young
       (408)756-6789
       20761 Canyon View Dr.
       Saratoga, CA 95070

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 91 22:01:32 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Open Architecture Fast Packet Consortium


The open architecture fast packet consortium is/was a group of small vendors
and consultants who took the mission of opening up the new fast packet networks
to innovative vendors to supply add-on software and hardware.  Our tactic was
to write a monthly newsletter which detailed a switch definition, a
line card definition, and an open architecture control system.  The definition
of the "public domain architecture" mirrored the market debate regarding
the new networks, and as a market consensus was reached on a certain technology
in the market, we would package that new technology as part of the public domain
architecture.  The resulting architecture, after a year and a half, was the
equivalent of a public domain SNA.  It was actually quite well conceived.  It
is virtual path based, using cell relay with variant cell sizes, a single card 
switch motherboard supporting eight line card slots with full buffering in both
input and output.  The switch can be stacked for larger nodal processors, and 
by itself can be packaged for wall mount or rack mount.  The VLSI was well 
specified so that a number of vendors could begin immediate design.  We 
detailed some 20-30 applications, including voice applications, routers, 
gateways, bridges, high bandwidth mainframe channels, direct 10 Mbps to the 
desktop, frame relay,X25, etc.  The control system allowed desktop applications
direct access to the basic switching resource for the building of special 
purpose logical networks.

The newsletter was targeted at every computer and communications company in the
United States. The second part of the plan took effect when a number of VLSI 
companies began designing and partnering to generate the supporting VLSI, and a
number of small and medium sized companies began building products which could
be easily adapted to the public domain platform.  Thus, what developed was a 
shadow consortium of real companies who are building very similiar, but 
slightly incompatable versions of the public domain platform.  This was by 
design, since the open architecture group used many of their ideas in the 
definition of the public domain platform (we didn't invent everything).

The final part of the plan occurs when a small company, using the resulting 
VLSI, builds a completely open architecture platform, compatible with the
WAVE control system.  We are very close to realizing that final step, and the
result will be the demolition of IBM SNA, and the birth for Unix, of an
enterprise wide, multi-media, open network architecture, full multi-vendor
support, fully open to control by desktop applications, for voice conferencing,
video delivery, puiblic net gateway products, allowing small vendors to add
traditional router/bridge/x25/modem/ISDN support.  The archtiecture is manageble
by traditional upper level management such as SNMP.  There is no prime vendor,
the architecture is fully public domain, available for unlimited participation.


Send me a return address by postage and I'll send you a copy of our 
news letter, including all details of the Open Architecture Hub, including
VLSI design, Control system, tons of applications, market size, market 
opportunities.  

Our Motto:  Equal access to all layers of the technology.

Matt Young
20761 Canyon View Dr.
Saratoga, CA 95070

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 00:27:51 GMT
From:      arc@kaibab.wpd.sgi.com (Andrew Cherenson)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostbyaddr Utility Anyone?

In article <695@nic.cerf.net> pushp@nic.cerf.net (Pushpendra Mohta) writes:
>In article <CMM.0.90.2.686589172.albright@lager.cisco.com> albright@LAGER.CISCO.COM (Bob Albrightson) writes:
>>
>>Nslookup can do it for you.  Lookup 128.95.1.4 in this example:
>>
>>nslookup
>>Default Server:  lager-fddi.cisco.com
>>Address:  131.108.13.55
>>
>>> set q=ptr
>>> 4.1.95.128.in-addr.arpa.
>>Server:  lager-fddi.cisco.com
>>Address:  131.108.13.55
>>
>>4.1.95.128.in-addr.arpa host name = june.cs.washington.edu
>>>
>
>If you have a *nix box, and need to look up this information often, 
>you may find the following "USEnet retrieved" aliases useful.
>
>-pushpendra
>CERFnet
>
>alias cname	"(" echo set q=CNAME ";" echo \!\* ")" "|" nslookup
>alias mx	"(" echo set q=MX ";" echo \!\* ")" "|" nslookup
>alias hinfo	"(" echo set q=HINFO ";" echo \!\* ")" "|" nslookup
>alias ns	"(" echo set q=NS ";" echo \!\* ")" "|" nslookup
>alias any	"(" echo set q=ANY ";" echo \!\* ")" "|" nslookup
>alias soa	"(" echo set q=SOA ";" echo \!\* ")" "|" nslookup
>alias ptr	echo \!$ \| awk -F. \'\{printf \"set q=PTR\\n%s.%s.%s.%s.in-addr.arpa\\n\",\$4,\$3,\$2,\$1\}\' \| nslookup


Wow, you folks are using ancient versions of nslookup!

You can get the latest version of nslookup from the BIND 4.8.3 
or 4.3BSD-Reno distributions. It's also available via ftp from uunet
in the packages/bsd-sources/usr.sbin/named/tools/nslookup directory.
It does the PTR conversion for addresses when doing "A" queries
and any "set" command can be specified on the command line.

For address lookups:

    % nslookup 128.95.1.4
    Server:  sgi
    Address:  0.0.0.0

    Name:    june.cs.washington.edu
    Address:  128.95.1.4

For specifying different record types:

    alias cname		nslookup  -q=CNAME
    alias mx		nslookup  -q=MX
    alias hinfo		nslookup  -q=HINFO
    alias ns		nslookup  -q=NS
    alias any		nslookup  -q=ANY
    alias soa		nslookup  -q=SOA

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 01:12:27 GMT
From:      buck@pool.info.sunyit.edu (Jesse Buckley)
To:        comp.protocols.tcp-ip
Subject:   Send a file to a service number.

Forgive me but I'm socket ignorant.  I need a program that will send
it's standard input to a specific service port.  For example.

% cat /etc/motd | prog host service_number

Anyone out there have something along those lines.
-- 

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 01:24:53 GMT
From:      ddownes@csuna.mur.csu.edu.au (Dean Downes)
To:        comp.protocols.tcp-ip
Subject:   Novell and Sun Os Guru needed

Hello fellow netters ....


I have a question to asks those involved in the use of SUN OS and 
Novell 3.11 . My question is this :

	we are about to transfer our net os to the Novell 3.11 environment
	and where wondering about how to get tcp\ip and smtp connections
	from our pc net to AARnet\Internet.

	I had read that you set up the Novell server with a second ethernet
	card and configure the Novell server to do routing . Is this something
	which is provided with Novell ?

	Next is there a mail program that anyone would recomend to give users
	a seamless mail transfer between the pc to unix world, and of course
	pc to pc. Be it PD our not . 

	Currently we run the tcp\ip under NCSA Telnet and have no problems,
	will this package continue to function properly ?

	We also wish to transfer files via ftp and the novell net os
	from one campus to another (approx. 150 - 300km). Will the Novell
	software allow us to do this. We have a Cisco router . That is
	can we log into a Novell file server which is located on another 
	net, as if it where a local file server ??

	Lastly anyone how has a great deal of information and knowledge
	to share please e-mail me. I would love to have a chat ...



Dean Downes 		e-mail : ddownes@csuna.mur.csu.edu.au

Charles Sturt University - Murray
Australia

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 02:14:35 GMT
From:      lim@thai-yang.trl.OZ.AU (Andy Lim)
To:        comp.protocols.tcp-ip
Subject:   Re:Open Architecture Fast Packet Consortium


Matt,

pls send me a copy of the newsletter.  I can't send email to you at
young@force.decnet.lockheed.com

cheers
andy
-------------------------------------------------------------------------------
 _--_|\    Dr Andy Lim  		     |  Ph:   +61 3 541 6313
/      \   Switching Section, SNRB	     |  FAX:  +61 3 541 6144    
\_.--._/   Telecom Research Laboratories     |  Email: a.lim@trl.oz.au     
      o    P.O.Box 249, Vic. 3168, Australia |  "I'll give u a definite maybe"  -------------------------------------------------------------------------------

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 03:32:13 GMT
From:      lmorales@natchez.huachuca-emh8.army.mil ("Luis F. Morales,Jr.")
To:        comp.protocols.tcp-ip
Subject:   Watcher program

To all,

I am looking for the source code repository for the program I believe is called
"Watcher"  It allows you to script procedures to monitor/administer your 
network and hosts.  Does anyone know where I can find this program??

Also can anyone direct me as to where/how a commercial company can connect to
the internet with full access.  I know PSI provides this service, but I was
wondering what other methods there are or what other companies provide this
type of service.

I currently don't subscribe the tcp-ip list so I would appreciate responses
directly to me.

Thanks in advance,

Luis F. Morales,Jr.
lmorales@huachuca-emh8.army.mil

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 04:40:19 GMT
From:      Mailer-Daemon@NIC.DDN.MIL (Mail Delivery Subsystem)
To:        comp.protocols.tcp-ip
Subject:   Returned mail: Unable to deliver mail

Return-Path: <tcp-ip>
Received: by nic.ddn.mil (4.1/SMI-4.1)
	id AA02291; Tue, 8 Oct 91 00:40:19 EDT
From: tcp-ip
Message-Id: <9110080440.AA02291@nic.ddn.mil>
Subject: 
To: tcp-ip-relay@realy.nic.ddn.mil
Date: Tue, 8 Oct 91 0:40:18 EDT
X-Mailer: ELM [version 2.3 PL2]

Return-Path: <tcp-ip-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA01848; Sat, 5 Oct 91 21:44:50 EDT
Errors-To: sysadm@nic.ddn.mil
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA25412; Sat, 5 Oct 91 18:48:47 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 Oct 91 01:38:30 GMT
From: dorm.rutgers.edu!pilot.njin.net!gould@rutgers.edu  (Brian Jay Gould)
Organization: Rutgers Univ., New Brunswick, N.J.
Subject: Can an SNA network carry TCP/IP traffic?
Message-Id: <Oct.5.21.38.29.1991.24511@pilot.njin.net>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

I have a client that has use of a pure IBM real SNA network 
implemented strictly with IBM hardware and IBM software.

For a particular application, they need to move TCP/IP
data between continents using the 19.2kbps SNA link that
is currently carrying SNA (SDLC) traffic.

There is no option of multiplexing or replacing any IBM
hardware or software.  The network is controlled by another
division and they refuse to consider anything that doesn't
come directly from big blue.

Does IBM offer a solution?  If so, what kind of performance
can I expect?  Is it routed, or carried on a virtual 
connection?  

Any help will be greatly appreciated.  E-mail please.
-- 
--
Any disclaimers made for me, by me, or about me - may or may not accurately
reflect my failure to be reflecting the opinions of myself or anyone else.
*************************************************
*  Brian Jay Gould - Professional Brain-stormer *
*************************************************

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 05:09:15 GMT
From:      tcp-ip@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

Return-Path: <tcp-ip-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA02685; Sat, 5 Oct 91 22:44:45 EDT
Errors-To: sysadm@nic.ddn.mil
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA26536; Sat, 5 Oct 91 19:44:00 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 Oct 91 03:35:21 GMT
From: crabapple.srv.cs.cmu.edu!godiva.nectar.cs.cmu.edu!Karl_Kleinpaste@pt.cs.cmu.edu
Organization: Carnegie-Mellon Univ, Nectar Project
Subject: Re: gethostbyaddr Utility Anyone?
Message-Id: <1991Oct06.023526.52881@cs.cmu.edu>
References: <911003165556.452149@DOCKMASTER.NCSC.MIL>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

Sabo@DOCKMASTER.NCSC.MIL writes:
   Does anyone know of a utility program in the public domain which can
   return a domain name given an IP address?

archive.cis.ohio-state.edu:pub/nameserver/host.[1c] and thank Chuck
Hedrick.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 05:42:46 GMT
From:      mrs@charlie.secs.csun.edu (Mike Stump)
To:        comp.protocols.tcp-ip
Subject:   Re: PING to NIC.DDN.MIL

kwang@eng.vitalink.com (Kwang Sung) writes:
>	Does anyone have better idea to get equal response time from 
>NIC.DDN.MIL for everybody in U.S. ? 

(Call me patient:)

64 bytes from 192.112.36.5: icmp_seq=2. time=124064. ms
64 bytes from 192.112.36.5: icmp_seq=3. time=123104. ms
64 bytes from 192.112.36.5: icmp_seq=4. time=122144. ms
64 bytes from 192.112.36.5: icmp_seq=5. time=121164. ms
64 bytes from 192.112.36.5: icmp_seq=6. time=120204. ms
64 bytes from 192.112.36.5: icmp_seq=7. time=119224. ms
64 bytes from 192.112.36.5: icmp_seq=8. time=118244. ms
64 bytes from 192.112.36.5: icmp_seq=9. time=117264. ms
64 bytes from 192.112.36.5: icmp_seq=10. time=116284. ms
64 bytes from 192.112.36.5: icmp_seq=11. time=115304. ms
64 bytes from 192.112.36.5: icmp_seq=12. time=114324. ms
64 bytes from 192.112.36.5: icmp_seq=13. time=113344. ms
64 bytes from 192.112.36.5: icmp_seq=14. time=112384. ms
64 bytes from 192.112.36.5: icmp_seq=15. time=111404. ms
64 bytes from 192.112.36.5: icmp_seq=16. time=110424. ms
...
64 bytes from 192.112.36.5: icmp_seq=128. time=520. ms

I thought that this type of megabyte buffering was frowned upon.  It
certainly is by me!  It would not bother me so much if they would just
drop the packets, and turn things around in the 520-1000 range that seems
typical for them now.  Does anybody disagree?  Why?
-- 
If I can get mail to you via a legally registered fully qualified
domain name, you could be on Saturn for all I care.

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

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 06:19:27 GMT
From:      tcp-ip@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

Return-Path: <tcp-ip-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA23246; Sun, 6 Oct 91 21:16:10 EDT
Errors-To: sysadm@nic.ddn.mil
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA23157; Sun, 6 Oct 91 18:18:41 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 Oct 91 22:33:50 GMT
From: nic!pushp@ucsd.edu  (Pushpendra Mohta)
Organization: CERFnet
Subject: Re: gethostbyaddr Utility Anyone?
Message-Id: <695@nic.cerf.net>
References: <CMM.0.90.2.686589172.albright@lager.cisco.com>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

In article <CMM.0.90.2.686589172.albright@lager.cisco.com> albright@LAGER.CISCO.COM (Bob Albrightson) writes:
>
>Nslookup can do it for you.  Lookup 128.95.1.4 in this example:
>
>nslookup
>Default Server:  lager-fddi.cisco.com
>Address:  131.108.13.55
>
>> set q=ptr
>> 4.1.95.128.in-addr.arpa.
>Server:  lager-fddi.cisco.com
>Address:  131.108.13.55
>
>4.1.95.128.in-addr.arpa host name = june.cs.washington.edu
>>

If you have a *nix box, and need to look up this information often, 
you may find the following "USEnet retrieved" aliases useful.

-pushpendra
CERFnet

alias cname	"(" echo set q=CNAME ";" echo \!\* ")" "|" nslookup
alias mx	"(" echo set q=MX ";" echo \!\* ")" "|" nslookup
alias hinfo	"(" echo set q=HINFO ";" echo \!\* ")" "|" nslookup
alias ns	"(" echo set q=NS ";" echo \!\* ")" "|" nslookup
alias any	"(" echo set q=ANY ";" echo \!\* ")" "|" nslookup
alias soa	"(" echo set q=SOA ";" echo \!\* ")" "|" nslookup
alias ptr	echo \!$ \| awk -F. \'\{printf \"set q=PTR\\n%s.%s.%s.%s.in-addr.arpa\\n\",\$4,\$3,\$2,\$1\}\' \| nslookup

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 06:53:07 GMT
From:      tcp-ip@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

Return-Path: <tcp-ip-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA23824; Sun, 6 Oct 91 22:31:48 EDT
Errors-To: sysadm@nic.ddn.mil
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA24766; Sun, 6 Oct 91 19:27:41 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Oct 91 02:23:09 GMT
From: agate!stanford.edu!snorkelwacker.mit.edu!usc!cs.utexas.edu!news@ucbvax.Berkeley.EDU  (Jason Martin Levitt)
Organization: CS Dept, University of Texas at Austin
Subject: Changes to ttcp.c for SVR4 Version 3. Comments?
Message-Id: <kevh8dINNf79@cs.utexas.edu>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil


  Yo folks,

      I tried to run the ttcp benchmark under SVR4/386 Version 3 and it
failed handily. The following fixes were necessary to get it to
work. These fixes were done by Dave McCracken of Dell Computer.
      These changes were made on the version of ttcp.c with a last fix date
of 16-oct-85. 

     1. Skip bind() call for tcp_client case

       if(!trans || udp)
          if (bind(fd, &sinme, sizeof(sinme)) < 0)
                 err("bind");


     2. Call listen() with a positive value for backlog, instead of 0

       listen(fd, 1);


      Without these changes, SVR4 says something like "Address family
not supported by protocol family" or maybe it's the other way
around. :-) 
      Does anyone know if the problem is a bug in SVR4 or some kind of
functional change in these calls for SVR4?

       ---jason   jason@cs.utexas.edu

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 07:05:10 GMT
From:      tcp-ip@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

Return-Path: <tcp-ip-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA18596; Mon, 7 Oct 91 15:04:49 EDT
Errors-To: sysadm@nic.ddn.mil
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA20575; Mon, 7 Oct 91 11:50:14 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Oct 91 16:35:41 GMT
From: agate!stanford.edu!msi.umn.edu!cs.umn.edu!atc!s5000!kurt@ucbvax.Berkeley.EDU  (Kurt Matthys x5693)
Organization: Unisys - Roseville, MN
Subject: TCP disconnection problem
Message-Id: <296@s5000.rsvl.unisys.com>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

This is in response to a question about whether a client TCP should notify
the user when the server has crashed.

When the client sends a segment to the server after the server has crashed
it will obviously not get a response and its retransmission timer will expire.
According to RFC 1122, the client should retransmit some number of times 
before giving up. The application program MUST be able to set the this value.
The RFC even mentions setting the value to infinity which allows the 
application to decide when to give up. Two possibilities occur to me which
would explain what you are seeing. 1) the client TCP is still retrying and has
not given up yet, or 2) the application has set the retransmission value to
infinity and it has not yet given up.

The comment about getting a message on the client when the server has recovered
is explained by the fact that the server will respond to the retransmitted 
segment, with a TCP abort (RST) and the client will then inform the user that
the connection is gone.

Kurt Matthys
Unisys Corp.

Standard disclaimer applies 

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 07:07:08 GMT
From:      tcp-ip@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

Return-Path: <tcp-ip-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA27888; Mon, 7 Oct 91 20:35:20 EDT
Errors-To: sysadm@nic.ddn.mil
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA04392; Mon, 7 Oct 91 17:21:28 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Oct 91 17:25:47 GMT
From: psinntp!psinntp!uupsi!ficc!peter@nyu.edu  (Peter da Silva)
Organization: Xenix Support, FICC
Subject: RFS on SunOS
Message-Id: <EWCEODB@xds13.ferranti.com>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

This is the second time I've posted this. Apologies if you get a duplicate.

I have been trying to get RFS up on SunOS 4.x on a SparcStation 2.
Unfortunately, Sun has decided to quit shipping users and system
administrator's guides and the online manuals don't cover what I need
to know. We have Answerbook on order, but in the meantime I need to
get RFS up to talk to our intel boxen.

I have the intel box set up with an rfmaster that looks like:

ficc	p	ficc.bridge
ficc	s	ficc.cheetah
ficc.bridge	a	\x00020401C0000142
ficc.cheetah	a	\x00020401C000015C

"bridge" is the intel box, "cheetah" is the Sparcstation. I set up the
files on the Sparc size the same way, using the intel docs because that's
all I have. The manual pages seem identical, but it doesn't seem to be on
the network. Here's what I did:

	nlsadmin -i tcp
	nlsadmin -a 105 -c /usr/net/servers/rfs/rfsetup -y rfsetup tcp
	nlsadmin -l '\x00020401C000015C' -t '\x00020402C000015C' tcp
	nlsadmin -s tcp

This worked just fine, so far as I could see.

	dname -D ficc
	dname -N tcp

When I tried

	rfstart -p bridge

And

	rfstart -p '\x00020401C0000142'

In both cases it sat there about a minute and said it wasn't on the network.
What did I do wrong?
-- 
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 08:12:41 GMT
From:      MAILER-DAEMON@gs3.gsc.co.kr (Mail Delivery Subsystem)
To:        comp.protocols.tcp-ip
Subject:   Returned mail: unknown mailer error 1

Received: by gs3.gsc.co.kr.gsc.co.kr (5.51.2/5.17)
	id AA00271; Tue, 8 Oct 91 17:12:41+0900
Return-Path: <iso@nic.ddn.mil>
Received: by gsc.gsc.co.kr.gsc.co.kr (4.12/08-14-86)
	id AA09854; Tue, 8 Oct 91 17:21:25+0900
Received: from relay.nic.ddn.mil ([192.112.36.102]) by kum.kaist.ac.kr (4.0/KUM-0.1)
	id AA08822; Tue, 8 Oct 91 17:20:06 KST
Received: from [192.112.36.5] by relay.nic.ddn.mil (5.64/NIC1.1)
	id AA00505; Mon, 7 Oct 91 23:31:09 -0700
Errors-To: sysadm@nic.ddn.mil
Received: by nic.ddn.mil (4.1/SMI-4.1)
	id AA09186; Tue, 8 Oct 91 02:54:30 EDT
From: iso@nic.ddn.mil
Message-Id: <9110080654.AA09186@nic.ddn.mil>
Subject: 
To: iso-relay@NIC.DDN.MIL
Date: Tue, 8 Oct 91 2:54:30 EDT
X-Mailer: ELM [version 2.3 PL2]

Return-Path: <iso-relay@nic.ddn.mil>
Received: from ucbvax.Berkeley.EDU by nic.ddn.mil (4.1/SMI-4.1)
	id AA06301; Mon, 7 Oct 91 08:32:23 EDT
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA08469; Mon, 7 Oct 91 05:23:27 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for iso@nic.ddn.mil (iso@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Oct 91 11:36:16 GMT
From: eru!hagbard!sunic!ugle.unit.no!isolde!hta@bloom-beacon.mit.edu  (Harald Tveit Alvestrand)
Organization: SINTEF DELAB, Norway
Subject: QUESTION: Absolute references, anyone?
Message-Id: <1991Oct7.113616.7578@ugle.unit.no>
Sender: iso-relay@nic.ddn.mil
To: iso@nic.ddn.mil

Hello,
a few years ago (circa 1988) I saw an ISO SG18 document, I think it was
part of the Document Filing and Retrieval work (DFR), that described a
syntax and semantics for "external document references".

The references included:
- Some sort of filestore identification
- Some sort of file/document identification
- Some sort of guarantee for its correctness
  (for instance "none", "may be changed", "is the same until....")

Can anyone feed me the current number and status of this work, if it
still exists?
I have promised to feed it back to the people working on value added
services (espec filestore organization) in the Nordic networks.

-- 
                   Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 08:54:44 GMT
From:      Postmaster@NOC.BELWUE.DE
To:        comp.protocols.tcp-ip
Subject:   (none)

Your message had been relayed through an X.400 network, which has issued
a "delivery report". The syntax of these reports had been devised to
fit the needs of X.400 user software; it is a terse binary structure.
Our gateway is making its best effort to present this information in an
understandable manner; we apology for its esoteric structure.

The report contains information on the following recipients:

<merdian@rus.uni-stuttgart.dbp.de>: Transfer failure.
MTA congestion (Please retry later, when the queues have been cleared).

This message is issued by <postmaster@noc.belwue.de>. 
In fact, it has been automatically generated by an X.400 message
switch, an MTA as it is called. We dont know exactly which one, but
it is located in the following X.400 domain:
	/PRMD=uni-stuttgart/ADMD=dbp/C=de/
If you need more info, try to figure out who the manager of that
X.400 domain is.

The subject of the message was: 

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 10:13:37 GMT
From:      deon@aim1.UUCP (Deon Botha)
To:        comp.protocols.tcp-ip
Subject:   How the find IP address of remote host

How can I determine the hostname/IP address of a remote host given a user
has rlogin/telnet connected to my host from the same?

Also are there any elegant solutions to printing to a remote PC's printer
once that PC has logged in to my host via NCSA Telnet. I am currently
ftp'ing the output file to <calling_pc:prn> which works fine, but this
assumes I know the hostname/IP address of the PC in question (which of
course relates to my first question).

Thanks in advance
-- 
.............................................................
Deon Botha                            :Tel: +27 (21) 419-2690      
Aztec Information Management          :Fax: +27 (21) 21-1040
deon@aim1.UUCP

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 14:00:54 GMT
From:      dfarmer@calg01.UUCP
To:        comp.protocols.tcp-ip
Subject:   Subscription Cancellation

Please remove me from the TCP/IP mailing list.  I will be loosing my indirect 
Internet access on Tuesday, October 15th, 1991.

Sigh, ....

Doug Farmer
AT&T Canada Inc.,
Calgary, Alberta

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 15:11:05 GMT
From:      jaadam01@ulkyvx.ct.louisville.edu
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet Question.


	I am running on an ATT Starlan connected with tcp/IP to a vax cluster
 the problem I am having is With The configeration file for NCSA Telnet.
I have No Problem when I FTP from one node on the lan to another running
Ncsa Telnet, However when  I try to telnet to that node, the host responds
"Invalid port -- packet resent", somthing like that.   In the Config.tel
file their is a parameter to enable ftp, is their a parameter to enable telnet,
 that Im not aware of ???  

				Thanks
					|	
                              John Adam University of Louisville       


			     ||_		

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 16:19:23 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: stuck in FIN_WAIT_2


	If you have kernel sources, you can fix it. Berkeley (in at least
4.3Tahoe, maybe 4.3 too) sets a timer there and forces the TCB to go away
if nothing happens before the timer goes off.
	Since there can be arbitrary processing on the other end before it
does a close or shutdown, you may want to be conservative and make the
timer large (eg, 15 minutes). In my experience it's generally a problem that
they stay forever, not that there are many of them at one time, so giving
them generous, but finite timeouts may be enough.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 16:36:04 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   Secondary nameserver won't refresh itself

I'm having a problem with a secondary DNS server that won't refresh
itself.  When I update a file on the primary, including updating
the serial number and kill -1ing it, the secondary never gets the
updated information.  I have to kill and restart the secondary to
make it refresh itself.  What could I be doing wrong?  Both machines
run SunOS 4.1.1, with Sun's in.named.  Here is the SOA from the
primary:

cc.umanitoba.ca 86400 IN        SOA     ccu.umanitoba.ca reid.ccu.umanitoba.ca(
                        91100701        ;serial (version)
                        600     ;refresh period
                        1800    ;retry refresh this often
                        604800  ;expiration period
                        86400   ;minimum TTL
                        )

Here's it from the secondary:


cc.umanitoba.ca 120 IN  SOA     ccu.umanitoba.ca reid.ccu.umanitoba.ca(
                        91100301        ;serial (version)
                        600     ;refresh period
                        1800    ;retry refresh this often
                        604800  ;expiration period
                        86400   ;minimum TTL
                        )

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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 20:19:11 GMT
From:      udbl@pool.info.sunyit.edu (David Lally)
To:        comp.protocols.tcp-ip
Subject:   Where to get info on FDDI: X3T9.5

Forgive me for posting here but there isn't a FDDI group.

Please send any and all information about FDDI's X3T9.5 protocol to
udbl@sunyit.edu.  I'm writting a term paper on how X3T9.5 relates to the OSI
model.  Specificly how X3T9.5 relates to the MAC layer.  Is there a RFC
on it?  Any help will be greatly appreciated.

Thank you!

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 91 23:49:56 GMT
From:      steph@sco.COM (Steph Marr)
To:        comp.protocols.tcp-ip
Subject:   RFC 1122 and Backwards Compatibility

Okay, we've received our first complaint from the "real world"
(remember them?) about a certain lack of compliance with RFC1122.

It would seem that those fine folks at FTP Software have done a
very nice job of conforming to the RFC, but at the expense of
interoperability.  To be specific, it seem that in section 4.2.2.4
on page 84 the Urgent data pointer now points to the LAST octect
of urgent data rather than (as in RFC 793 Section 3.1) the LAST+1
octect of urgent data (or first octect of non-urgent data).

Well now, it seems that switching this simple little pointer has
blown up many applications, including rlogin, telnet, and a few
other useful programs written out there in the "real world."

Now we could change this and conform to the specs, or we can actually
have a useful product which people can use to get work done.  Unfortunately,
BSD UNIX seems to be the yardstick everyone cares to use, and 4.2 had
this pointer "wrong" and every implementation I have ever seen, while it might
have had #ifdef's, was set to be 4.2 compatible, including RENO.

We could provide a mechanism which changes the value of this pointer
on a system-wide basis, but that's likely to make us go through and
add code to a thousand little apps that use this stuff.  We could even
provide a mechanism whereby this behaviour could be switched on a
per-endpoint basis, but again, we'd have to modify the thousand little apps.

Now, before I go dinking around with all of these apps, I feel the
question must be asked: Did anyone bother to -think- about the consequences
of this change before the RFC was published?  The other question that
comes to mind is: IS anyone else besides FTP going to quietly flip this
pointer around?  If so, do you have any kind of a transition strategy?
What kind of "interoperability testing" can you do when you're the only
one around that's working this way?
--
Steph Marr                                   ...!{uunet, ucscc}!sco!steph
SCO Network Engineering                     (MX Handlers)   steph@sco.COM
#include <std/disclaimer.h>
#include <random/quote.h>

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 00:30:04 GMT
From:      mcb@reason.ig.com (Michael C. Berch)
To:        comp.protocols.tcp-ip
Subject:   What's going on with the NNSC?

Along the same lines of trying to cope with the new NIC, I would like
to report that it now seems impossible to get anything out of the 
NSFNet NNSC.  (I am trying to get our site into the Internet Resource
Guide, which was published under contract to NSFNet by BBN, at least
with in the last year.)

I sent mail to the designated contact address, nnsc@nnsc.nsf.net.
The mail was delivered but there was no answer.  According to their
SMTP server, "nnsc" VRFY's as a valid address.

About a week later I re-sent my message, with a copy to
postmaster@nnsc.nsf.net.  No answer -- the system seems to be a black
hole.

Anyhbody know what the story is?  I was under the imression that the
NNSC contract was still in place, but perhaps not?  Who is responsible
for the Internet Resource Guide?  Who is responsible for the
services performed by the NNSC?

--
Michael C. Berch 
IntelliGenetics, Inc.
mcb@presto.ig.com

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 03:08:53 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip
Subject:   Re: How the find IP address of remote host

deon@aim1.UUCP (Deon Botha) writes:

>How can I determine the hostname/IP address of a remote host given a user
>has rlogin/telnet connected to my host from the same?

I posted this question in comp.unix.programmer and got few optimistic
responses (thanks to those who did) but just thought of this kludge :

	[A portion of] "netstat -n -f inet" gives 

Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  130.102.130.20.23      130.102.128.63.12173   ESTABLISHED
tcp        0      0  130.102.130.20.23      130.102.130.4.2075     ESTABLISHED
				    ^^ 23 is a telnet, rlogin would be 513

	Based on any local addresses with port #s 23 or 513,  do a reverse
	address lookup on the foreign address e.g. 130.102.128.63 or
	130.102.130.4,  in this case.  These reverse lookups can be compared
	to the last column of finger :

Login       Name              TTY Idle    When    Where
natalie  Natalie Hindmarsh     p0    7 Wed 09:06  natalieh.ceu.uq.    
nirad    Nirad Sharma          p1      Wed 12:22  spade3.cc.uq.oz.    

	and the latest login for a particular person, myself in this case,
	could be extracted from the finger output and compared against the
	1st 16 letters of the results of the reverse lookup above,  yielding
	the fully qualified address and ip # of the remote host.

(The reverse lookups won't be very expensive for successive iterations as
resolvers cache their requests.)

This should be fairly doable in a shell or perl script.  While I have probably
specified one of the kludgiest solutions in history,  it should work and, in
the absense of a cleaner solution (which shouldn't be hard),  I might actually
use it. 

A much better solution would be to delve into the source for netstat and
perhaps implement something a little along the lines of this solution. Or
get SysVR4 as others have said.

Sorry about the kludge,  its just a suggestion.
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 03:19:03 GMT
From:      eddjp@edi386.UUCP ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   Re: unix, tcp-ip, and token ring

In article <1991Oct7.185854.27720@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes:
>
-  I have to set up a network on which there should be at least two
-Unix machines. The network will be a token ring and I will run 
-TCP-IP on it. I am familiar with Suns etc - you can alway get
-a unix box that runs some sort of socket stuff on top of
-ethernet, but I have no idea what Unix/Unix box runs the socket,
-IP, etc over token ring. I will take any Unix/Unix box combination
-but I would prefer a BSD flavor. Any pointers would be appreciated.
-
-                                   Jerry Freedman,Jr

Try IBM's RS/6000 running AIX, a PC running SCO Opendesktop, or
a DELL PC running DELL SVR4.

I use the RS/6000 and it gives good token ring...

I have nothing to gain from any of the above.

-- 
Dewey Paciaffi      ...!uunet!edi386!eddjp

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 04:46:20 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip
Subject:   Re: How the find IP address of remote host

nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma) writes:

>deon@aim1.UUCP (Deon Botha) writes:
 
>>How can I determine the hostname/IP address of a remote host given a user
>>has rlogin/telnet connected to my host from the same?
 
>I posted this question in comp.unix.programmer and got few optimistic
>responses (thanks to those who did) but just thought of this kludge :

Following up to myseelf ?  If you read my article and survived wait 'til you
see this.  As I said before,  although written quickly and very dirtily, it
seems to work except from localhost logins :

---START---
#!/bin/sh
#
#  getremotehost.sh -  quick and very dirty implemention to find the host
#		       from which a telnet / rlogin is coming from
#
#  Note my lack of prowess with awk, sed and dig.  I'd LOVE someone to
#  clean this up or,  better still,  provide a clean solution to this problem.
#


# Find the tty of the controlling terminal
TTY=`tty | awk '{FS="/";print $3}'`

# Get up to 16 characters of the host from which the remote login came from
PARTHOST=`who | grep $TTY | awk '{print $6}' | sed -e "s/(//g" -e "s/)//g"`

# Do a reverse lookup on the foreign addresses corresponding to ports 23
# (telnet) and 513 (rlogin) and return a list of them

for addr in `netstat -n -f inet | egrep '.23 |.513 ' | awk '{print $5}' | awk \
		'{FS="."; print $1 "." $2 "." $3 "." $4}'`
do dig -x $addr | grep PTR |awk '{print $4}'
done | \
grep $PARTHOST | uniq		# and get the hostname best corresponding to
				# the 1st 16 characters found above.
---END---

If this is the best way to do (I mean the general theory) then could someone
PLEASE clean up the awks / greps / digs.  Hope this helps

--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 06:00:57 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        alt.sys.sun,comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: 57600 baud on Sun zs (Zilog 8530) port (and SLIP on T3000)

In article <8128@emory.mathcs.emory.edu>, km@mathcs.emory.edu (Ken Mandelberg) writes:
|> I just got hold of a Telebit T3000 modem that supports a DTE rate of
|> 57,600 baud, and have been trying to crank up a Sun IPC "zs" serial
|> port to this speed to talk to it.
   .........

I want to thank the people that replied to my original article with
additional information about the 8530. As has been pointed out in other
followups here, the formula for baudrate using the internal clock and a
clock divisor of 16 is

   baud_rate = 153600/(tc+2)

As far as I know it is not practical to change either the clock rate
or divisor, so tc is all there is to play with.

The Sun driver has a minimumum tc of 2 (in zs_speeds) which gives
exactly its highest supported baudrate of 38,400.

I've subsequently patched zs_speeds to try, tc=1 51,200 baud and tc=0
76,800 baud. Surprisingly, these actually work even at sustained loads.
The way I tested it was to loop ttya to ttyb with an 8 foot cable, and
set up a SLIP connection.

Using ftp as a test, I got 5055 bytes/sec of end to end throughput on
the tc=1 51,200 baud test. I got 7302 bytes/sec on the same test run
with tc=0, 76,800 baud. In this latter case I saw an interrupt load
(from xperfmon) of just over 15,000/sec which it seemed to handle in
stride.  This is really a worst case scenario, the same machine was
handling both the send and receive interrupts. My tests ran for several
minutes at a time, transfering several megabytes of data with no end to
end errors. There were also no zs silo overflows or other signs of
trouble.

Of course this doesn't help me exploit the 57,600 DTE speed of the
Telebit, since neither 51,200 nor 76,800 are in its repertoire, I'm
still stuck at 38,400. It really is a shame too. I can see that its not
infrequent that because of the V.42BIS compression, that the DTE speed
is a limiting factor.  Unlike UUCP compressed batches, a lot of what
you run over a SLIP link does not consist of precompressed data (SMTP,
NNTP, NFS).

I really wish Telebit would support 51,200  or 76,800 so Sun SLIP users
good squeeze a bit more out of it. If there is any progress in modulation
methods better than V.32BIS it will be even more important.

One last comment. The results I report are all with SLIP, which runs
its own streams module above the zs port. Results are less satsifactory
running through the ldterm/ttcompat modules used for Unix terminal
support. I did not try UUCP, but both kermit and zmodem dropped a lot
of data at these speeds, unless the window size was kept small. I
really wasn't able to do any better with these then at 38,400. I think the
problem is that the max packet size for these  stream modules is small,
resulting in too many user level context switchs reading the data.

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

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 09:24:35 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Secondary nameserver won't refresh itself

In article <1991Oct8.163604.4374@ccu.umanitoba.ca> mills@ccu.umanitoba.ca (Gary Mills) writes:
>I'm having a problem with a secondary DNS server that won't refresh
>itself.  When I update a file on the primary, including updating
>the serial number and kill -1ing it, the secondary never gets the
>updated information.  I have to kill and restart the secondary to
>make it refresh itself.  What could I be doing wrong?  Both machines
>run SunOS 4.1.1, with Sun's in.named.  Here is the SOA from the
>primary:
>
>cc.umanitoba.ca 86400 IN        SOA     ccu.umanitoba.ca reid.ccu.umanitoba.ca(
>                        91100701        ;serial (version)

Everything looks OK from here :

% host -vC cc.umanitoba.ca

Finding nameservers for cc.umanitoba.ca ...
Query done, 4 answers, status: no error
Found 1 address   for ccu.umanitoba.ca
Found 1 address   for eeserv.ee.umanitoba.ca
Found 1 address   for relay.cdnnet.ca
Found 1 address   for clouso.crim.ca
Checking SOA for cc.umanitoba.ca at server ccu.umanitoba.ca
Query done, 1 answer, authoritative status: no error
ccu.umanitoba.ca	reid.ccu.umanitoba.ca	(91100701 600 1800 604800 86400)
Checking SOA for cc.umanitoba.ca at server eeserv.ee.umanitoba.ca
Query done, 1 answer, authoritative status: no error
ccu.umanitoba.ca	reid.ccu.umanitoba.ca	(91100701 600 1800 604800 86400)
Checking SOA for cc.umanitoba.ca at server relay.cdnnet.ca
Query done, 1 answer, status: no error
ccu.umanitoba.ca	reid.ccu.umanitoba.ca	(91100701 600 1800 604800 86400)
Checking SOA for cc.umanitoba.ca at server clouso.crim.ca
Query done, 1 answer, authoritative status: no error
ccu.umanitoba.ca	reid.ccu.umanitoba.ca	(91100701 600 1800 604800 86400)

As you can see, all the SOA's have the same number.

BTW The 'host' program is a completely rewritten version of the original
'host'. It is a DNS query program a la dig, but much more usefull options.
You can find it at nikhefh.nikhef.nl in ~ftp/network. Read the README_FIRST
first, you may need a new resolver as well (it is also in there).

-Marten

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 14:34:06 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Alternate ftp site for RFC documents?

System NIC.DDN.MIL is, for all intents and purposes, down.  Is there
another Internet site which provides a public archive of RFC specifications?

I'd like to RTFM about subnetting and I can't get the details lately.

-rich

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 14:57:46 GMT
From:      tanaka@isl.mei.co.jp (Yasunori Tanaka)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Does anyone know Agilis Co. , wireless communicatin?


Please send me any information about Agilis Corporation which
developed spread spectrum radio products to use wireless
communication. 

I am interested in wireless LAN. I found that company at the 
report in Business Communications Review. Agilis is in
Mt. View, CA. But I couldn't find it in Tel Directory.

Any help will be greatly appreciated.

Thank in advance.
-- 
------------------------------------------------------------------------------
Yasunori Tanaka                                         tanaka@isl.mei.co.jp
Information Systems Reserch Lab.                        :Tel: +81(6)906-2431
Matsushita Electric Industrial Co.,Ltd.                 :FAX: +81(6)906-5547

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 16:29:18 GMT
From:      peter@ski.austin.ibm.com (Peter Jeffe 512.838.4019)
To:        comp.protocols.tcp-ip
Subject:   subnets with different masks

There is a site that wants to use class B addresses with subnets, and
use different subnet masks for the different subnets.  Specifically,
a machine has two interfaces, as follows:

                 en0                     en1
    address    832f0407 (131.47.4.7)   832ffe01 (131.47.254.1)
    mask       fffffc00                ffffff80
    subnet     832f0400                832ffe00

They want all traffic for addresses from 131.47.4.1 through 131.47.7.254
to be routed through en0, which seems reasonable enough to me.  But the
BSD code doesn't allow this (at least through the tahoe release--I
tried to figure out the reno routing logic but ran screaming from the
room after an hour).  The code grabs the subnet mask from the first
interface it finds with the same net value as the destination.  It then
uses this mask for the comparison between the destination and the
routing table entry, which yields unpredicatable results (depending on
the order of the interface table).

So my question is: is there some good reason to disallow this
arrangement, other than that it's confusing as hell?  It seems to me
that as long as the subnets are unique for all the values of the masks
(as in this case), there is no ambiguity.  And if there is an overlap
due to poor address selection, it's no worse an ambiguity than exists
now.  So why not compare the subnet value of the interface with the
destination address masked by the interface's subnet mask, instead of
simply comparing net values?

-- 
peter jeffe  ...cs.utexas.edu!ibmchs!ski.austin.ibm.com!peter

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 16:29:20 GMT
From:      ub@sapwdf.UUCP (Uwe Bloching)
To:        comp.protocols.tcp-ip
Subject:   UDP Broadcast problems

While playing with UDP broadcasts I ran into the following problems:

  a) a broadcast message sent by my test program could be received by
     all machines in the network except the local machine. 	

  b) I could not find out how to send a broadcast message to a different
     subnetwork which is connected via a gateway to the network I was
     doing my tests in. 

Does anybody have an idea about this ? 
      

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 16:58:30 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP disconnection problem

kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) writes:
>This is in response to a question about whether a client TCP should notify
>the user when the server has crashed.
>
>When the client sends a segment to the server after the server has crashed
>it will obviously not get a response...

... But, what if the remote has crashed and the local program hasn't
tried to send anything?  Suppose it wants some form of asynchronous
notification even when it's idle or doing something other than network
transmissions?  I don't think TCP/IP protocols have a "keep-alive"
transmission.  This is sometimes the reason why a company will want to
use some other protocol, or a variant of TCP/IP.  I've had to
implement code in some applications which employed a keep-alive packet
to ensure such notification even during idle periods.

Doesn't NetWare employ something like this?  If you snap a client system's
power off, the server figures this out pretty quickly.

-rich

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 17:06:08 GMT
From:      fredrick@acd.acd.ucar.edu (Timothy Fredrick)
To:        comp.protocols.tcp-ip
Subject:   Can POPMAIL-PC be used with PC/TCP from FTP Software?

We have FTP Software's PC/TCP version 2.05 running on a 3com Etherlink 3c503
card.  Their POP3 client works, but has a very bad user-interface.  I
would love to be able to use the POPmail/PC program (2.2) from the
University of Minnesota.  Does that program *have* to use the ethernet
packet driver?  If so, we're out of luck since I could never get it to
connect to our POP3 server with the ethernet packet driver in memory.

Is there any way for it to go through the drivers that FTP Software provides?

Thanks.

--Tim Fredrick (fredrick@ncar.ucar.edu)
  Ntl Center for Atmospheric Research
.

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 17:21:00 GMT
From:      SCOTT@SKLIB.USASK.CA (Peter Scott/Order Unit/U of Saskatchewan Library)
To:        comp.protocols.tcp-ip
Subject:   HYTELNET version 4.0 now available

[Apologies for any cross-posting]
 
This is to inform you that HYTELNET version 4.0, the utility which gives 
an IBM-PC user instant-access to all Internet-accessible library 
catalogs, Freenets, CWISs, Library BBSs, etc. is now available. You can 
get it via anonymous ftp from:
 
vaxb.acs.unt.edu   (129.120.1.4)
 
in the "library" subdirectory. It is listed as HYTELN40.ZIP.
 
<Please do not attempt a download on Saturday, October 12, 1991>
 
Version 4.0 is a major upgrade. It has been completely re-designed to 
run faster. The majority of files are now housed in their own 
subdirectories. For example, all Canadian library sites are now filed in 
the subdirectory \CN0, Australian libraries in \AT0, etc. The file 
OTH046 contains instructions for accessing the UNIX version of HYTELNET, 
which has been written by Earl Fogel at the University of Saskatchewan.
 
Note: the UNZIPPED files total over 500,000 bytes...but remember, you 
can always edit out any information you do not need, in order to save 
space.
 
Information from Roy Tennant follows, slightly edited, describing how to 
obtain HYTELNET version 4.0 from Billy Barron's ftp site (thanks Roy)::
 
TO RETRIEVE HYTELNET:
At your system prompt, enter:               ftp vaxb.acs.unt.edu
      or                                    ftp 129.120.1.4
When you receive the Name prompt, enter:    anonymous
When you receive the password prompt, enter your Internet address.
When you are at the ftp> prompt, enter:     binary
At the next ftp> prompt, enter:             cd library
Then enter:                                 get HYTELN40.ZIP
After the transfer has occurred, either
   proceed with the instructions below to
   retrieve the UNZIP utility (which you
   need unless you already have it) or enter:   quit
 
The Hytelnet program is archived using a ZIP utility.  To unarchive it, 
you must be able to "unzip" the file.  If you have the file PKUNZIP.EXE, 
it will unarchive the HYTELN40.ZIP file (see below for instructions). If 
you do not have it, you may retrieve it with by following these 
instructions:
 
TO RETRIEVE PKUNZIP:
Use the above instructions for connecting to vaxb.acs.unt.edu
At the ftp> prompt, enter:                   binary
Then enter:                                  cd micro/ibm/utility
Then enter:                                  get PKUNZIP.EXE
After the transfer has occurred, enter:      quit
 
TO DOWNLOAD IT TO YOUR PC:
 
Because of the plethora of PC communications programs, I will not 
attempt to give step-by-step instructions here.  You should check the 
instructions for your software for downloading a *binary* file from your 
Internet account to your PC.
 
TO UNARCHIVE HYTELN40.ZIP:
 
Make a new directory on your hard disk (e.g., mkdir hytelnet)
Copy PKUNZIP.EXE and HYTELN40.ZIP into the new directory
Make sure you are in that directory, then enter: pkunzip HYTELN40
It will then unarchive HYTELN40.ZIP, which contains the following files:
 
                             HYTELNET.ZIP
                             READNOW.!!!
 
The file READNOW.!!! gives full instructions for un-archiving 
HYTELNET.ZIP. Simply put, you **MUST** unZIP the file with the -d 
parameter so that all the subdirectories will be recursed.
 
To use HYTELNET, you should refer to the instructions in the release 
announcement by Peter Scott, or to the README file included with the 
package.
 
PLEASE NOTE that I offer the above instructions as a service for those 
who are unfamiliar with the steps required to download and use files 
from network sources.  I cannot be responsible for any local variations 
in these procedures which may exist.  Please contact your local computer 
support staff if you have difficulty performing these tasks.
 
..............................................................
   Peter Scott                    [] Phone:    306-966-6014
   University of Saskatchewan     [] FAX:      306-966-6040             
   Saskatoon                      [] Internet: SCOTT@SKLIB.USASK.CA     
   Saskatchewan, Canada S7N OWO   [] CFN:      an682@cleveland.freenet.edu

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 17:47:28 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1122 and Backwards Compatibility

In article <14679@scolex.sco.COM> steph@sco.COM (Steph Marr) writes:
>Okay, we've received our first complaint from the "real world"
>(remember them?) about a certain lack of compliance with RFC1122.
>
>It would seem that those fine folks at FTP Software have done a
>very nice job of conforming to the RFC, but at the expense of
>interoperability.  To be specific, it seem that in section 4.2.2.4
>on page 84 the Urgent data pointer now points to the LAST octect
>of urgent data rather than (as in RFC 793 Section 3.1) the LAST+1
>octect of urgent data (or first octect of non-urgent data).

RFC1122 (dated Oct 1989) does mention this, but the correction was
initially noted in RFC961 (December 1985), so it is not as recent
an upheaval as you suggest.

>Now we could change this and conform to the specs, or we can actually
>have a useful product which people can use to get work done.  Unfortunately,
>BSD UNIX seems to be the yardstick everyone cares to use, and 4.2 had
>this pointer "wrong" and every implementation I have ever seen, while it might
>have had #ifdef's, was set to be 4.2 compatible, including RENO.

But, isn't it the case that 4.2 had it *wildly* wrong, so that they
actually pointed to the FIRST+1 urgent octet?  There was some kind of
assumption that the urgent data was always one octet long.
4.3 "corrects" the pointer to be LAST+1.  

Fortunately, the "standard" applications never do send more than one
octet with the urgent flag, so as far as they are concerned the behaviours
are identical.  Even more fortunately, I think you will find that most
systems you thought were following the 4.2 example are actually
following 4.3 (i.e., RFC793), so there really aren't 3 alternatives to
worry about.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 20:04:51 GMT
From:      chris@wuarchive.wustl.edu (Chris Myers)
To:        comp.protocols.tcp-ip
Subject:   Re: Alternate ftp site for RFC documents?

richb@kronos.com (Rich Braun) writes:

>System NIC.DDN.MIL is, for all intents and purposes, down.  Is there
>another Internet site which provides a public archive of RFC specifications?
>
>I'd like to RTFM about subnetting and I can't get the details lately.
>
>-rich

There are several sites which have all of the RFC's available for anonymous
FTP:

	FTP.NISC.SRI.COM
	NIS.NSF.NET
	NISC.JVNC.NET
	VENERA.ISI.EDU
	WUARCHIVE.WUSTL.EDU

Chris Myers                                Internet: chris@wugate.wustl.edu
Software Engineer                           UUCP: ...!uunet!wuarchive!chris
Office of the Network Coordinator                BITNET: chris@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 935 7390
-- 
Chris Myers                                Internet: chris@wugate.wustl.edu
Software Engineer                           UUCP: ...!uunet!wuarchive!chris
Office of the Network Coordinator                BITNET: chris@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 935 7390

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 91 21:53:55 GMT
From:      arne@rrzbu.UUCP (Arne Ludwig)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.unix.sysv386,comp.windows.x
Subject:   Re: ESIX 5.3.2-d Sockets how????

johnksun@cbnewse.cb.att.com (john.k.sun) writes:
>	Yes, I 've the same problem when compiling X11R5 on ESIX 5.3.2D
>with TCPCONN in x386.cf.   The X server died in listen() with a bus
>error.

I haven't a clue.

>	I don't have a copy of ESIX streams programmers guide either.
>Would some kind soul out there send me a working short example piece
>of code "me too" ?

The AT&T Streams Programmers Guide is a guide for STREAMS device driver
programmers. It discusses things at kernel level.

So I seriously doubt that even the ESIX version of this manual should
mention a user level function, and much less functions from the Berkeley
emulation library as listen.
-- 
Arne Ludwig		arne@rrzbu.hanse.de	...uunet!??????!rrzbu!arne

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 01:10:21 GMT
From:      darrell@cerberus.bhpese.oz.au (Darrell Boon)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ibm
Subject:   Is there a tn3279 ?


I have seen tn3270 which I guess is emulating an IBM 3278 terminal
is there a graphics terminal emulator available tn3279 that emulates
an IBM 3279 graphics terminal?

I specifically need one to run on a group of PC's.

Public domain or commercial don't care...
-- 
Darrell Boon				Phone   :  +61-49-402-141
Senior Systems Engineer			Fax     :  +61-49-402-165
BHP Information Technology		Internet:  darrell@bhpese.oz.au
P.O. Box 216 Hamilton 2303 AUSTRALIA

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 05:04:06 GMT
From:      guy@trofis.tfrc.csiro.au (Guy Carpenter)
To:        comp.protocols.tcp-ip
Subject:   Re: How the find IP address of remote host

deon@aim1.UUCP (Deon Botha) writes:

>How can I determine the hostname/IP address of a remote host given a user
>has rlogin/telnet connected to my host from the same?

Under SunOS4.1.1, (and presumably most BSD types?) the hostname
is stored in the utmp entry.  I use a tiny bit of C code to
look that up.  I'm sure there are shell script solutions too.

I have a program called "wherefrom", in honour of all of those
baksheesh hunters in Egypt and India who ask repeatedly:
"Hey mister - where from?".

There are no command-line options.  Usage is simply
	wherefrom
But be sure to take into account the fact that the 
field will be blank if the user is logged in from the
console.

I will append the code below.  It's really short.

>Also are there any elegant solutions to printing to a remote PC's printer
>once that PC has logged in to my host via NCSA Telnet. I am currently
>ftp'ing the output file to <calling_pc:prn> which works fine, but this
>assumes I know the hostname/IP address of the PC in question (which of
>course relates to my first question).

That's the way I do it.  I also have a couple of printcap filters
which ftp files to PC's.  So something like "lpr -Phpgl map.hpgl"
is queued on the Sun, then FTP'd to the PC (in this case the host
is constant).  This works pretty well, assuming you can let the
PC in question sit running the FTP server.

Best of Luck,
Guy.

/*----------------------------------------------------------------------
        wherefrom.c             Guy Carpenter                 Jun 19, 1991

        Determine (if possible) from which machine the current
        session is logged in.
 
        This is done simply by looking at the utmp file and
        checking the entry for host name, if remote.

	Works under SunOS 4.1.1, compiling with gcc.
----------------------------------------------------------------------*/
 
#include <utmp.h>
#include <stdio.h>
 
#define UTMP "/etc/utmp"
 
struct utmp *get_utmp ()
{
        static struct utmp utmp;
        int slot = ttyslot();   /* ez lookup of utmp index */
        FILE *utmpf = fopen(UTMP,"r");
        if (!utmpf) return 0;
 
        fseek (utmpf,sizeof(struct utmp) * slot, 0);
        if (fread (&utmp, sizeof(struct utmp), 1, utmpf) != 1) return 0;
 
        return &utmp;
}
 
void main (int argc, char ** argv)
{
        char hostname[17];      /* truncated here */
        struct utmp *u;
        if (!(u=get_utmp())) exit (-1);

        strncpy (hostname,u->ut_host,16);
        hostname[17]=0;
        printf ("%s\n",hostname);
        exit(0);
}

--- code ends ---

-- 
----------------------------------------------------------------------
CSIRO Tropical		P.O. Box 780             Work : (070) 91 1755
      Forest		Atherton Q 4883          Fax  : (070) 91 3245
      Research		Australia                Home : (070) 95 3309

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 07:02:57 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast problems

In comp.protocols.tcp-ip, ub@sapwdf.UUCP (Uwe Bloching) writes:

> While playing with UDP broadcasts I ran into the following problems:
 
> a) a broadcast message sent by my test program could be received by
> all machines in the network except the local machine. 	

	Did u check your network configuration setting in your local machine?
	U can check it using cmd "ifconfig" in Unix host.  Your broadcast
	address setting in the local host must be the same as you set in
	your UDP broadcast program.  Note that there are 2 kinds of broadcast 
	address, all 0 (BSD convention), or all 1 (IP standard).

> b) I could not find out how to send a broadcast message to a different
> subnetwork which is connected via a gateway to the network I was
> doing my tests in. 

	In my understanding, this is not possible if your TCP/IP network is
	a subneted network.  The gateway will automatically filter any
	local subnet broadcast packets in order to prevent broadcast storm. 

	However, it is probably possible if you mandatory set the broadcast 
	address to your destined subnet broadcast address. For example, if
	you are in subnet 137.132.87.X (class B address), and you want to
	broadcast a packet in subnet 137.132.86.X, then your broadcast
	address can be set to 137.132.86.255 (all 1 convention). In this case,
	you have to send a broadcast message for each destined subnet.
	You can try this out and hopefully tell me whether it is possible.

	Any other opinions?
	Hope this helps.

 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgnlc.sgp.hp.com  |
| Singapore 0410                      | HPDesk:    HP3200/67                 |
| Republic of Singapore		      |					     |
 ----------------------------------------------------------------------------
    

      

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 07:18:58 GMT
From:      als@bohra.cpg.oz.au (Anthony Shipman)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Sun's TIRPC package

I would like to know if there is anybody out there trying Sun's new TIRPC
transport independent RPC package.  This is part of their new ONC product and
is used in SysVR4 I believe.

I am looking at porting this to a variety of machines and would like to hear
about what others have tried. 

Does anyone know of any relevant mailing lists or an appropriate news group?

Thanks
-- 
Anthony Shipman                 "You've got to be taught before it's too late,
Computer Power Group             Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia             You've got to be carefully taught."  R&H

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 07:35:57 GMT
From:      dms@celtech.COM (Dave Stanhope)
To:        comp.protocols.tcp-ip
Subject:   X25 access via TCP

Does anyone know of a box that will let me access X25 facilities via
an ethernet connection.  Such a box would have 1 ethernet interface
talking TCP/IP and multiple syncronous interfaces talking X25.  I am
!NOT! looking for a router or a gateway but instead need a box that I
can make a socket connection to and then exercise complete control
over the x25.  I want to use the x25 interfaces as if they were
physically installed in my Unix box.  Via the tcp connection I need
to be able to make calls, read and write packets and have complete
control over x25 facilities in these transactions.  For example, on
writes I need to directly control the Q, D, and M bits.  On reads
I need to be able to see the status of these bits.  Such capability
is normally provided for in the programmers interface for directly
connectted boards.  Sorry to go into so much detail but people keep
trying to sell me routers or telnet to pad translators, neither of
which will work in my applications.  Any help to find such a device
would be greatly appreciated. Please respond to:

               dms@ctsx

                Thanks in advance,
                 David M. Stanhope (206-443-6400)

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 14:11:33 GMT
From:      jel@tuura.UUCP (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast problems

ub@sapwdf.UUCP (Uwe Bloching) writes:

>  b) I could not find out how to send a broadcast message to a different
>     subnetwork which is connected via a gateway to the network I was
>     doing my tests in. 

This is really what you should expect since one of the reasons
routers are used is that they restrict broadcasts to the local network.

However, some routers (e.g. Cisco ones) can be convinced to pass 
selected (on a per port basis) broadcasts from one network to another.
Unfortunately the provided functionality is not perhaps not quite so
general as you would wish.  In any case this can hardly be considered
a good solution since it will work only work if your network happens
to have the correct and properly configured router models.

An alternative could be IP multicast if you can find host software and
routers which implement it.

Perhaps you should consider what you are trying to do with the broadcasts
and figure out some other method: broadcast protocols do not work very
well in wide area networks.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 16:38:27 GMT
From:      lff@sequent.com (Lou Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 access via TCP

dms@celtech.COM (Dave Stanhope) writes:
>Does anyone know of a box that will let me access X25 facilities via
>an ethernet connection.  Such a box would have 1 ethernet interface
>talking TCP/IP and multiple syncronous interfaces talking X25.  
 
>                Thanks in advance,
>                 David M. Stanhope (206-443-6400)

I would call Simpact Associates (1-800-488-4188) and ask them about
their CNS 6000 series LAN-based Communications Servers.  I haven't used
any Simpact products but I heard a presentation on their products and I
think they have exactly what you are looking for.

Good luck,
...Lou
--
Louis F. Fernandez			Sequent Computer Systems
lfernandez@sequent.com			Mail Stop DES2-798
503-578-5113 (voice)			15450 SW Koll Parkway
503-578-5110 (fax)			Beaverton, OR 97006-6063

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 17:21:12 GMT
From:      wclark@lager.cisco.com (Wayne Clark)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ibm
Subject:   Re: Is there a tn3279 ?

In article <1991Oct10.011021.6495@cerberus.bhpese.oz.au> darrell@cerberus.bhpese.oz.au (Darrell Boon) writes:
>
>I have seen tn3270 which I guess is emulating an IBM 3278 terminal
>is there a graphics terminal emulator available tn3279 that emulates
>an IBM 3279 graphics terminal?
>
>I specifically need one to run on a group of PC's.
>
>Public domain or commercial don't care...
>-- 
>Darrell Boon				Phone   :  +61-49-402-141
>Senior Systems Engineer			Fax     :  +61-49-402-165
>BHP Information Technology		Internet:  darrell@bhpese.oz.au
>P.O. Box 216 Hamilton 2303 AUSTRALIA

Darrell -

    There are a couple of tn3270 variants that I'm aware of that do support
    IBM graphics commands:

	1. tn3179G from OpenConnect Systems

		OpenConnect Systems, Inc.
		2033 Chennault Drive
		Carrollton, Texas USA 75006
		214/490-4090

        2. tn3270 (the Windows version) from Wall Data 

		Wall Data Incorporated
		17769 NE 78th Place
		Redmond, WA  98052-4992
		206/883-4777

    Tecnhically speaking, they both emulate a 3179-G (now 3192-G) vector
    graphics terminal.  On 3279 S3G terminals, IBM implemented graphics by
    using Programmed Symbols.  Programmed Symbols effectively mapped the 
    pixels in a 9x16 or 9x12 character box to match the graphics needs of the 
    display.  Fortunately for all of us, IBM no longer does PS-style
    graphics.  
    
    The vector graphics commands (orders) are embedded in the 3270 data stream.

Wayne Clark
wclark@cisco.com
415/688-4627

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 17:49:15 GMT
From:      wclark@lager.cisco.com (Wayne Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: Open Architecture Fast Packet Consortium

In article <18121@leadsv.UUCP> young@force.decnet.lockheed.com writes:
>
>  [... bunch of stuff deleted ...]
>
>The newsletter was targeted at every computer and communications company in the
                             ^^^^^
>United States. The second part of the plan took effect when a number of VLSI 

Never saw it.

>
>  [... bunch of stuff deleted ...]
 
>The final part of the plan occurs when a small company, using the resulting 
>VLSI, builds a completely open architecture platform, compatible with the
>WAVE control system.  We are very close to realizing that final step, and the
>result will be the demolition of IBM SNA, and the birth for Unix, of an
                    ^^^^^^^^^^^^^^^^^^^^^

Fat chance. If you think that the 83% of all Fortune 1000 companies using SNA 
today are going to turn over their corporate networks to a a new, unproven
architecture, you are nuts.  Even the well-established TCP/IP and OSI 
consortia are having difficulty convincing those blue accounts to do this.

>  [... bunch of stuff deleted ...]
 
>
>Our Motto:  Equal access to all layers of the technology.

Peace and love.

>
>Matt Young
>20761 Canyon View Dr.
>Saratoga, CA 95070

Wayne Clark
wclark@cisco.com
(and in neighboring Los Gatos)

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 21:29:30 GMT
From:      buck@pool.info.sunyit.edu (Jesse Buckley)
To:        comp.protocols.tcp-ip
Subject:   The cat x | prog host service question.

A few days ago I posted a message about a program that would let you
send something to service number.  Many people responded with use
telnet.  I'm using ULTRIX 4.2 and cat x | telnet host port doesn't work.
Any other ideas.
-- 

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 22:05:37 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1122 and Backwards Compatibility

In article <14679@scolex.sco.COM> steph@sco.COM (Steph Marr) writes:
>Now we could change this and conform to the specs, or we can actually
>have a useful product which people can use to get work done.  Unfortunately,
>BSD UNIX seems to be the yardstick everyone cares to use, and 4.2 had
>this pointer "wrong" and every implementation I have ever seen, while it might
>have had #ifdef's, was set to be 4.2 compatible, including RENO.

Let me take a moment to clue you in: 4.2BSD was never considered a
yardstick, it was merely a widespread implementation.  It wasn't an
example, it was a problem to be solved.  But 4.2BSD did many, many
things very wrong.  We could have thrown out the standards and just
accepted the BSD implementation as "correct", but this wasn't
satisfactory long term, and it certainly wasn't fair to all the
correct implementations that weren't based on 4.2BSD.  (In the end,
some 4.2BSDisms *were* accepted as standard practice just to allow
interoperability will all the 4.2 implementations, but only when the
practices were reasonably legal according to the standards.)

In the particular case of the urgent pointer, i doubt many people were
to worried about the change.  Most protocols use urgent to convey
non-essential information.  For this reason, a change to typical
urgent handling may have broken some advanced features, but it didn't
affect the general utility of the protocol.  Thus the transisson
period consisted of not using those features until the utilities were
fixed.

Turns out the 4.2BSD protocols, such as rlogin, use urgent in
a way that couldn't actually be supported correctly by TCP.
Consequently, it was understood that those utilities would have to be
revisited to correct those problems, so correct them for the urgent
point mistake wouldn't be a big deal.

I hope this helps you understand the situation better.
							don provan
							donp@novell.com

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 22:13:20 GMT
From:      kjpires@iat.com (Kurt J. Pires)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and PPP compared

Although Appendix B ("Compatibility with past mistakes") of VJ's RFC
suggests possible compatiblity with old SLIP, it does discourage it.

Also, I know that the new Annex software has options for 
"slip_do_compression" and "slip_allow_compression" -- does
anyone know if this uses PPP or is using the Appendix B stuff...

Kurt

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 22:20:04 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,news.admin
Subject:   How to find the domain name for an institution?

On system FTP.NISC.SRI.COM, there's a file called "netinfo/domains"
which is a raw list of domain names compiled over a year ago.  Does
anyone maintain a current list, which contains the names of the
institutions to which they're registered?  Someone here asked me
today, "How do I find out an e-mail address for my friend at XYZ
University?", given a login name and host name but lacking the domain
name.  The following format would be fine by me:

kronos.com		Kronos, Inc.		Waltham, MA  USA
udel.edu		U. of Delaware		Newark, DE   USA

Aside from "archie", is there a central index for useful information
like this anywhere, which isn't so humongous as to be useless?  (Archie,
it seems, became overwhelmed overnight as soon as people discovered it.)
I fear when I post items like this that I'm just reciting yet another FAQ.
An archive of FAQ's, sorted by newsgroup, would be tremendously useful.

-rich

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 91 23:47:12 GMT
From:      ront@kimbark.uchicago.edu (ronald j thielen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ibm
Subject:   Re: Is there a tn3279 ?

Brown University's tn3270 for the Macintosh supports a large subset of 3179G
facilities.  I have used it with both SAS/Graph and GDDM.  The TCP/IP you
connect with must also support extended data streams.  IBM's TCP/IP Version 2
for MVS and TCP/IP Version 2 for VM both support extended data streams.  Other
vendors' TCP/IP product may or may not.

This package may be FTP'd from BROWNVM.BROWN.EDU or ordered by calling
Brown University Computing and Information Services at (401) 863-7247.

I have no affiliation with Brown other than as a user of tn3270.  Please 
direct questions to the above phone number or the author, Peter DiCamillo, 
whose address is "CMSMAINT@BROWNVM.BROWN.EDU".

Ron Thielen
Manager of Operating Systems
University of Chicago - Networking and Large Scale Computing

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 00:06:53 GMT
From:      sandee@Think.COM (Daan Sandee)
To:        comp.protocols.tcp-ip,news.admin
Subject:   Re: How to find the domain name for an institution?

In article <1991Oct10.222004.17032@kronos.com>, richb@kronos.com (Rich Braun) writes:
 [ request for info about internet addresses ]
|> I fear when I post items like this that I'm just reciting yet another FAQ.

    You do.

|> An archive of FAQ's, sorted by newsgroup, would be tremendously useful.

 There is one. It's the newsgroup called news.answers.
 The problem you describe is addressed there.
 Not that the answer will make you entirely happy, but the bottom line is
 *is* no central Internet directory.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 02:40:56 GMT
From:      stuart@fawlty.towers.oz.au (Stuart Walker)
To:        comp.protocols.tcp-ip
Subject:   Talking to daytime/timed daemon

I'm not sure if this is the correct news group to mail this to, but here goes...

This is my first attempt to try and utilise sockets and datagrams.  My aim is
to communicate with one of the time oriented services, either timed or daytime.
The symptoms of the following code is that it simply stops while trying to read
from the socket.  I've played around with various parameters, but can't for the
life of me seem to get the thing to work.

Besides finding out specifically what is wrong with this code, maybe someone
could direct me to some sort of documentation with respect to how to talk
to established services in the Internet domain using datagrams.

Here's the !*&#@$%^& code:


#define	BUF_SIZE	100

int
main(argc, argv)
int argc;
char *argv[];
{
	int		rport;	/* port number for remote socket */
	int		recv_port;	/* sock num for receiving data */
	char		*service_name; /* name of service */
	char		*hostname;
	int		length;
	struct sockaddr_in	lname;
	struct sockaddr_in	rname;
	struct hostent	*hp;
	struct hostent	*gethostbyname();
	/* struct timeval	buffer; */
	char 		buffer [BUF_SIZE];

	hostname = "imagestore";	/* default hostname */
	service_name = "timed";	/* default process to connect to */

	/* Get port number for specified service */
	rport = ipc_serv_port(service_name);
	if (rport<0)
	{
		fprintf(stderr, "ERROR: can't get port no. for service: '%s'\n",
								service_name);
		exit(2);
	}

	/* Create socket from which to read. */
	recv_port = socket(AF_INET, SOCK_DGRAM, 0);
	if (recv_port < 0)
	{
		perror("opening local socket from which to read");
		exit(2);
	}

	/* Create name with wildcards. */
	lname.sin_family = AF_INET;
	lname.sin_addr.s_addr = INADDR_ANY;
	lname.sin_port = 0;

	/* Bind this to the local socket. */
	if (bind(recv_port, (struct sockaddr *) &lname, sizeof(lname)))
	{
		perror("can't bind socket");
		close(recv_port);
		exit(2);
	}

	/* Find the assigned port value, which was allocated by bind. */
	length = sizeof(lname);
	if (getsockname(recv_port, &lname, &length))
	{
		perror("unable to get port number after bind");
		close(recv_port);
		exit(2);
	}

	/* Get network host entry for specified hostname. */
	hp = gethostbyname(hostname);
	if (hp == 0)
	{
		perror("getting network host entry");
		fprintf(stderr, "%s: unknown host\n", hostname);
		close(recv_port);
		exit(2);
	}
	bcopy(hp->h_addr, &rname.sin_addr, hp->h_length);

	rname.sin_family = AF_INET;
	rname.sin_port = rport;

	/* Send an empty datagram - which should act as
	 * a request for the time.
	 */
	if (sendto(recv_port, "", 0, 0, &rname, sizeof(rname)) < 0)
	{
		fprintf(stderr, "ERROR: can't send datagram message\n");
		close(recv_port);
		exit(2);
	}

	fprintf(stderr, "About to try and read a datagram\n");
	if (read((int)recv_port, (char *)buffer, (unsigned)sizeof(buffer)))
	{
		fprintf(stderr, "ERROR: can't read from local socket # %d\n", (int)recv_port);
		close(recv_port);
		exit (2);
	}

	/* printf("This is the value of tv_sec : %ld\n", buffer.tv_sec); */
	printf("This is the value of buffer : ");
	{
		int	i;
		for (i=0; i< BUF_SIZE; i++)
		{	
			printf("%d", (int)buffer[i]);
		}
 puts("");
	}

	close(recv_port);
	exit (0);
}


Please mail replies to this news group, since out mail facilities are not
terribly accessible at the moment.

Regards,

Stuart.
-- 
Internet: stuart@fawlty.towers.oz.au			  Phone: +61 2 427 2999
UUCP:     uunet!fawlty.towers.oz.au!stuart		  Fax:   +61 2 427 7072
Snail:    Tower Technology
	  1 Apollo Place, Lane Cove, NSW 2066, Australia.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 02:54:00 GMT
From:      v102sk2r@ubvmsd.cc.buffalo.edu (LIPCHEN ALEX CHAN)
To:        comp.protocols.tcp-ip
Subject:   ftp problem


Dear friend,

I created some files using Frame Maker 2.1x few months ago. I saved
them in Frame Maker Format in unix mainframe until I downloaded them 
into 3.5 inch disk using FTP. I deleted all Frame Maker files inside
unix mainframe in order to save some memory space.

Now, I need to use these files again. Therefore I uploaded them to
unix mainframe this morning using FTP again. However, when I tried to 
open these files using Frame Maker 3.0x, there was a caution saying that 
I was opening a Frame Maker 2.1 files, which is a normal situation.
After I clicked OK, I got a message that there was a problem to 
open these files and asked me to consult machine or network operator.
Then I recalled that I didn't set the FTP to binary when I download
and upload these files. I afraid that some distortion has occurred 
to these files when I first downloaded them.

My question is whether these files could possibly be accessed again
using Frame Maker. If yes, how can I do it? I really hope that I
can recover these files again because they cost me two months
of hard labor. Thanks in advance for your suggestion and help.


Alex Chan

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

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 03:26:23 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Assigning one IP address into 2 ethernet addresses

Hi netlander,

	Consider the following scenario:

	--------------------------------------------
	  |				|
	 ---			      -----
         |A|			     |  B  |
	 ---			      -----
	  |				|
	----------------------------------------------

	Is it possible to assign one IP address into two different ethernet
	addresses (two ethernet card) for host A and B? The purpose of doing
	this is to provide reliablity thru redundany. When one ethernet fails,
	the host A and B will automatically switch to another ethenet without
	the TCP application notice it because of there are 2 route paths. 
	If this is possible, how ARP selects one of the ethernet addresses?

	Thanks in advance.

 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgnlc.sgp.hp.com  |
| Singapore 0410                      | HPDesk:    HP3200/67                 |
| Republic of Singapore		      |					     |
 ----------------------------------------------------------------------------
    

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 03:42:52 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP vs X.25 in a close environment

Hi netlander,
	
	Given two hosts situated in the close environment (location), which
protocols (TCP vs X.25) is best suited to connect them in terms of 
performance, reliability, flexibility, maintanence, expandability 
and availiablity? 
	Below are some my observations:

	1) TCP/IP can run on top of LAN already installed, but X.25 requires 
	a delicate link. Or X.25 can run on top of LAN (ethernet)?

	2) Both of them are not optimized for connecting hosts in a close
	and short distance environment. But which one performs better?
	X.25 because of dedicate link? In terms of protocols itself, which
	one incurs more overhead? Any experience? No religion debate please.

	3) Both of them cannot handle failure of physical link. However,
	if the X.25 card or LAN card are replicated, which one provides a
	better failure-transparency (i.e. less impact on the application when
	the link/LAN is down)?

	Thanks in advance.

 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgnlc.sgp.hp.com  |
| Singapore 0410                      | HPDesk:    HP3200/67                 |
| Republic of Singapore		      |					     |
 ----------------------------------------------------------------------------

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 04:50:04 GMT
From:      johnksun@cbnewse.cb.att.com (john.k.sun)
To:        comp.unix.sysv386,comp.windows.x,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: ESIX 5.3.2-D Sockets for (X386 1.2) X11R5 how????

>> I wrote:
>>>	Yes, I 've the same problem when compiling X11R5 on ESIX 5.3.2D
>>>with TCPCONN in x386.cf.   The X server died in listen() with a bus
>>>error.

	This is due to the way ESIX handles the listen() call.
	See below.

>>
 In article <2371@rrzbu.UUCP> arne@rrzbu.UUCP (Arne Ludwig) writes:
>>I haven't a clue.
>>
>>>	I don't have a copy of ESIX streams programmers guide either.
>>>Would some kind soul out there send me a working short example piece
>>>of code "me too" ?
>>
>>The AT&T Streams Programmers Guide is a guide for STREAMS device driver
>>programmers. It discusses things at kernel level.
>>
>>So I seriously doubt that even the ESIX version of this manual should
>>mention a user level function, and much less functions from the Berkeley
>>emulation library as listen.
>>-- 
 From article <1991Oct10.193225.6768@stortek.com>, by v044595@stortek.com (Jeff Jennings):
> this is incorrect.  as a proud owner of a copy of the ESIX Network/Streams
> Manual, i can say with some authority that is does indeed mention user
> level functions such as listen(), bind(), sendto(), etc.
> 
	Yes, this is true.  I called ESIX tech support and they FAX
me the 30 pages of Appendix A which contains the list of TLI and socket
calls with its appropriate parameters and types.

> for the above questions on getting sockets to work, even with the manual
> i have not been able to get anything to work.  ESIX decided to implement
> sockets on top of the TLI interface, and the socket functions have 
> additional parameters related to TLI structures.  trying a simple client
> server program (like from Stevens' book) results in a core dump, obviously
> because the parameters on the stack do not match what the library call is
> expecting.
> 
	I've finally gotten the sockets to work with ESIX 3.2.D.  Try
the examples from Stevens Pages 360 to 366 with TLI and incorporate the ESIX
socket calls.  In ESIX, bind() needs a backlog as the last parameter, and
both listen() and accept() needs a struct t_call* callptr.  Furthermore,
read() and
write() are unusable for sockets on ESIX unless the "timod" module is popped
and the "tirdwr" module is pushed onto the streams head.  The
pseudo-socket send() and recv() calls can be used instead of read() and
write().  However, I still can't get X11R5 to work under ESIX 5.3.2.D
*yet*.  The server came up with a screen I specified in Xconfig with a
X cursor.  But the screen froze from this point on.  Logging on from another
terminal reveals that both the xinit and X process were dead.  In .xerr,
I see the lines contains the X386 1.2, X11R5 banner and ET4000 clocks
information.  After that, 2 lines of error message from xinit:

xinit:	giving up. (interrupted system call).  Unable to connect to X server.
xinit:	Server error.  (no such process)

	Anybody has any ideas?  I suspect the problem is still with
communication.  I've change the #define's ReadFromServer and
WriteToServer in ./lib/X/Xlibnet.h to use send() and recv() and I've
change the server side with the pseudo-sockets way of accepting
connections.  "timod" has been popped and "tirdwr" been pushed right
after the accept() call.  The font server stuff that deals with
connections have also been modified appropriately.

			Thanks for any additional information,

			-----John
			jksun@ihlpl.att.com

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 08:04:49 GMT
From:      robert@swanee.ee.uwa.oz.au (Roberto Togneri)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   lpd local printer filtering with a remote printer


Hi,
   We have a LaserJet remotely connected to a Sun. To print PostScript
we are using NeWSprint which is running on the local Sun. Now the lpd
service only runs printer filters with a local printer, however, I would
like to perform the NeWSprint filtering on the Sun and then have the output
sent to the remote printer. I have found a way around this by having
lpd print to a local file and then having that file printed remotely. 
However, at about 1 Mb per page this will create a very big file.

I remember a previous news posting that somebody had managed to rewrite
lpd so that it could perform filtering locally for remotely connected
printers. I would like to know whether somebody has in fact done this
and whether it would solve the above problem (i.e. a printer output file
is not created but the local lpd somehow connects to the remote lpd and sends
the output directly to the printer and not as queued file in /usr/spool/lpd;
which is normally how remote printing works).

Thanks for any information that you can provide,
--
Dr. Roberto Togneri                         Phone: +61-9-380-2535
Digital Signal Processing Research Group
Dept. of Electrical & Electronic Engineering
The University of Western Australia         Fax:   +61-9-380-1065
NEDLANDS WA 6009 Australia                  Email: robert@swanee.ee.uwa.oz.au

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 10:04:59 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: subnets with different masks

peter@ski.austin.ibm.com (Peter Jeffe 512.838.4019) writes:

>                 en0                     en1
>    address    832f0407 (131.47.4.7)   832ffe01 (131.47.254.1)
>    mask       fffffc00                ffffff80
>    subnet     832f0400                832ffe00
 
>They want all traffic for addresses from 131.47.4.1 through 131.47.7.254
>to be routed through en0, which seems reasonable enough to me.  But the

I think so, too

>So my question is: is there some good reason to disallow this
>arrangement, other than that it's confusing as hell?  It seems to me

I agree with that observation also

>that as long as the subnets are unique for all the values of the masks
>(as in this case), there is no ambiguity.  And if there is an overlap
>due to poor address selection, it's no worse an ambiguity than exists
>now.  So why not compare the subnet value of the interface with the
>destination address masked by the interface's subnet mask, instead of
>simply comparing net values?

Isn't that what is supposed to happen? From rfc-950:

  IF bitwise_and(dg.ip_dest, my_ip_mask)
			  = bitwise_and(my_ip_addr, my_ip_mask)
  THEN
      send_dg_locally(dg, dg.ip_dest)
  ELSE
      send_dg_locally(dg, gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

  It may or may not be necessary to modify the "gateway_to" function,
  so that it too takes the subnet field bits into account when performing
  comparisons.

  To support multiply-connected hosts, the code can be changed to keep the
  "my_ip_addr" and "my_ip_mask" quantities on a per-interface basis; the
  expression in the conditional must then be evaluated for each interface.

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 10:14:56 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast problems

jel@tuura.UUCP (Jerry Lahti) writes:

>>  b) I could not find out how to send a broadcast message to a different
>>     subnetwork which is connected via a gateway to the network I was
>>     doing my tests in. 
 
>This is really what you should expect since one of the reasons
>routers are used is that they restrict broadcasts to the local network.

Then what's the purpose of the 'all subnets directed broadcast' ?
 {<Network-number>,-1,-1}

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 13:25:26 GMT
From:      jjohnson@ewsvax.mdcbbs.com
To:        comp.protocols.tcp-ip
Subject:   telnet client CR/LFs -Sun vs HP

Hi everyone,

I was presented with the following problem from another user:
 A Telnet session is established to a remote machine and somehow the telnet
 client is reconfigured to send LF characters (ASCII 10) in place of CR 
 characters (ASCII 13).  This occurs with HP and DEC-Ultrix telnet clients
 connecting to an Emulex telnet server.  It does not occur with the Sun or
 Wollongong-VMS telnet clients.  How can this mapping/substitution be prevented
 (i.e. the Emulex server is expect CR's and not LF's) ?

Apparently the Emulex is wired into the back of another machine that can't
directly do telnet sessions and so the Emulex acts as a go-between. Please
e-mail any suggestions as I'm not a regular member of this newsgroup.. Thanks
in advance!

Jeff Johnson
jjohnson%ewsvax.decnet@mdcgwy.mdc.com

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 14:10:36 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.protocols.tcp-ip
Subject:   Re: The cat x | prog host service question.

In article <1991Oct10.212930.15439@pool.info.sunyit.edu> buck@pool.info.sunyit.edu (Jesse Buckley) writes:
>A few days ago I posted a message about a program that would let you
>send something to service number.  Many people responded with use
>telnet.  I'm using ULTRIX 4.2 and cat x | telnet host port doesn't work.
>Any other ideas.

1) For a short file (i.e., whatever will fit in memory), you can read
the whole file in and shoot it back out, with this Expect script.

	spawn telnet host port
	#
	# do your send/expect interaction here or whatever is demanded
	# by your port owner.  (I.e., login if necessary.)
	#
	expect_user eof;		# read til EOF
	send $expect_match;		# send whatever came in, out

2) For infinite (or comparatively large) or unbuffered files, you can
read a line, bufferful or whatever at a time in a loop

	spawn telnet host port
	#
	# ... as above ...
	#
	for {} 1 {} {
		expect * {send $expect_match} eof exit
	}

This particular script will loop sending whatever is received, however
the kernel decides to chunk it.  When eof is received, it will exit.

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

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 14:58:15 GMT
From:      cudep@warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP to the "new nic"

In article <13543@castle.ed.ac.uk> ercm20@castle.ed.ac.uk (Sam Wilson) writes:
>I'm involved in setting up an IP and DNS service in the UK.  Before the
>move, during the morning here (the wee small hours at the NIC, wherever
>in the US it might be situated) the connection to MILNET was often (>50%
>of attempts?) broken due to routing loops.  These took minutes to clear,
>during which time the NIC and its NS were out of contact.  It has
>improved slightly since the move - now I more often get network
>unreachable for the new NS address.

I'm involved in the same service as Sam, and I've yet to make a *single*
connection to the new nic - not from my hosts, or from accounts around the
world.  I don't know the cause but it's far from ideal.

Cheers,
--
Ian
-- 
\/ato - Ian Dickinson                Let the Bobbies come running to
vato@csv.warwick.ac.uk               *this* user unfriendly package!
..!mcsun!uknet!warwick!vato
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 15:54:40 GMT
From:      jcobban@bcars5.UUCP (Jim Cobban)
To:        comp.protocols.tcp-ip
Subject:   Re: WAVE: A New Executable Protocol for TCP-IP

In Article: 9590 of comp.protocols.tcp-ip

>A research project at Lockheed as resulted in an implementation of
>waves, a distributed language which operates over LANs and WANS.  This
>language is pseudo code based and propagates into the network, executing
>at each node, replicating parts of itself and re-propagating on the
>outgoing links.  The language can carry variables with it, update variables
>at each node, or execute system specific system calls at each node.

This item seems to me to be a massive virus attack looking for a place
to happen. The most serious failures of massively interconnected
computer networks that I can think of were not caused by deliberate
virus attacks. Deliberate virus attacks have caused havoc on the
individual computers attached to the network, but have had little or no
effect on the network itself. The massive network failures, in
particular the Internet Worm and the IBM Christmas Tree Worm, were the
result of small defects in what were intended to be relatively
innocuous, amusing, programs which took advantage of a feature of the
network which allowed for transmitting executeable code.

The concept here is one which would appear highly laudable to a
university math specialist: instead of spending all of our time
figuring out ever more and more complex specialized protocols for
doing various functions in the network, which must then be tested for
compliance to the standard, so that two distinct implementations can
talk to one another, we bypass the whole problem and arrange a
mechanism by which we ensure that the same program is running at
both ends of any communication.  If it is the same program, then there
is no need to worry about compatibility, and therefore no advantage to
building complex protocols to handle every contingency imagineable for
a particular application.

However this proposal eliminates a major roadblock to the propagation
of a worm style network virus.  At present a worm must be designed to
satisfy the operational environment of the host which it infects.
For example the Internet Worm hit VAXes running UNIX.  In an environment
with a different command language, or different machine code, the
worm dies.  However a WAVES based worm could thrive in any machine
which implemented the WAVES protocol.

-- 
-------------------------------------------------------------------------------
Jim Cobban   |  jcobban@bnr.ca                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars277!jcobban       |  FAX:   (613) 763-2626

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 16:14:01 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: WAVE: A New Executable Protocol for TCP-IP

In article <1991Oct11.155440.556@bigsur.uucp> jcobban@bcars5.UUCP (Jim Cobban) writes:
>... The massive network failures, in
>particular the Internet Worm and the IBM Christmas Tree Worm, were the
>result of small defects in what were intended to be relatively
>innocuous, amusing, programs...

For a program intended to be innocuous and amusing, the Internet Worm
sure spent a lot of effort trying to cover its tracks and obscure its
operations.
-- 
In operating-system code, log(quality)  | Henry Spencer @ U of Toronto Zoology
times quantity is a constant.           |  henry@zoo.toronto.edu  utzoo!henry

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 16:30:28 GMT
From:      anthes@geocub.UUCP (Franklin Anthes)
To:        comp.protocols.tcp-ip
Subject:   DNS client config. for SunOS 4.1.1


I followed the instructions for configuring the DNS client software
as given in the Sun Manuals, by putting the follwing in /etc/resolv.conf:


domain turbomeca.fr.
nameserver 1.2.8.2

Now this works fine with several machines (A/UX etc.). The nameserver
at 1.2.8.2 is running fine with Macs,PCs, and VMS systems, so that isn't the 
problem. As a matter of fact, if I run nslookup on the sun, it works quite
well.

This problem has me stumped, so if someone could help me out, I'd sure be
grateful!


-- 

	Frank Anthes-Harper :  Bien le bonjour de la France
	anthes@geocub.greco-prog.fr

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 18:49:01 GMT
From:      kramer@bellhop..bellcore.com (Mike Kramer)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Sun's TIRPC package

In article <1991Oct10.071858.12540@bohra.cpg.oz.au> als@bohra.cpg.oz.au (Anthony Shipman) writes:
>I would like to know if there is anybody out there trying Sun's new TIRPC
>transport independent RPC package.  This is part of their new ONC product and
>is used in SysVR4 I believe.
>
>I am looking at porting this to a variety of machines and would like to hear
>about what others have tried. 
>
>Does anyone know of any relevant mailing lists or an appropriate news group?
>
>Thanks
>-- 
>Anthony Shipman                 "You've got to be taught before it's too late,
>Computer Power Group             Before you are six or seven or eight,
>19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
>Melbourne, Australia             You've got to be carefully taught."  R&H


I have tried installing Sun's TIRPC package on one of their own SPARCstations,
and installation was not trivial! First, you have to apply some modifications
to the SUNOS 4.1.1 kernel, including the inclusion of encryption capabilities.
These are available as seperate updates from SUN.

After that, you should be able to run the supplied Makefile and 
have it install itself. Well, there is a bug in the Makefile 
and it took me two days of work to figure out what the problem is
and to get it installed. The problem was not actually so severe -
some files were not copied into the right directory and the 
cc command failed to find them. I had some e-mail help from someone 
at SUN for which I am grateful. They stil haven't fixed the bug though! 

I imagine that if installing it on a SPARC was painful, that it 
will not be a piece of cake to port. But I really have no experience
on this, so I defer to any other opinions! 

Mike Kramer
kramer@thumper.bellcore.com 

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 19:27:56 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip
Subject:   Re: The cat x | prog host service question.

In article <1991Oct10.212930.15439@pool.info.sunyit.edu> buck@pool.info.sunyit.edu (Jesse Buckley) writes:
>A few days ago I posted a message about a program that would let you
>send something to service number.  Many people responded with use
>telnet.  I'm using ULTRIX 4.2 and cat x | telnet host port doesn't work.
>Any other ideas.

 Do you mean something like this:

Script started on Fri Oct 11 14:22:33 1991
rickert 1> echo QUIT | /usr/etc/mconnect -p 119 mp
connecting to host mp (131.156.1.2), port 119
connection open
201 mp.cs.niu.edu NNTP server version 1.5.11 (10 February 1991) ready at Fri Oct 11 14:23:31 1991 (no posting).
205 mp.cs.niu.edu closing connection.  Goodbye.

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

  No.  I don't know where to fine mconnect sources.  At one time they
were packed with 'sendmail' sources.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 21:04:58 GMT
From:      dez@vulture.ATT.COM (MoonD)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Problem using Legato's nhfsstone

Hi netters,

I am trying to benchmark nfs using Legato's nhfsstone.
I ran nhfsstone on my machine(diskless Sun 3/60,nfs client).
The output of "nhfsstone <dir1> <dir2>" looks like:

nhfsstone: INVALID RUN, mix generated is off by 104.00%
op        want       got    calls      secs  msec/call    time %
null        0%     0.00%        0      0.00       0.00     0.00%
getattr    13%     5.31%       55      0.39       7.09     0.53%
setattr     1%     0.87%        9      0.46      51.11     0.63%
root        0%     0.00%        0      0.00       0.00     0.00%
lookup     34%     9.38%       97      1.71      17.62     2.36%
readlink    8%     0.77%        8      1.04     130.00     1.43%
	:
	:

Why does it say INVALID RUN?  What could I possibly be doing wrong?
I would appreciate any help.

Deseree Moon
3030-538-4450
dez@druhi.att.com

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 21:21:31 GMT
From:      greenie@drycas.club.cc.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   Telnet responds with "Not Sending Options"

When I telnet to certain sites with a /PORT specifier, I keep getting the
message "Not Sending Options"... and it prevents the line feeds and carriage
returns from echoing properly - the results is that all the text scrolls right
on over to the right side of the screen and stays there.

Does anyone know how I can remedy this?  I'm using CMU-TEK TCP/IP...

Andy, greenie@drycas.club.cc.cmu.edu

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 91 21:28:13 GMT
From:      orand@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip,rec.radio.amateur.packet
Subject:   KA9Q on Ethernet (help wanted)


    Does anyone out there have any experience running KA9Q_NOS on a
hard-wire network?  I want to try to get it to run on our Ethernet
experimentally and see if I can get a full NNTP feed here.  Any
experiences?

    Brady...

-- 
===========================================================================
                    Brady Orand - Network Specialist
        University of Kansas Department of Engineering Computing
              3043 Learned Hall     Lawrence, Ks    66045

ORAND@kuhub.cc.ukans.edu            **  Intelligent quote goes here.     **
Work:  (913) 864-3250               **  When I think of one, I'll add it.**
Home:  (913) 749-1341               **                 - Anonymous       **
===========================================================================

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 91 00:54:28 GMT
From:      dixon@sagittarius.crd.ge.com (walt dixon)
To:        comp.protocols.tcp-ip
Subject:   Help wanted with UDP Broadcast (Long)

I am looking for a way to locate a service on an IP subnet from
outside that subnet.  Based on a somewhat limited understanding
of the IP protocol suite,  it would seem that I could send a udp
packet to the subnet broad cast address.  I don't read this news
group regularly.  When I checked the currently available articles,
I found a couple of references to this topic,  but no definitive
answer.

I have tested the two enclosed simple programs.  The test environment
consisted of a sun3 on the backbone network and two processors on a
separate ip subnet running vxworks.  I loaded the "client" code onto
both processors on the ip subnet.  One of these processors also serves
as a gateway node.  The process running on the gateway node received
the broadcast;  the other process did not receive it.  Is this reasonable
behavior or is there an obvious problem with the code.  Alternatively,
can any one suggest another way to do what I want.
================== sun3 (server) code
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

long    msgbuf = 0x12345678;

void    main(argc,argv)
int     argc;
char    *argv[];
{
   int                   sockfd;
   struct sockaddr_in    server_addr,client_addr;

   /*
   **
   **  Allocate socket descriptor for talking to the client.
   **  AF_INET       use INET (TCP/IP) protocols
   **  SOCK_DGRAM    connectionless protocol
   **
   */

   if((sockfd = socket(AF_INET,				    /* if can't create socket */
		       SOCK_DGRAM,
		       0           )) < 0) {
      printf("Can't open socket\n");			    /* print error and quit */
      exit(1);
    }							    /* end if can't create socket */

   bzero((char *)&client_addr,sizeof(client_addr));
   client_addr.sin_family = AF_INET;
   client_addr.sin_addr.s_addr = inet_addr("3.1.123.255");
   client_addr.sin_port = htons(6000);

   bzero((char *)&server_addr,sizeof(server_addr));
   server_addr.sin_family = AF_INET;
   server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
   server_addr.sin_port = htons(0);

   if(bind(sockfd,
	   (struct sockaddr *)&server_addr,
	   sizeof(server_addr)            ) < 0) {
      printf("Can't bind\n");
      exit(2);
    }
  
   if(sendto(sockfd,
	     &msgbuf,
	     sizeof(long),
	     0,
	     (struct sockaddr *)&client_addr,
	     sizeof(server_addr)     ) != sizeof(long)) {
        printf("Send error\n");				    /* print error and quit */
	exit(3);
      }							    /* end if read fails */
}							    /* end server */

==================== vxworks (client) code ===================
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

long    msgbuf;

void    client()
{
   int                   sockfd;
   struct sockaddr_in    server_addr;
   struct sockaddr_in    client_addr;
   int                   server_len;
   int                   n;
   int                   optval;

   bzero((char *)&server_addr,sizeof(server_addr));
   server_addr.sin_family = af_inet;
   server_len = sizeof(server_addr);

   if((sockfd = socket(af_inet, sock_dgram, 0)) < 0) {	    /* if unable to create socket */
      printf("can't open socket\n");			    /* print error and quit */
      exit(1);
    }							    /* end if can't create socket */
   
  if(setsockopt(sockfd,sol_socket,so_reuseaddr,&optval,sizeof(int)) < 0)
  {
    printf("cant set options\n");
    exit(4);
  }

   bzero((char *)&client_addr,sizeof(client_addr));
   client_addr.sin_family = af_inet;
   client_addr.sin_addr.s_addr = htonl(inaddr_any);
   client_addr.sin_port = htons(6000);
   if(bind(sockfd,
	   (struct sockaddr *)&client_addr,
	   sizeof(client_addr)            ) < 0) {
      printf("can't bind\n");
      exit(2);
    }
  
   n = recvfrom(sockfd,
		&msgbuf,
		sizeof(long),
		0,
		&server_addr,
		&server_len      );
   if(n < 0) {
     printf("receive error\n");
     exit(4);
   }							    /* end if read failed */
   else
     printf("client: received packet from %08x\n",
	    server_addr.sin_addr.s_addr);
}

i've looked everywhere i can think of to find the answer to this
question.  I have a call in to Wind River (they sell vxWorks).
Sometimes their tech support is able to answer questions; other
times it is not.

please respond directly to me and i will summarize the replies.

thanks

walt dixon		{internet:	dixon@crd.ge.com	}
			{us mail:	ge-crd			}
			{		po box 8		}
			{		schenectady, ny 12301	}
			{phone:		518-387-5798 (w)	}
			{		518-875-6203 (h)	}

--
Walt Dixon dixon@crd.ge.com

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 91 16:50:33 GMT
From:      allyn@netcom.COM (Mark Allyn)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.appletalk,comp.unix.questions,comp.sys.novell
Subject:   print serving for different networks

I have an interesting request from a friend of mine who is in a group
with ibm pc's, mac's, and unix boxes in a mismash of networks. Most of
the various boxes of all types have an associated printer. These printers
are  usually the junky el-cheapo dot matrix printers of days gone past
and they have not been well cared for. They work, but barely. The group
needs to have a variety of parts and supplies on hand to keep these
printers, which are scattered in a 50,000 square foot area, running.

Well, my friend wants to consolidate the print functions to a few high
performance laser printers located in a central location that can be
easily cared for and maintained. In addition, he needs to maintain some
administrative control of the printers so that no sensitive data is 
printed without proper authorization (you know the typical management
paranoia).

There are about 50 to 70 machines of various flavors in the facility.
Most are ibm pc's. Some are apple mac's, and a select few are
unix boxes. The ibm pc's are on either novell, lan manager, or something
called lc or elsee or whatever network. This lc sounds like something
pre-historic since he muttered that it is nothing much more than serial
lines from pc to pc. 

What I would like to propose to him is to assign one of the higher
performance unix boxes (probably a sparcstation 2) to be a dedicated
print server with two or three high performance printers attached to it
in a central location. He thinks he can get the printers fairly easily 
from another source within his company.

The catch, of course is to get everything talking with each other to
the point that all of the machines can send their print jobs to this
central print server. Since there are large numbers of machines, whatever
he does, he has to do cheap. He is especially interested in something
that is public domain or very cheap. He and I are willing to hack at it
if we can get sources. We have access to unix boxes and pc's with C
compilers to do any building if we have to. 

The unix to unix stuff is no problem. What we want in particular is
stuff that can reside in the pc's (especially those running the old
lc network) that can make them talk tcp-ip over a 3com ethernet board
and that can become a bsd lpr client that can be attached to one of
the printer devices (lpr1 or lpr2). On the novell stuff, is there
appropriate cheap or public domain source available for the unix box
so that it can understand novell or the pc so that it can be a tcpip
lpr client as well as a novell client?

As far as the mac's are concerned, I am hoping that maybe we could
get an ethernet card for one of them in the appletalk network and make
that machine a gateway or maybee get something like the gatorbox. Which
would be the cheapest and most reliable for printing. We only want the
printing aspect for it. We don't care about file sharing or x window
stuff. Again, if we can get free pub domain sources, we can get to a 
mac with compilers.

Thanks for your help.
Mark Allyn
(206) 526-8852 nites
(206) 865-4699 days
or send mail to allyn@netcom.com 

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 91 02:14:12 GMT
From:      buck@pool.info.sunyit.edu (Jesse Buckley)
To:        comp.protocols.tcp-ip
Subject:   Re: The cat x | prog host service question.

In article <1991Oct11.192756.7572@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>
> Do you mean something like this:
>
 Yep.
>
>  No.  I don't know where to fine mconnect sources.  At one time they
>were packed with 'sendmail' sources.
>
 I'll start the hunt.
>-- 
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
>  Northern Illinois Univ.
>  DeKalb, IL 60115                                   +1-815-753-6940


--
-Buck (buck@sunyit.edu)
"Just go with the flow control, roll with the crunches, and, when you
get a prompt, type like hell."
-- 

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 91 13:57:52 GMT
From:      dpayne@isis.cs.du.edu (Dirk Payne)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Sun's TIRPC package

If you're willing to go outside Sun, a company here in Colorado is doing
extensive work in TIRPC across (IMHO) tremendous numbers of platforms and
protocols. They support DECnet, LAN manager (MickeySoft), SNA, NetBIOS,
HP's NetIPC, Novell Netware, and of course, TCP/IP. All of the platforms I
mentioned are currently shipping!!!

Netwise 2477 55th St., Boulder, CO 80301 (303) 442-8280.
--
===============================================================================
"If at first you don't succeed ... hack, hack again!!"    dpayne@isis.cs.du.edu
===============================================================================

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 91 15:06:37 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: Secondary nameserver won't refresh itself - RESOLVED

In <1991Oct8.163604.4374@ccu.umanitoba.ca> mills@ccu.umanitoba.ca (Gary Mills) writes:

>I'm having a problem with a secondary DNS server that won't refresh
>itself.  When I update a file on the primary, including updating
>the serial number and kill -1ing it, the secondary never gets the
>updated information.  I have to kill and restart the secondary to
>make it refresh itself.  What could I be doing wrong?  Both machines
>run SunOS 4.1.1, with Sun's in.named.  [...]

This story has a happy ending.  Thanks to all of you who sent suggestions.
I obtained Berkeley bind.4.8.3 from an ftp site, ported the named portion
to SunOS 4.1.1 (took a couple of hours), and installed /usr/etc/in.named
and /usr/etc/in.named-xfer on the secondary DNS server.  After that, when
I updated a file on the primary, the secondary would refresh itself within
the refresh interval specified on the SOA record.  I assume that Sun's
named has some bug that prevents the automatic refreshes.  By the way,
Sun recently released a patched version of in.named-xfer.  I had previously
installed this, but it had no effect on the refresh problem.
-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 00:05:58 GMT
From:      pae@netwise.com (Phil Earnhardt)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Sun's TIRPC package

In article <1991Oct13.135752.6058@mnemosyne.cs.du.edu> dpayne@isis.cs.du.edu (Dirk Payne) writes:
>If you're willing to go outside Sun, a company here in Colorado is doing
>extensive work in TIRPC across (IMHO) tremendous numbers of platforms and
>protocols. They support DECnet, LAN manager (MickeySoft), SNA, NetBIOS,
>HP's NetIPC, Novell Netware, and of course, TCP/IP. All of the platforms I
>mentioned are currently shipping!!!
>
>Netwise 2477 55th St., Boulder, CO 80301 (303) 442-8280.

I'm an engineer at Netwise; Dirk's posting may be a bit confusing.

Netwise's RPC TOOL is indeed available over a variety of platforms and
transports. This is different from Sun's TIRPC. Just to add to the confusion
somewhat, we do have a version of our tool which runs on top of TIRPC.

As I remember, the original question was what issues folks had installing
Sun's TIRPC package. Other than being a user of TIRPC, Netwise can't help much
with that. I didn't install it here myself and don't know anything about the
issues involved. On the other hand, if you're interested in Netwise's tool,
the sales types would be more than happy to assist.

Hope this clears up any confusion.

Phil Earnhardt		pae@netwise.com
Netwise, Inc. 		Boulder, CO  (303) 442-8280

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 02:44:32 GMT
From:      dpayne@isis.cs.du.edu (Dirk Payne)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Sun's TIRPC package


	My apologies if my last message was misunderstood. I did not mean to 
imply that Netwise RPCTOOL was Sun TIRPC. My reason for stating the option of 
Netwise products was in a response to the original poster, stating that the
current version was not what the sender was expecting (read: rough road).

	Just trying to be helpful, you know!

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

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 02:46:16 GMT
From:      johng@uniwa.uwa.oz.au (John Gibbins)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS client config. for SunOS 4.1.1

I had problems mailing to your address so I am posting a response:

In comp.protocols.tcp-ip you write:

>I followed the instructions for configuring the DNS client software
>as given in the Sun Manuals, by putting the follwing in /etc/resolv.conf:
 
>domain turbomeca.fr.
>nameserver 1.2.8.2
 
>Now this works fine with several machines (A/UX etc.). The nameserver
>at 1.2.8.2 is running fine with Macs,PCs, and VMS systems, so that isn't the
>problem. As a matter of fact, if I run nslookup on the sun, it works quite
>well.
 
>This problem has me stumped, so if someone could help me out, I'd sure be
>grateful!

Your message doesn't say what doesn't work!
I assume that your problem is that normal programs (eg ftp, ping etc)
are failing to access the nameserver.  This happens on suns because the
normal gethostbyname() library call does not call the resolver.  There
are two solutions to this.  The first (and simpler one if you don't
mind NIS) is to run NIS (aka YP) and to modify the /var/yp/Makefile to
add a -b flag to the makedbm commands for the hosts.time entry:
Makefile:
...
hosts.time: $(DIR)/hosts
...
                | $(MAKEDBM) - -b $(YPDBDIR)/$(DOM)/hosts.byname; \
...
                | $(MAKEDBM) - -b $(YPDBDIR)/$(DOM)/hosts.byaddr; \
...


The second method (which I use because I don't want to run NIS), is to
build a new copy of the shared c library libc.so including the routines
from libresolv.  This replaces the gethostbyname call with one that
does call the resolver.  If you want to do this, I have a modified
version of the /usr/lib/shlib.etc/README file which describes in detail
how to do this.

Regards
johng
--
John Gibbins
The Western Australian Research Institute for Child Health
The University of Western Australia
GPO Box D184                              Internet: johng@uniwa.uwa.oz.au
PERTH  W.A. 6001                          Phone:    61-9-3408547
AUSTRALIA                                 Fax:      61-9-3883414
-- 
John Gibbins
The Western Australian Research Institute for Child Health
The University of Western Australia
GPO Box D184                              Internet: johng@uniwa.uwa.oz.au

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 05:09:17 GMT
From:      kory@avatar.com (Kory Hamzeh)
To:        comp.protocols.tcp-ip
Subject:   What is the purpose of trailer ARPs?

Can anyone explain to me the purpose of Trailer ARPs? I have not been 
able to find a description of it in any RFCs. If it is mentioned in a
RFC, please let me know the RFC number.

Thanks,
Kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com 

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 06:33:11 GMT
From:      wclark@lager.cisco.com (Wayne Clark)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ibm
Subject:   Re: Is there a tn3279 ?

In article <1991Oct10.172112.12066@csl.sri.com> wclark@lager.cisco.com (Wayne Clark) writes:
>In article <1991Oct10.011021.6495@cerberus.bhpese.oz.au> darrell@cerberus.bhpese.oz.au (Darrell Boon) writes:
>>
>>I have seen tn3270 which I guess is emulating an IBM 3278 terminal
>>is there a graphics terminal emulator available tn3279 that emulates
>>an IBM 3279 graphics terminal?
>>
>>I specifically need one to run on a group of PC's.
>>
>>Public domain or commercial don't care...
>>-- 
>>Darrell Boon				Phone   :  +61-49-402-141
>>Senior Systems Engineer			Fax     :  +61-49-402-165
>>BHP Information Technology		Internet:  darrell@bhpese.oz.au
>>P.O. Box 216 Hamilton 2303 AUSTRALIA
>
>Darrell -
>
>    There are a couple of tn3270 variants that I'm aware of that do support
>    IBM graphics commands:
>
>	1. tn3179G from OpenConnect Systems
>
>		OpenConnect Systems, Inc.
>		2033 Chennault Drive
>		Carrollton, Texas USA 75006
>		214/490-4090
>
>        2. tn3270 (the Windows version) from Wall Data 
>
>		Wall Data Incorporated
>		17769 NE 78th Place
>		Redmond, WA  98052-4992
>		206/883-4777
>
>    Tecnhically speaking, they both emulate a 3179-G (now 3192-G) vector
>    graphics terminal.  On 3279 S3G terminals, IBM implemented graphics by
>    using Programmed Symbols.  Programmed Symbols effectively mapped the 
>    pixels in a 9x16 or 9x12 character box to match the graphics needs of the 
>    display.  Fortunately for all of us, IBM no longer does PS-style
>    graphics.  
>    
>    The vector graphics commands (orders) are embedded in the 3270 data stream.


For what it's worth, I spoke with OpenConnect Systems at Interop here last
week and they do have a tn3279 under development that emulates an IBM
3279 S3G and therefore supports Programmed Symbols.


Wayne Clark
wclark@cisco.com
415/688-4627

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 10:21:18 GMT
From:      hay@shannon.ee.wits.ac.za (Angus Hay)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: Secondary nameserver won't refresh itself - RESOLVED

In <1991Oct13.150637.26320@ccu.umanitoba.ca> mills@ccu.umanitoba.ca (Gary Mills) writes:

>the refresh interval specified on the SOA record.  I assume that Sun's
>named has some bug that prevents the automatic refreshes.  By the way,
>Sun recently released a patched version of in.named-xfer.  I had previously
>installed this, but it had no effect on the refresh problem.

Is there any way to get hold of the fixed version other than directly
from Sun? Alternatively, where can I get the latest source for BIND.
A mail server site would be great, since we don't have FTP access to
the Internet.

-- 
     *   *  Angus Hay, Dept of Electrical Engineering,   
    **   *  University of the Witwatersrand,                 
   *******  Private Bag 3, WITS, 2050, New South Africa   
  *  *   *  Internet: hay@nyquist.ee.wits.ac.za Tel:(27)(11)716-5423
 *   *   *  NeXTmail: hay@turing.ee.wits.ac.za  Fax:(27)(11)403-1929

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 16:14:25 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: WAVE: A New Executable Protocol for TCP-IP

In article <1991Oct11.155440.556@bigsur.uucp>, jcobban@bcars5.UUCP (Jim Cobban) writes:
>In Article: 9590 of comp.protocols.tcp-ip
>

Reply:

  Yes, what you say is true.  A WAVE protocol with a Wave interpreter at each
node, by itself, facilitates malicious virus distribution.  

  However, if we build in management to the protocol, connecting that management
to existing security features, we can minimize the danger.

  Viruses exist because they are powerful and simple.  To me that translates
into potentially tremendous usefulness to a computer based society.  Lets
formalize them and take advantage of their usefulness.

  Cars kill, airplanes crash, TCP can cause broadcast storms, and Waves 
can be mis-used.  Now lets get on with the job.

               Matt

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 18:01:23 GMT
From:      allebrandi@inland.com (Tom Allebrandi)
To:        comp.protocols.tcp-ip
Subject:   Summary: "Reverse Subnetting"

About a month ago, I posted a question regarding the feasability of
something I called "reverse subnetting." The basic idea was to take a
collection of Class C network numbers, which were specifically chosen
to have certain properties, and group them together to appear as if
they were one big network.

We had specifically chosen 32 Class C network numbers which were 

	a) contiguous;
	b) started with a number whose C byte was a multiple of 32.

The net effect of this is that the NIC has assigned us the upper 19
bits of our IP addresses, we "own" the lower 13 bits.

Our intent was to then use a subnet mask of 255.255.224.0 on all of our
nodes to make them think that all of our network numbers were actually
the same network. In other words, group all of the Class C networks
such that thay appeared to be one Class B subnetwork.

I commented that this did not seem to work on a number of TCP/IP
implementations and asked if it should. The following is a summary of
the responses I received to my posting:

o) A number of people thought that this was a neat idea. Also, we are not
   the first people to have thought of something like this; a couple of
   other people have tried it with the same results.

o) The general consensus was that the idea should work, but probably does
   not in most implementations. A number of people commented that the BSD
   4.2 TCP/IP implementation has class number sensitive code. Since many
   of the TCP/IP implementations currently available are based on the BSD
   4.2 implementation, this explains why it does not work.

   A comment was made that BSD 4.3 derivations will handle the netmask the
   way I was proposing.

o) Some people commented that my idea is a subversion of the intent of
   the subnetting rules. In other words, the rules are intended to make
   smaller networks out of a big one, not a big one out of collection of
   small ones.

o) Others commented that even if it did work, it would likely pose
   problems for IP routing to external networks, and broadcast message
   delivery in the local network.

o) One person did point out that many TCP/IP implementations can be told
   that various networks connect to the local adapter. In other words, we
   could simply declare that all 32 networks happen to be acessable to the
   local adapter with no routing required. We already knew this but were
   trying to avoid it as a solution. (We would have to keep a set of
   tables on every one of a couple hundred machines!)

o) Keith Mitchell, from Spider Systems Ltd. in Edinburgh, Scotland,
   did pass on the following interesting comment:

> What you are trying to do sounds like the subject of some IETF Draft
> documents on the "Cluster" scheme. Basically a Cluster is a group of
> networks joined together to look they are subnets of a much larger
> net. The work was done by a chap in Germany called Michael
> Rokitansky.  Although his particular application was for IP over
> public X.25 networks, I think much of the principles and discussion
> should still be relevant, though he did not have much to say about
> implementations.
> 
> You should be able to pick up the documents concerned on "The PDN
> Cluster Scheme" from the NIC in the "Internet-Drafts:" directory:
>
>  <DRAFT-IETF-PDN-CLUSTERSCHEME-00.TXT>  Internet Cluster Addressing Scheme
>
>  <DRAFT-IETF-PDN-PDNCLUSTER-00.TXT>	Application of the Cluster Addressing
>					Scheme to X.25 Public Data Networks
>					and Worldwide Internet Network
>					Reachability Information Exchange
>
> <DRAFT-IETF-PDN-PDNCLUSTERNETASSIGNM-	Assignment/Reservation of Internet
>   00.TXT>				Network Numbers for the PDN-Cluster


o) Finally, most people suggesting giving up and going to get a Class B
   number instead.


Our solution? I've gone back to the NIC, explained the problem with
what we are trying to do, and have asked to trade in our 32 Class C
numbers for a Class B number.


Thanks to barmar@Think.COM, ddl@burrhus.harvard.edu, graeme@ccu1.aukuni.ac.nz,
mal@terminator.cc.umich.edu, keith@spider.co.uk, rickert@cs.niu.edu, 
fitz@wang.com, jbvb@ftp.com, dotytr@nscultrix2.network.com, tom@wcc.oz.au,
08071TCP@msu.edu, and vaf@Valinor.Stanford.EDU for your responses and
assistance!

--- Tom		Allebrandi@Inland.Com
		Inland Steel Research Labs

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 19:43:09 GMT
From:      rah@sppy00.UUCP (MOORE ROBIN)
To:        comp.protocols.tcp-ip
Subject:   "Default" Route Not Working?


  We have recently added several Sun2 systems to our network 
(they used to be off by themselves, and now they are part of
the Internet-connected community).  For historical reasons I 
won't bore you with, some of these systems run SunOS 4.0.1 
and some run SunOS 3.5.  
  Here's the problem:  On all of these systems, we added an
appropriate default route using the command,
    /usr/etc/route add default <Some_gateway> 5
On the 4.0.1 systems, this worked fine.  On the 3.5 systems,
routing is occuring as needed BUT the systems are accumulating
massive routing tables for lots and lots of Internet networks 
that should have been covered by the "default" entry.
  Is this a bug with the older OS, or are we doing something 
wrong in our configuration?  Is there a workaround?
  Thanks, 
  Robin Hermance-Moore
  rah@rsch.oclc.org
-- 
{ Robin A. Hermance-Moore                     %              OCLC Inc.        }
{ sppy00!rah@cis.ohio-state.edu <== 1st   %%% %%% %% %%%%%   6565 Frantz Road }
{   OR:  rah@rsch.oclc.org      <== 2nd   %   % %    % % %   Dublin, OH 43017 }
{ OCLC => "Services for Libraries"        %   % %    % % %   (614) 764-6215   }

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 20:31:37 GMT
From:      steve@gli.com (Steve Giovannetti x4908)
To:        comp.protocols.tcp-ip
Subject:   IETF Proceedings

Where can one obtain Proceedings to the Internet Engineering Task Force?

Steve Giovannetti
General Logistics International, Inc.
1085 Morris Avenue
Union, NJ 07083

email: steve@gli.com

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 91 23:26:09 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Superfast Ethernet Printers wanted

I am looking for recommendations for superspeed laser printers with
Ethernet physical interfaces.  The printer should support PostScript
and TCP/IP.

Print speeds in the range of 100+ pages/minute are sought.

Vendor replies are extremely welcome.  E-mail or post.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 04:27:43 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS problem RESOLVED????

In <1345@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:

>After talking with a colleague, the problem may well be the "120" TTL in
>the secondary's initial line. This means, I believe, that after 2 minutes,
>the SOA record expires so all the counters within that record are re-set.
>So, your refresh period of "600" or 10 minutes is never reached, it is
>being re-set to 0 every 2 minute interval as dictated by the TTL in your
>SOA record.  YOu might experiment with removing that figure (120) or
>bumping it to something above 600 so that won't happen.

I sent you mail about this, but perhaps you never received it.  The value
of 120 was not a TTL that I specified.  It was the value that the ``host''
command displayed when it queried the nameserver.  I noticed that it did
decrement in value, and just happened to be 120 when I looked at it.

>I'm really confused now.  Why would bind 4.8.3 solve the problem? It appeared
>very clear that your TTL on the SOA line was doing in your refresh period.
>Did you change that line or is 4.8.3 smart and/or forgiving?  

I made no changes to the data files when I installed 4.8.3.  The automatic
refresh simply started working.  
-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 07:43:30 GMT
From:      barrett@daisy.ee.und.ac.za (Alan P Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS problem RESOLVED????

In article <1345@bcstec.boeing.com>,
ced@bcstec.uucp (Charles Derykus) writes:
> I'm really confused now.  Why would bind 4.8.3 solve the problem? It appeared
> very clear that your TTL on the SOA line was doing in your refresh period.
> Did you change that line or is 4.8.3 smart and/or forgiving?  

Primary and secondary nameservers are not supposed to use the TTL values
to age their authoritative data, but resolvers are supposed to use the
TTL values to age their cached non-authoritative data.  RFC1034 section
3.6 says this:

    The meaning of the TTL field is a time limit on how long an RR can
    be kept in a cache.  This limit does not apply to authoritative data
    in zones; it is also timed out, but by the refreshing policies for
    the zone.

Some nameserver implementations incorrectly use the TTLs to age their
authoritative data.  At least some SunOS implementations have this bug,
but bind 4.8.3 does not heve this bug.  So, I think it is quite likely
that the short TLL was causing problems that could be corrected by
switching to bind 4.8.3.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 09:45:44 GMT
From:      als@bohra.cpg.oz.au (Anthony Shipman)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Sun's TIRPC package

kramer@bellhop..bellcore.com (Mike Kramer) writes:

>In article <1991Oct10.071858.12540@bohra.cpg.oz.au> als@bohra.cpg.oz.au (Anthony Shipman) writes:
........................

>I have tried installing Sun's TIRPC package on one of their own SPARCstations,
>and installation was not trivial! First, you have to apply some modifications
>to the SUNOS 4.1.1 kernel, including the inclusion of encryption capabilities.
>These are available as seperate updates from SUN.
 
>After that, you should be able to run the supplied Makefile and 
>have it install itself. Well, there is a bug in the Makefile 
>and it took me two days of work to figure out what the problem is
>and to get it installed. The problem was not actually so severe -
>some files were not copied into the right directory and the 
>cc command failed to find them. I had some e-mail help from someone 
>at SUN for which I am grateful. They stil haven't fixed the bug though! 
 
>I imagine that if installing it on a SPARC was painful, that it 
>will not be a piece of cake to port. But I really have no experience
>on this, so I defer to any other opinions! 



Thanks for the responses.  I've looked at enough of it to see that it will be
more like a piece of concrete than a piece of cake to port.  Even the Makefiles
seem to be non-standard (wrt SysV).

But I must port it to a variety of machines mostly of the SysVR3.2 persuasion
with socket libraries, some with XTI, some with genuine TLI!

Regards

-- 
Anthony Shipman                 "You've got to be taught before it's too late,
Computer Power Group             Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia             You've got to be carefully taught."  R&H

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 13:39:58 GMT
From:      dla@se05.wgep.waii.com (Douglas Acker)
To:        comp.protocols.tcp-ip
Subject:   Re: "Default" Route Not Working?

In article <1425@sppy00.UUCP>, rah@sppy00.UUCP (MOORE ROBIN) writes:
|> 
|>   We have recently added several Sun2 systems to our network 
|> (they used to be off by themselves, and now they are part of
|> the Internet-connected community).  For historical reasons I 
|> won't bore you with, some of these systems run SunOS 4.0.1 
|> and some run SunOS 3.5.  
|>   Here's the problem:  On all of these systems, we added an
|> appropriate default route using the command,
|>     /usr/etc/route add default <Some_gateway> 5
|> On the 4.0.1 systems, this worked fine.  On the 3.5 systems,
|> routing is occuring as needed BUT the systems are accumulating
|> massive routing tables for lots and lots of Internet networks 
|> that should have been covered by the "default" entry.
|>   Is this a bug with the older OS, or are we doing something 
|> wrong in our configuration?  Is there a workaround?
-- 
Are you running the route daemon?  That would work around the
"default" entry.

Be lucky... under 4.1.1, our default route just goes away .....
every now and then.

Douglas L. Acker

Western Geophysical
Exploration Products

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 13:51:54 GMT
From:      kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP disconnection problem

richb@kronos.com (Rich Braun) writes:

>kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) writes:
>>This is in response to a question about whether a client TCP should notify
>>the user when the server has crashed.
>>
>>When the client sends a segment to the server after the server has crashed
>>it will obviously not get a response...
 
>... But, what if the remote has crashed and the local program hasn't
>tried to send anything?  Suppose it wants some form of asynchronous
>notification even when it's idle or doing something other than network
>transmissions?  I don't think TCP/IP protocols have a "keep-alive"
>transmission.  


>-rich

Some TCP implementations do have keep-alives. Their use is discouraged by
RFC 1122 for 3 reasons, because they "1) cause perfectly good connections to  
break during transient Internet failures; (2) consume unnecessary bandwidth  
("if no one is using the connection, who cares if it it still good?"); and
(3) cost money for an Internet path that charges for packets."

I say that RFC1122 discourages them since it states that the application
program MUST be able to turn them off and they must default to off. Also,
the default keep-alive interval MUST be no less than 2 hours.

There is more in RFC 1122 about this if you are interested. I do not want to
restart the arguments about whether keep-alives are good or not, that 
subject has already been beaten to death.

Kurt Matthys
Unisys Corp.

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

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 14:57:02 GMT
From:      albers@tegra.COM (Walter Albers)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   BSD 4.3 tcp-ip/sockets port - mbuf deadlocks


I am porting the 4.3BSD(tahoe?) socket/ethernet code into Alycon's
Regulus, a UNIX (V7) clone.  Our product is an imagesetter controller
and we use a single LANCE chip (Am7990) to accept both TCP/IP and
Ethertalk packets. 

The port has not been too painful, and everything works as long as I
don't exhaust my limited mbuf supply.  My environment limits the OS's
text/data/bss size to 0x60000, of which I can use only 0x8000 (32K) as
mbufs.  By running concurrent rcp tasks I can create a deadlock where
tasks are starving for mbufs.  This no chance to expand beyond the
0x60000 in the product, and therefore no way to expand my mbuf space.

I have reduced the socketbuf value SB_MAX from 64K to 8K, and have
varied the tcp_sendspace/tcp_recvspace values.  I have also added code
to change a free mbuf clusters into mbufs, and code to remake an mbuf
cluster from free mbufs.

There are a number of things I can try.  One is to implement
soreserve() to actually allocate socket buffer space.  Another is to
change sosend() to back-off when it starves for mbufs - freeing what
it has gotten so far.  Yet another idea is to limit the number of
sockets, particularly tcp sockets, which hold on to mbufs until an ack
is received.

I am seeking ideas/advice/solutions using a small mbuf space where my
performance may become horrible, but I will avoid mbuf deadlocks.  Any
and all assistance is appreciated.

Walter R. Albers (508)663-7435 x145
Tegra, Inc.
900 Middlesex Turnpike, Bldg 5
Billerica, MA 01821

albers@tegra.com

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 17:34:46 GMT
From:      chunglin@melasv.UUCP (Chung-Lin Dai MPU)
To:        comp.protocols.tcp-ip
Subject:   Re: Is source code for Comer vol II ftpable?

Hi,
  I read a news posted by you some time back to June about the availability
  of the Comer's TCP-ip source code. I am also interested in getting it.
  I contacted Prentice-Hall about the availability of the source and getting 
  back a "don't know" answer. I am wondering have you had any responses since
  you posted the above news. Thank you!

  Chunglin Dai

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 17:47:43 GMT
From:      bajan@cs.mcgill.ca (Alan Emtage)
To:        comp.protocols.tcp-ip,news.admin
Subject:   Re: How to find the domain name for an institution?

In article <1991Oct10.222004.17032@kronos.com> richb@kronos.com (Rich
Braun) writes:
>
>Aside from "archie", is there a central index for useful information
>like this anywhere, which isn't so humongous as to be useless?  (Archie,
>it seems, became overwhelmed overnight as soon as people discovered it.)

There will be at least two new archies in North America within the next
month. One hopefully will be announced this week and we'll be able to
start sharing the load. Eventually it is expected that the currently
archie server will be used as a testbed but the the new servers will take
most of the production load.

>I fear when I post items like this that I'm just reciting yet another FAQ.
>An archive of FAQ's, sorted by newsgroup, would be tremendously useful.

Actually, we (the archie group) are currently planning to do just such a
thing for the next release of archie which hopefully isn't _too_ far away.
It is possible that this will be integrated with WAIS to implement the
fast searches.

-Alan

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 19:37:56 GMT
From:      sxn@eng.sun.com (Steve Nahm)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Sun's TIRPC package

kramer@bellhop..bellcore.com (Mike Kramer) writes:

>I have tried installing Sun's TIRPC package on one of their own SPARCstations,
>and installation was not trivial! First, you have to apply some modifications
>to the SUNOS 4.1.1 kernel, including the inclusion of encryption capabilities.
>These are available as seperate updates from SUN.

TIRPCSRC was released to give early access to code that is part of
Solaris 2.0.  Since TIRPC is not "native" to SunOS 4.1.x, installation and use
of it on that release was unfortunately messier that we would have liked.
TIRPCSRC was released last April, so it is indeed *real* early access.

By the way, TIRPCSRC was released for SPARC platforms running SunOS 4.1.x
only.

>After that, you should be able to run the supplied Makefile and
>have it install itself. Well, there is a bug in the Makefile
>and it took me two days of work to figure out what the problem is
>and to get it installed. The problem was not actually so severe -
>some files were not copied into the right directory and the
>cc command failed to find them. I had some e-mail help from someone
>at SUN for which I am grateful. They stil haven't fixed the bug though!

Here is the best fix for this problem:  if you've unpacked the TIRPCSRC
release in, say, /usr/joe/tirpcsrc, then issue this command prior to building
the release:

        % cp /usr/include/rpcsvc/*.h /usr/joe/tirpcsrc/rpcsvc

We were planning on making an updated release about now, but that's been
put off for a bit.  I'll see whether I can get this fix put into the
various archives that live around the net.  Fortunately, this is a source
release, and you can fix your own copies of TIRPCSRC yourself.

>I imagine that if installing it on a SPARC was painful, that it
>will not be a piece of cake to port. But I really have no experience
>on this, so I defer to any other opinions!

The main concern for porting TIRPC is whether the target platform
supports TLI, which TIRPC uses.  If it doesn't, you need to provide a
mechanism for translating the TLI calls that TIRPC makes to whatever your
transport interface happens to be (such as sockets).

Steve Nahm
Distributed Computing Technologies
Sun Microsystems
--
Steve Nahm                              sxn@sun.COM or sun!sxn

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 19:47:22 GMT
From:      shih@madrone.eecs.ucdavis.edu (Alan S. Shih)
To:        comp.protocols.tcp-ip
Subject:   Need Help with SLIP connection

Help, 

Does anyone ever try to connect to net via
SLIP on SVR4.386's ?  I downloaded the slip.pkg from
intel ftp site and installed it. I run the following
commands:

slattach -d /dev/tty01s sl 0 2400
slip

(after I log on to the host computer)
The system simply just stopped by saying
ATTACHING <system name> to net via <system name>

Any info is greatly appreciated!

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

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 91 20:41:26 GMT
From:      bagnall@leadsv.UUCP (Brian Bagnall)
To:        comp.protocols.tcp-ip
Subject:   Urgent data stream paths in tcp-ip




        Is it possible and where may I find examples of 
the urgent data path in tcp being used to deliver more than
one byte of out of band data? I have looked at the usual UCB
applications, i.e. rlogin, telnet, and only find one byte of
data being used.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 01:42:42 GMT
From:      lhuynh@Bonnie.ICS.UCI.EDU (Thomas Huynh)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Setting up gateways

Hi,

	I am trying to setup two separate subnets, connected through
	a server (which in this case acts as a gateway).  Graphically,
	it looks like this:


		Net1-----------------Gateway--------------Net2

	Both Net1 and Net2 connects a number of machines using
	thin net ethernet cables.  The problem I am having is,
	do I need two separate ethernet cards for the server
	(gateway) or just one single ethernet card suffices.
	If I need two cards, do I need two IP numbers for both
	machines?   I am having no problem with setting up
	one network.

	One more thing;  all workstations on Net1 and the server
	uses SCO Unix, and all workstations on Net2 uses ISC Unix.
	Thanks for your answer in advance.

--
Thomas Huynh  lhuynh@bonnie.ics.uci.edu
Information and Computer Science
University of California, Irvine

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 01:54:53 GMT
From:      kreed@telesys.cts.com (Kevin W. Reed)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Access to Usenet News / Email via X.25??

In less than a week, a company that I am doing some work for will
have a 56kb X.25 leased line installed connected to ADP Autonet 
dial-up network.

The primary purpose for the X.25 connection was to provide dialup
access to the system from a large number of local access number
located throughout the US, Canada and other International.

Inital tests, show that the connection will work well for
the intended purpose.

The question now is whether same connection, which is supposed to
be both dial-in and dial-out, can be used for access to USENET News
and email?  Kinda like a TCP/IP connection except using X.25.

I would be interested in hearing from other system administrators
of sites that may use an X.25 connection for this type of 
purpose.

As a point of reference, the configuration being used would 
consist of:

	i486/33 System
	ADAX APC-PC X.25 Interface (single port)
	ESIX System V Release 4
	56kb Leased line to ADP (Autonet)

-- 
Kevin W. Reed                                 TELESYS DEVELOPMENT SYSTEMS
kreed@telesys.cts.com                           Box 40866, Mesa, AZ 85274
{nosc,ucsd}!crash!telesys!kreed                           +1 602 649 9099
matchmaker@phoenix.relay.ucm.com    Public *NIX Site & Phoenix Matchmaker

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 06:12:27 GMT
From:      jat@xavax.com (John Tamplin)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell and Sun Os Guru needed

In article <1991Oct8.012453.7818@csu.edu.au> ddownes@csuna.mur.csu.edu.au (Dean Downes) writes:
>I have a question to asks those involved in the use of SUN OS and 
>Novell 3.11 . My question is this :
>
>	we are about to transfer our net os to the Novell 3.11 environment
>	and where wondering about how to get tcp\ip and smtp connections
>	from our pc net to AARnet\Internet.
>
>	I had read that you set up the Novell server with a second ethernet
>	card and configure the Novell server to do routing . Is this something
>	which is provided with Novell ?
>
>	Next is there a mail program that anyone would recomend to give users
>	a seamless mail transfer between the pc to unix world, and of course
>	pc to pc. Be it PD our not . 
>
>	Currently we run the tcp\ip under NCSA Telnet and have no problems,
>	will this package continue to function properly ?
>
>	We also wish to transfer files via ftp and the novell net os
>	from one campus to another (approx. 150 - 300km). Will the Novell
>	software allow us to do this. We have a Cisco router . That is
>	can we log into a Novell file server which is located on another 
>	net, as if it where a local file server ??
>
>	Lastly anyone how has a great deal of information and knowledge
>	to share please e-mail me. I would love to have a chat ...
>
>
>
>Dean Downes 		e-mail : ddownes@csuna.mur.csu.edu.au
>
>Charles Sturt University - Murray
>Australia

Crystal Data Systems is a Novell Platinum reseller, and we do a lot of
Novell/Unix integration, so take these comments as you wish.

Netware 3.11 with TCP/IP will function as an IP router (Netware has always
functioned as an IPX router), so your telnet and smtp traffic will go
across it with no problems.  As for communicating with the Cisco, IP traffic
will get routed if it is set up to support RIP (routing information protocol).
IPX traffic is also supported on some Cisco routers (AGS+ I know for sure).
If you have your routers (on both ends) set up properly, you should be able
to have IP and IPX traffic appear as local to servers running 3.11.  The
catch is that the client software either has to understand RIP, so it knows
how to send to a remote network, or it has to be able to send packets to
"unreachable" destinations to a default gateway.  Novell's Lan Workplace for
DOS (TCP on the PCs) supports this, as does FTP's PC/TCP.

In house we have a configuration like this:
  Network		Description
    90		12 PC's in a training room on an isolated net
    89		Employee's workstations, X terminals, Novell servers,
		Unix machines
    88		Development network, with Unix machines and X terminals

A Netware 3.11 fileserver with dual Ethernet cards bridges the 90 and 89
networks, and a Motorola Delta 8440 bridges the 89 and 88 networks.
Everything works without a hitch, although the Netware IP routing is perhaps
a touch slow, but it is doing a lot more work than a dedicated router.
(The training room PC's run TCP/IP to get to the 88k box for important
stuff like running our real-time football pool stock market :-).

Feel free to ask if you have any more questions.

-- 
John Tamplin					Crystal Data Systems, Inc.
jat@xavax.COM					2104 West Ferry Way
...!uunet!xavax!jat				Huntsville, AL 35801

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 13:43:30 GMT
From:      deaddio@spock.bellcore.com (Michael DeAddio)
To:        comp.protocols.tcp-ip
Subject:   Re: Is source code for Comer vol II ftpable?

I recently came from a tutorial at Interop in CA in which they used
Comer Vol. II as the basis for the class.  When asked about the source
code the instructor (wasn't Comer) said that it was only available from
Prentice Hall and not from any on-line source that he know about.  Sorry
this doesn't help much but it's the latest that I know.


Mike

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 14:38:17 GMT
From:      dxe@cassidy (Dan Ellsweig - Network planning)
To:        comp.protocols.tcp-ip
Subject:   Re: Urgent data stream paths in tcp-ip

In article <18222@leadsv.UUCP> bagnall@leadsv.UUCP (Brian Bagnall) writes:
>
>
>
>        Is it possible and where may I find examples of 
>the urgent data path in tcp being used to deliver more than
>one byte of out of band data? I have looked at the usual UCB
>applications, i.e. rlogin, telnet, and only find one byte of
>data being used.


To obtain more infor on the usage of urgent data and the interpretation
of the standard, get a hold of a copy of Comers book "Internetworking
with TCP/IP Volume 2". Page 286 will contain all of the info you need!!!



-- 
*****************************************************************************
Dan Ellsweig    **   Salomon Technology Services      **  dxe@cassidy.sbi.com
                **   Route 3   East Rutherford, N.J.  **
*****************************************************************************

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 16:27:58 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs X.25 in a close environment

From article <20620005@hpsgm2.sgp.hp.com>, by taybh@hpsgm2.sgp.hp.com (Tay Beng Hang):
> Hi netlander,
> 	
> 	Given two hosts situated in the close environment (location), which
> protocols (TCP vs X.25) is best suited to connect them in terms of 
> performance, reliability, flexibility, maintanence, expandability 
> and availiablity? 

You should get enough information about TCP/IP, so i'll concentrate on X.25:

> 	Below are some my observations:
> 
> 	1) TCP/IP can run on top of LAN already installed, but X.25 requires 
> 	a delicate link. Or X.25 can run on top of LAN (ethernet)?

This is not true. X.25 can be run (in principle) over any 802 LAN using
LLC2 instead of HDLC at the data link layer. This is running for SUN,
DEC (VMS, unsure about Ultrix), CDC Cyber, PC under MSDOS and probably
some other machines i don't know too. There are also some X.25 Switch
(like TCP/IP router) manufacturers supplying X.25 over LLC2, like netcom
or spider. X.25 in its use as the connection oriented network service
is required for european OSI conformance.

> 	2) Both of them are not optimized for connecting hosts in a close
> 	and short distance environment. But which one performs better?
> 	X.25 because of dedicate link? In terms of protocols itself, which
> 	one incurs more overhead? Any experience? No religion debate please.

The performance purely depends on the underlying network architecture.
So far there a very few experiences at large with X.25 at higher speeds
(higher = higher than 10Mbps), but deducing simply from the protocols
one cannot say that X.25 is superior in terms of performance to TCP, nor can
it be said the other way.

Of course, there is optimisation in all protocols. I really don't know, what
you mean with "close and short disctance", i read it as "fast", but that's
something totally different, because WANs can be fast too. See above you do
not need dedicated links to run X.25.

> 	3) Both of them cannot handle failure of physical link. However,
> 	if the X.25 card or LAN card are replicated, which one provides a
> 	better failure-transparency (i.e. less impact on the application when
> 	the link/LAN is down)?

As ever, it depends. I personally know only of living people who can handle
failures of a physical link, and no protocols. As TCP is a transport
layer protocol, whereas X.25 is only a network layer protocol you can hardly
compare them in this respect at all. My experience is, that with current
software, TCP/IP is much more transparent to short term failures, but this
is only because mostly TP0 is used as a transport layer protocol for X.25,
and it does not provide for error recovery.

So much for the information. If you need an advice:

If you are bound to provide an OSI oriented network you'll have to go for
CLNS/X.25 (one of them at least) anyway. If you have no such needs,
and you are a beginner, use TCP/IP at first, because its much more proven
in LAN usage, it is cheaper for most machines, and it provides a much broader
spectrum of applications. When you buy the fitting equipment, you can
use both TCP/IP and X.25 , whereas X.25 is most useful for the
standard applications X.400, FTAM and triple X.
---

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless/
  Workstations gegen V.4, e.V. (Konto 376524 - Kennwort: Brot fuer BSD)

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 19:55:10 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip
Subject:   Re: WD8013EP Packet Driver Question...

gary@sci34hub.sci.com (Gary Heston) writes:

>In article <178@edison.North.DE> diro@edison.phone.North.DE (Dirk Rode) writes:
>>gooey@helix.nih.gov (Sean Graham) writes:
 
>>>	I was wondering if someone can tell me if the current packet
>>>	driver "WD8003E.COM   6535  03-28-91" supports the WD8013EP

I don't think so.  It never worked for me.

>> and when there is someone who knows this, is there also somebody
>>who knows a packet driver for the WD8003EBT Card? I search also the
>>(complete) source for such a packet driver and how to include it in
>>the KA9Q / NOS package.
 
>I'm using the current Clarkson packet driver with 8003EP and EBT boards;
>it should work with the 8013 series as well. If SMC will ever call me
>back, now that they've bought the product line from WD, maybe I'll order
>some and find out.

8003PKDR.EXE can be found in pub/packet.driver/oems/wd on vax.ftp.com and
seems to support all the WD8003 familty cards,  even MCA versions.
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 21:41:01 GMT
From:      bjork@telebit.com (Steve Bjork)
To:        comp.protocols.tcp-ip
Subject:   How to join the Internet



                       Joining the DARPA IP Internet

Overview

  With the availability of easily configured IP routers that can use the
Public Switched Telephone System, the network of IP internets is growing
phenomenally. There are many advantages to IP networks. One of the biggest
advantages is the existance of the Defense Advanced Research Projects Agency
(DARPA) Internet.

  This network is composed of Government networks and Research and Educational
networks, and recently, full commercial networks as well. All these networks
are joined by gateways, allowing the full range of IP services (such as FTP,
Telnet, and applications such as X windows) to be exchanged.

  The availability of sophisticated software such as compilers, X window
system, and numerous other utilities makes access to the DARPA IP Internet
a distinct advantage in today's hi-tech environment. This note will describe
the various items necessary for obtaining a fully supported connection to
the DARPA IP Internet.

Basic Walkthrough

  The following items will be necessary for supporting the internet connection.
It is assumed that the reader has obtained one or more of the references 
listed in the appendix, and will understand the need for the various items
as this note mentions them. In addition, the Network Information Center
(NIC) will be consulted for Network number assignment and domain registration.
The contact information for the NIC is in the appendix.

1. Obtaining an IP network number

  An officially registered Network number must be obtained from the appropriate
party. This number uniquely identifies the IP network. The NIC will assign the
network number based upon the needs of your organization. The various classes
of network numbers are described in the TCP/IP reference listed in the
appendix.

  Once the network address is obtained, you are then able to assign individual
host numbers to entities on your IP network. Each network entity must have
a unique host number. One of the most important addresses that you must
assign is the address of your Domain Name System (DNS) server. You must
have a network number to assign host addresses for your DNS server before
you can complete the Domain Application form from the NIC (see next section).

2. Registering a Domain

  A Domain Name is also registered at the NIC. The domain name uniquely 
identifies your organization in the DARPA Internet community. It is used
in electronic mail addresses, and many other IP services. See the appendix
for a reference volume for the Domain Name System (DNS). The NIC will 
refuse to register a domain unless there are two servers for the domain.
The two servers are a primary and a secondary. Two servers are required
for reliability, and it is strongly recommended that the servers be
physically separated. Most often, an organization will run its own
primary server, and the secondary is off-site. The off-site server
can be arbitrary, and often is simply a "network neighbor." The
commercial IP network providers can also act as DNS servers for
smaller sites.

3. Physical Interconnection Issues

  The physical connection must be supported with an IP router. The router
can use a telephone company (telco) leased line for high speed, or the
regular Public Switched Telephone System for low cost. The router is what
directs network traffic outside your local organization, and into and out
of the DARPA internet. The flexibility of the IP protocols is especially
apparent here, with numerous options available for transport and 
interconnection of various IP network segments. Options include optical
fiber, satellite relay, microwave transmission, or the common telco lines.
Consult the router vendors listed in the appendix for further information.

4. Network Service Providers

There are several entities that can be contacted
for obtaining interconnection to the internet. Military users generally
are attached to the Defense Data Network (DDN). Research and Educational
institutions often connect via the National Science Foundation network
(NSFnet). Recently, full commercial IP networks have been placed into
operation. The commercial networks generally have fewer restrictions
on the traffic they will carry as compared to the Military and Research
networks. The appendix lists contacts for some of these transport agencies.

5. Tying It All Together

Once you have a network address, and have your domain registered, you can 
begin building the network connection. Coordinate with your network sevice
provider for the appropriate access method, for instance a dialup IP link
via SLIP or PPP. The telephone company may need to install circuits if a
high speed leased line is required. Once the leased line (or other access
method) is in place, you can test the LAN access. Consult your vendors
documents for appropriate configuration commands. Once your IP routers
are configured for your network topology, the packets should flow.
Congratulations, you're now a member in good standing of the IP Internet
community.

Appendix

Follows is a short introduction to various IP networking references.


                     Networking Reference Information

==================================================
Books and the Request For Comment (RFC) Collection

  Follows is a list of various books and other reference information for
networking issues, with emphasis on TCP/IP Internets.

___________________________________________
Internetworking With TCP/IP, Second Edition
Douglas Comer
Prentice Hall

You will find this book an excellent reference for most TCP/IP internet
questions. Covers such issues as network classes, domains, and routing.

_______________
The Simple Book
Marshall Rose
Prentice Hall

The Internet Standard Simple Network Management Protocol (SNMP) is given
a thorough treatment by the author. Because of the nature of managing a
network with SNMP, the internet protocols are given a wring out in the text.

_________________________________
Computer Networks, Second Edition
Andrew Tannenbaum
Prentice Hall

A comprehensive overview of various networking implementations including
TCP/IP, DECnet, SNA, x.25, and various transport agents such as ethernet,
token ring, packet radio, and others.

_____________________
DDN Protocol Handbook
SRI International

This four volume set contains sufficient information to code a functional
TCP/IP protocol implementation from. A number of Request For Comments
(RFC's) are listed in the handbook.

____________________
Request For Comments
(various authors)

The Request For Comment (RFC) is the mechanism used by the Internet Community
to define protocol standards. Several sites make the RFC's available for
copying from the network free of charge. Hard copy service is provided by
SRI International.

=========================
Network Service Providers

 This section lists providers of IP network backbone transport facilities.
Agents for Military, Government, Research and Education, and Commercial
users are listed. The Network Information Center (NIC) is listed as well.

________________________________
Network Information Center (NIC)

The Network Information Center provides assignment of IP network addresses,
registers domains, and operates the root name server for the Domain Name
System (DNS).

Government Systems, Inc.
Attn: Network Information Center
14200 Meadow Park Drive
Suite 200
Chantilly, VA 22021
+1-703-802-4535
(800) 365-3642

__________________________________________________
Defense Information Systems Agency (DISA, nee DCA)

Military and Government communications services are provided by DISA,
formerly known as Defense Communications Agency (DCA).

Headquarters
8th and South Courthouse Road
Washington, DC 20390

____________________________________________
National Science Foundation Network (NSFnet)

The NSFnet backbone provides supercomputer access for research and educational
facilities across the planet. In addition, NSFnet provides network access
for government agencies.

National Science Foundation Network
1800 G Street, NW
Washington, DC 20550

+1-202-357-9717

_____________________________
UUNET Communications Services

UUNET offers many services, including Domain MX records and commercial
internet access.

UUNET Communications Services
3110 Farview Park Drive, Suite 570
Falls Church, VA 22042

+1-703-876-5050

______________________________________________________
California Education and Research Foundation (CERFnet)

CERFnet provides commercial IP network access.

California Education and Research Foundation (CERFnet)
10100 John Jay Hopkins Drive
La Jolla, CA 92093

+1-619-534-5056

__________________________________________
Performance Systems International (PSInet)

PSInet provides commercial IP network access.

Performance Systems International
P.O. Box 3850
Reston, VA 22091

+1-703-620-6651

=================
IP Router Vendors

Follows is a listing of some of the Internet Protocol router vendors.

___________________
Telebit Corporation

Provides IP network routers capable of using the regular Public Switched
Telephone System as a transport agent. Also capable of traditional leased
line operation.

Telebit Corporation
1315 Chesapeake Terrace
Sunnyvale, CA 94089

+1-408-734-4333

___________________________
Cisco Systems, Incorporated

Provides IP internet routers utilizing a variety of transport agents.

Cisco Systems, Incorporated
1525 O'Brien Drive
Menlo Park, CA 94025

+1-415-326-1941

______________________________
Wellfleet Communications, Inc.

Provides IP internet routers utilizing a variety of transport agents.

Wellfleet Communications, Inc.
12 DeAngelo Drive
Bedford, MA 01730-2204

+1-617-275-2400

_____________
Proteon, Inc.

Provides IP internet routers utilizing a variety of transport agents.

Proteon, Inc.
Two Technology Drive
Westborough, MA 01581

+1-508-898-2800

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 22:00:41 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP disconnection problem

kurt@s5000.rsvl.unisys.com (Kurt Matthys x5693) writes:
>Some TCP implementations do have keep-alives. Their use is discouraged by
>RFC 1122 for 3 reasons, because they "1) cause perfectly good connections to  
>break during transient Internet failures; (2) consume unnecessary bandwidth  
>("if no one is using the connection, who cares if it it still good?"); and
>(3) cost money for an Internet path that charges for packets."
>...
>the default keep-alive interval MUST be no less than 2 hours.

I failed to state in my original comments on this topic:  one would only
want to use keep-alive packets for applications which need to provide some
sort of failure recovery or operator intervention in the event of
network downtime.  Usually this means a real-time application operating
on a LAN, where the "unnecessary bandwidth" and "cost money" criteria
are not at issue.  TCP/IP is one of those things which tries to be all
things to all people, and error recovery is one of those things which it
tries to do itself.  It doesn't leave the application much room for
creating its own error-handling conditions.

But, of course, it's quite possible as some have suggested to layer a
keep-alive transmission on top of the standard TCP or UDP protocols.
So by adding overhead, one can get around the problem.  (Unfortunately,
adding overhead is often undesirable in a dedicated real-time application.)

For those who argue TCP/IP isn't intended for real-time applications, let
me remind you that VxWorks is a commercially viable real-time O/S which
incorporates TCP/IP as one of its fundamental building blocks.

-rich

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 22:02:00 GMT
From:      barr@frog.UUCP (Chris Barr)
To:        comp.protocols.tcp-ip
Subject:   How to get rid of BSD gethostbyname() false error messages?

I get bogus error messages from gethostbyname() when it tries to
access a non-existent nameserver (setup by res_init()).  It then
successfully looks up the name in the local hosts file.

I'd like, for complicated reasons, to not run named locally or
rely on one remotely, but allow this optionally - any ideas about
how to do this and still not get bogus messages are appreciated.
/etc/resolv.conf looked promising -

I've tried putting in fake but 'valid' IP addresses in /etc/resolv.conf,
including local host's IP address, and thought that would satisfy 
res_init(), but no... I get:

  write error
  : Connection refused

or, if the address's net portion is invalid:

  write error
  : Network unreachable

I'd just like to get rid of the messages.

Thanks in advance,
Chris Barr

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 91 22:07:56 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: Setting up gateways

lhuynh@Bonnie.ICS.UCI.EDU (Thomas Huynh) writes:
>	I am trying to setup two separate subnets
>
>		Net1-----------------Gateway--------------Net2
>
>	The problem I am having is,
>	do I need two separate ethernet cards for the server
>	(gateway) or just one single ethernet card suffices.
>	If I need two cards, do I need two IP numbers for both
>	machines?

If you don't want all packets on Net1 to reach all systems on Net2, the
answer is you need two interface cards in the gateway.  And you need to
run routing software in the gateway; each card will have its own IP
address with a unique network or subnet number, if I understand correctly.

So hosts on Net1 might be numbered 192.50.50.xxx, and hosts on Net2 might
be numbered 192.50.51.xxx.  You could use 192.50.50.1 and 192.50.51.1 for
the gateway's two Ethernet cards.  If the network has any significant
size to it, you should request official numbers from NIC.DDN.MIL so you
won't have major headaches if and when your site is connected to "the" Net.

-rich

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 91 02:28:39 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: subnets with different masks

peter@ski.austin.ibm.com (Peter Jeffe 512.838.4019) writes:

> There is a site that wants to use class B addresses with subnets, and
> use different subnet masks for the different subnets.  Specifically,
> a machine has two interfaces, as follows:
>
>                  en0                     en1
>     address    832f0407 (131.47.4.7)   832ffe01 (131.47.254.1)
>     mask       fffffc00                ffffff80
>     subnet     832f0400                832ffe00

I was hoping someone knowledgeable would respond to this, but since no one
did, I'll give you an ignorant response instead.  I suspect it won't work.
While it's clear what addresses belong to the directly-connected subnets,
it's not at all clear how packets for distant subnets should be routed.
Consider a packet destined for 131.47.11.129.  There might be a subnet
131.47.8.0 with a netmask fffffc00 like the one on en0, or there might be a
subnet 131.47.11.128 with netmask ffffff80 like the one on en1.  So which
subnet should be looked up in the routing table?  You can't know.

Only TCP/IP implementations that take a subnet mask on the "route add"
command line can deal with this.  I don't know of any that do.  Without
subnet masks in the routing table (and a policy for resolving overlapping
subnets), the code has to figure out _THE_ subnet mask for all the subnets
in the network, and there can only be one such subnet mask.  Current code (as
far as I can tell) picks one interface attached to the subnet, and uses its
subnet mask for all routing calculations.

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

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 91 05:03:37 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on Karn/Jacobson algorithms

In comp.protocols.tcp-ip, perreaul@interlan.Interlan.COM (Jason Perreault) writes:

   >I'm looking for online documentation/source describing Karn's
   >algorithm for Round-Trip Time Estimation [ACM SIGCOMM '87] and
   >Jacobson's algorithm for Congestion Avoidance and Control [ACM
   >SIGCOMM '88].

   Inside the book "Unix Network Programming" by R.Steven chapter 8.4
   contains the source code for the above algorithms. The source code
   appeared in this book can be obtained on-line from uunet.uu.net.

   Hope this helps.

 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgnlc.sgp.hp.com  |
| Singapore 0410                      |            taybh@hpsgm2.sgp.hp.com   |
| Republic of Singapore		      | HPDesk:    HP3200/67                 |
 ----------------------------------------------------------------------------
    

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 91 14:11:15 GMT
From:      jchen@manticore.NoSubdomain.NoDomain (Jason Chen)
To:        comp.protocols.tcp-ip
Subject:   IP Security (RFC 1108)

RFC 1122 refers to RFC 1108 for ip security issues. But I could not find
that RFC at a number of archive sites. Is 1108 obsoleted? If it is, by which
one?

Any clue is appreciated.

-- 
C. Jason Chen
jchen@ctt.bellcore.com

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 91 14:49:04 GMT
From:      kvrao@bgsuvax.UUCP (Dr K. V. Rao)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.shell
Subject:   help with program to automate ftp

I am looking for a shell that automate the following sequence every day
at a set time -
ftp to a site with a fixed userid and pw
upload a specified file from a directory 
then quit ftp
edit the file to delete the text and save the file with one line.

Repeat the process next day and every day at a given time.

Thanks for your help in this regard. Please forward your replies to
kvrao@andy.bgsu.edu and I'll post the shell if there is sufficient
interest.

K. V. Rao 

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 00:24:18 GMT
From:      schwartz@latour.cs.colorado.edu (Michael Schwartz)
To:        comp.protocols.tcp-ip
Subject:   ITU standards available online

As announced recently at Interop, the International Telecommunication
Union standards documents (including the CCITT Blue Book) are now available
online.  You can get them by anonymous FTP from bruno.cs.colorado.edu (soon
to be renamed digital.resource.org) in pub/standards.  There is a HELP file
in this directory that explains what you need to know.  You can also access
these documents by sending mail to infosrv@bruno.cs.colorado.edu, with the
message body (not subject line) containing commands to a mail server.  Use
the command
	help
to get started.  Alternatively,
	send HELP
will send a more detailed description.

These documents will soon be available at a number of other sites as
well.

Please be aware that the standards on this server are being offered on
an experimental, volunteer basis.  They are currently in a preliminary
state of typesetting conversion.  Please bear with us concerning
imperfections.  The standards are being offered free of charge and we
expressly waive all guarantees and warranties.  If you want a guaranteed
version of the standards, you MUST refer to the printed versions
available for purchase from the International Telecommunication Union.

Sincerely,
	Carl Malamud
	Michael Schwartz

        The Digital Resource Institute and the Department of Computer
        Science, University of Colorado, Boulder

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 04:28:21 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: How to join the Internet

You might also want to list the other midlevel networks, since most, if not all,
of them provide Internet connectivity to the research community. Some of them
also provide purely commercial connectivity. In addition, the research Internet
is broadly enough defined that it includes many for-profit organizations,
including most of the major hardware and software vendors.

Here are a few of the regional networks not listed by the original posting:

    BARRNet (northern California)
    CICNet (midwest U.S.)
    JVNCNet (New Jersey & environs)
    Los Nettos (southern California)
    MERIT (Michigan)
    MIDNET (midwest U.S.)
    MRNET (Minnisota)
    NEARNet (New England)
    NorthWestNet (Pacific northwest U.S.)
    OARNet (Ohio)
    PREPNet (Pennsylvania)
    PSCNet (western Pennsylvania)
    Sesquinet (Texas)
    SURANet (southeast U.S.)
    THENet (Texas)
    VERNet (Virginia)
    Westnet (U.S. mountain region)

The Internet Resource Guide and the folks who run the NSFNet (MERIT) can no
doubt provide a more complete list.

	Vince Fuller, BARRNet technical director

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 07:25:59 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   SunOS 4.1.1 MGET panic with SLIP

Is there a known problem with SLIP running against SunOS 4.1.1 on a Sun
4/490? I have had no problem running the identical slip code on an SS1+
and IPC running 4.1.1. However when I try the 490 after a while I get
an MGET panic in:

      FP       PC             SYM+ OFF  ARGS
f8136aa0 f80510e0          _panic+  6c  f81517b7 f8165400 1 1 1b 16e
f8136b00 f80be830      _slip_btom+  50  ff655000 ff291adc f8171bd0 11000ae2 124 f8136b64
f8136b68 f80be5f4      _slip_rput+  398  40 c0 ff2256b8 ff2a2325 40 f8171bd0
f8136bd0 f80f8494     _mcpa_drain+  118  f81789e8 f8178a3d ff2256b8 110a 0 0
f8136c30 f80f8338    _mcpa_rxchar+  1c8  f81789e8 0 fffffffe 3ff 180 0
f8136c90 f80f55e0        _mcpintr+  130  ff022400 1 1100 c00 9 f8177548

One difference is of course that the 490 is using an ALM2 line, while
the SS1+ and IPC use a zs port.

There was a known SunOS 4.1 bug (and patch) for an MGET Slip panic, but
that supposedly was fixed in 4.1.1, so this must be something else.

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

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 09:51:27 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: subnets with different masks

fitz@wang.com (Tom Fitzgerald) writes:

>I was hoping someone knowledgeable would respond to this, but since no one
>did, I'll give you an ignorant response instead.  I suspect it won't work.
>While it's clear what addresses belong to the directly-connected subnets,
>it's not at all clear how packets for distant subnets should be routed.
>Consider a packet destined for 131.47.11.129.  There might be a subnet
>131.47.8.0 with a netmask fffffc00 like the one on en0, or there might be a
>subnet 131.47.11.128 with netmask ffffff80 like the one on en1.  So which
>subnet should be looked up in the routing table?  You can't know.

So it behoves the administrator to avoid any ambiguities, which could mean
unuseable 'holes' in address allocations.

>Only TCP/IP implementations that take a subnet mask on the "route add"
>command line can deal with this.  I don't know of any that do.  Without

AIX 3.1 on RS6000's associates the interface netmask with the route. 

>subnet masks in the routing table (and a policy for resolving overlapping
>subnets), the code has to figure out _THE_ subnet mask for all the subnets
>in the network, and there can only be one such subnet mask.  Current code (as
>far as I can tell) picks one interface attached to the subnet, and uses its
>subnet mask for all routing calculations.

Why only one?  RFC1219 describes a variable-subnet method for maximal address
allocations.  Saying that 'you can only have *one* subnet mask throughout your
network' is rather like saying 'your class B net *must* have the same mask
as all the other class B networks', isn't it?

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 11:58:44 GMT
From:      koelman@issun3.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Router in ISDN?

Hello,

Does anyone know of a router with an ISDN Basic and/or
Primary rate interface?

Please let me know.

Ton Koelman
STC, The Hague

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 12:24:29 GMT
From:      pfenning@techfak.uni-bielefeld.de (Joerg-Thomas Pfenning)
To:        comp.protocols.tcp-ip
Subject:   proxyarpd for SunOS 4.1.1

I need to install a proxyarpd on a Sparcstation running SunOS 4.1.1.
The versions I found 1.5 and 1.12 don't work for me. 
Has anybody fixed this?

I recall there was an announcement regarding this topic but I can't remember
the details.

Thanks for any help.
-- 
Thomas Pfenning, University of Bielefeld, Technical Computer Science
E-Mail:     pfenning@techfak.uni-bielefeld.de
Phone:      +49 521 106 2918
Fax:        +49 521 106 6328
Snail-Mail: Universitaetsstr., W 4800 Bielefeld 1, Germany

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 14:11:08 GMT
From:      berg@physik.tu-muenchen.de (Stephen R. van den Berg)
To:        comp.protocols.tcp-ip
Subject:   UDP, portable maximum packet size.

I was wondering, what is a generally supported maximum packet size on UDP?

512 bytes?  (surely)
536 bytes?
maybe 1024 bytes?
or even higher?

I am trying to define some UPD-communications protocol, and have to know
what a practical maximum packet size is (which still can be transmitted all
over the world).
--
Sincerely,                                berg@messua.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"-- Listen carefully, I shall say this only once --"

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 14:55:12 GMT
From:      mleech@bnr.ca (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   FTP as a collection of library routines

I have a student here who has some spare time ;-)  He wants to do a MOTIF
  FTP client implementation.  Has anyone built an FTP API library that
  could be used?


-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 17:23:57 GMT
From:      venu@cirrus.com (Venu Nayar)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

In <1991Oct18.141108.21940@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:

>I was wondering, what is a generally supported maximum packet size on UDP?

	What UDP does is to take the data that comes from the application
layer (which may be of any length) and encapsulate it in the header. Hence a
UDP packet can be of any length. IP then gets the UDP packet and fragments it
based on the MRU value. The MRU value is the maximum packet size which can be
transported on the underlying medium. 
	Hence the size of a packet which goes out is depends on your network
protocol - ethernet, token rng or whatever.
-- 
Venu Nayar			|		Internet: venu@cirrus.com
Cirrus Logic Inc.		|		UUCP:	oliveb!cirrus!venu
Work: (415)-226-2100 X3737	|
Home: (408)-942-0181		|

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 18:49:28 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: ITU standards available online

In article <1991Oct18.002418.27567@colorado.edu> schwartz@latour.cs.colorado.edu (Michael Schwartz) writes:
>As announced recently at Interop, the International Telecommunication
>Union standards documents (including the CCITT Blue Book) are now available
>online. 
>The standards are being offered free of charge and we
>expressly waive all guarantees and warranties.  If you want a guaranteed
>version of the standards, you MUST refer to the printed versions
>available for purchase from the International Telecommunication Union.
>
>Sincerely,
>	Carl Malamud
>	Michael Schwartz
>
    Hopefully the printed versions will be forced to reduce their 
    rip-off pricing levels a bit by this long overdue competition.

    Too bad there isn't an Internet Achievement award for which you
    guys would be a certain lock.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 19:53:56 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Security (RFC 1108)

In article <1991Oct17.141115.3690@walter.bellcore.com>
   jchen@manticore.NoSubdomain.NoDomain (Jason Chen) writes:
>RFC 1122 refers to RFC 1108 for ip security issues. But I could not find
>that RFC at a number of archive sites. Is 1108 obsoleted? If it is, by which
>one?
 
>C. Jason Chen
>jchen@ctt.bellcore.com

First, please talk to your local postmaster to get your "From"-address
fixed. "...NoDomain" is not a valid FQDN.

Secondly: RFC-1108 has never been issued and probably never will be.
My (highly unofficial) perception is that the DoD IP security option
has melted down into a mess where different programs use different
options. For this reason a "comemrcial" security option is now being
defined by the TSIG (Trusted Systems Interoperability Group).

If you have a need to implement security options for DoD you need to
ask the program sponsor for technical guidance relevant to the specific
program.

If you need generic security for non-government applications, get in
touch with TSIG (Steve Crocker <crocker@TIS.COM> is a good starting
point).
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 20:25:38 GMT
From:      sthaug@eros.delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: proxyarpd for SunOS 4.1.1

> I need to install a proxyarpd on a Sparcstation running SunOS 4.1.1.
> The versions I found 1.5 and 1.12 don't work for me. 
> Has anybody fixed this?

I am running proxyarpd version 1.7 on an IPC with 4.1.1, and it works like
a charm. I have made the 1.7 version available for anonymous FTP from
aun.uninett.no (129.241.1.99):

	pub/proxyarpd-1.7.shar.Z

Btw, where did you find the 1.12 version?

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 91 20:43:24 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   KA9Q and WD Elite16s

I wish to use KA9Q with a new Western Digital Elite 16 ethernet card.  I know
people locally using KA9Q with older 8003 and 8013 cards but I haven't found a
packet driver for the new cards.

Can someone point me in the right direction?

(Thanks in advance)

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

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 91 16:30:16 GMT
From:      allyn@netcom.COM (Mark Allyn)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   printer server questions

Thanks for all of your responses to my questions with the multi protocol
print server questions!

As it turns out, we will probably use the NCSA telenet for the PC's and
have them queue to a single unix box with a high performance HP laser
printer.

Mark Allyn

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 91 20:54:56 GMT
From:      berger@sfc.sony.com (Bob Berger)
To:        comp.realtime,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   FDDI as a realtime network?

Has anyone considered or used FDDI as a network for hard real-time?

With the price of FDDI boards beginning to approach Ethernet, FDDI is
becoming afordable. My question is, does FDDI (especialy with network
protocols such as TCP/IP) have low enough latency and high enough
determinicity to act as a network for distributed real time
applications?

Our application requires a that we can get small messages (< 100bytes)
out from at least several devices every few (<4) milliseconds. Plus
some low priority bulky messages in the backround which are not time
critical.

From a quick look, FDDI does look promising. Its token ring mechanism
and support for priorities allows for the possiblity of deterministic
response. The raw speed of the transport makes it look like low
latency is possible as well. It seems clear that there would be no
problem if we used FDDI from the MAC layer down. The question is can
we use a full TCP/IP (probably UDP actualy) and still maintain
determinicity and low latency?


-- 
Bob Berger  -  SONY Advanced Video Technology Center
677 River Oaks Parkway  San Jose, CA 95134 408-944-4964 FAX:  408-954-1027  
INTERNET: berger@sfc.sony.com   UUCP: [uunet,mips]!sonyusa!sfcsun!berger

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 91 23:57:17 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.realtime
Subject:   Re: FDDI as a realtime network?

In article <1991Oct19.205456.28916@sfc.sony.com>, berger@sfc.sony.com (Bob Berger) writes:
> Has anyone considered or used FDDI as a network for hard real-time?
> 
> With the price of FDDI boards beginning to approach Ethernet, FDDI is
> becoming afordable. My question is, does FDDI (especialy with network
> protocols such as TCP/IP) have low enough latency and high enough
> determinicity to act as a network for distributed real time
> applications?

Who is selling FDDI boards for $150?  The end-user FDDI board prices I know
about are 10 to 200 times higher.  And that doesn't count the $1000-$3000
concentrator port or optical bypass required by the "high availability"
sometimes associated with "hard realtime".  Even the new "low cost" UTP
concentrators seem to be priced at >= $1000/port.

What is the price of the SONY FDDI product?

> Our application requires a that we can get small messages (< 100bytes)
> out from at least several devices every few (<4) milliseconds. Plus
> some low priority bulky messages in the backround which are not time
> critical.

Depending on the background load and number of devices, 4msec is not a big
deal for ethernet.

> From a quick look, FDDI does look promising. Its token ring mechanism
> and support for priorities allows for the possiblity of deterministic
> response. The raw speed of the transport makes it look like low
> latency is possible as well. It seems clear that there would be no
> problem if we used FDDI from the MAC layer down. The question is can
> we use a full TCP/IP (probably UDP actualy) and still maintain
> determinicity and low latency?
> 
> Bob Berger  -  SONY Advanced Video Technology Center

FDDI async. priorities are no more or less useful than TCP/IP TOS.  They
are not widely implemented or used.  There is nothing in the protocol to
encourage or even inform a station with 200KB of low priority async traffic
that some other station has some high priority async traffic.  Sync.
bandwidth allocation is on its way to being standardized, but most
implementations are not paying attention to it.  (Who else besides the SONY
video demo is using sync?)  Restricted tokens seem to be universally
deprecated.

I think FDDI is less deterministic than ethernet.  Yes, you don't have
"ethernet collapse".  Instead, when you exceed the fiber's bandwidth you
have either practically infinite token rotation times or little service.
When the ring is saturated, you can transmit no more often than once per
N*TRT, where TRT>4msec and N=number of transmitting stations.  In addition,
you have the "ring recovery process" and other MAC and SMT stuff with
no ethernet equivalent but which can take a long time.  For example,
correctly operating rings can and do stick in CLAIM for ~4 milliseconds.

A bunch of lightly loaded ethernets seems as likely to statisfy "hard
realtime" needs.

Disclaimer:
  My employer sells FDDI boards for its workstations which in my
  biased option achieve respectible performance.  I doubt my bosses or at
  least my colleagues in marketing or sales would be overjoyed to hear me
  saying something as cheap as ethernet might do something as well or
  better than FDDI.


Vernon Scrhyver,   vjs@sgi.com

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 91 07:28:14 GMT
From:      cs@Eng.Sun.COM (Carl Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Security (RFC 1108)

| ...
| For this reason a "comemrcial" [sic] security option is now being
| defined by the TSIG (Trusted Systems Interoperability Group).
| ...
|
| If you need generic security for non-government applications, get in
| touch with TSIG (Steve Crocker <crocker@TIS.COM| is a good starting
| point).

	For details on CIPSO, contact Ron Sharp (rls@neptune.att.com), the
TSIG CIPSO working group chair.

			Carl

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 91 08:03:55 GMT
From:      spetter@ultra.com (Scott Spetter)
To:        comp.lang.asm370,comp.unix.aix,comp.protocols.ibm,comp.protocols.tcp-ip,comp.lang.rexx,comp.protocols.misc,comp.os.misc
Subject:   I need to "rsh/rexec" from MVS to Unix (SunOS)


For those groups whose charters do not precisely match my request, 
please accept my apologies.

I am working on a series of MVS tools which will require me to
send and execute commands on a Sun system.  We have IBM TCP/IP
Version 2 running on our MVS host, which includes (but does not
document) a program called REXEC, which appears to function
similar to a UNIX "rsh", but the thing just doesn't work, and
IBM does not support the MVS implementation (there is also a
VM version of REXEC with the same format.)

If anyone has code - be it object, source, or whatever that I
could use to issue my remote commands - mostly rcs operations
since we do all our source control (MVS, VM, and UNIX) using
UNIX, from MVS, I would be extremely grateful.  Short of that,
if you know of others who have done similar work, and could
point me towards them, that too would be most helpful.

Thank you very much for your assistance - and please do feel
free to call or email (or post), whatever you deem appropriate.

Sincerely,

Scott J. Spetter





-- 
Scott J. Spetter - IBM Release Engineer

*****  UltraNetwork Technologies  ** Home of the Gigabit/Second Network  ***** 
       101 Daggett Drive, San Jose, CA 95134    (408) 922-0100 X-143

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 91 20:07:05 GMT
From:      berger@sfc.sony.com (Bob Berger)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.realtime
Subject:   Re: FDDI as a realtime network?

Oh good, this is the kind of feedback I was hoping to get. I am not
speaking from much real experience yet, we are still novices with
FDDI, that is why I am asking these questions and appreciate this kind
of responses from people who have had more experience and knowledge of
the FDDI standards.

In article <of36u08@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon
Schryver) writes:

>Who is selling FDDI boards for $150?  The end-user FDDI board prices I know
>about are 10 to 200 times higher.  And that doesn't count the $1000-$3000
>concentrator port or optical bypass required by the "high availability"
>sometimes associated with "hard realtime".  Even the new "low cost" UTP
>concentrators seem to be priced at >= $1000/port.
>

Well, I said the price was approaching ethernet, what's an order of
magnitude amoung friends :-). Seriously, there were $2500 single ended
optical FDDI cards for the SBus. This implies that the prices will be
low enough for our needs and is dropping faster than we expected. I
beleive that by the time products that are starting to be designed now
are released, FDDI node cost will be under $1k.

>What is the price of the SONY FDDI product?
>
I don't know.


>I think FDDI is less deterministic than ethernet.  Yes, you don't have
>"ethernet collapse".  Instead, when you exceed the fiber's bandwidth you
>have either practically infinite token rotation times or little service.
>When the ring is saturated, you can transmit no more often than once per
>N*TRT, where TRT>4msec and N=number of transmitting stations.  In addition,
>you have the "ring recovery process" and other MAC and SMT stuff with
>no ethernet equivalent but which can take a long time.  For example,
>correctly operating rings can and do stick in CLAIM for ~4 milliseconds.
>
>A bunch of lightly loaded ethernets seems as likely to statisfy "hard
>realtime" needs.
>

Our calculations show that our application would generate many events
that are somewhat syncronous and thus increasing the potential for
collisions on an ethernet thus making it non-deterministic.
We expect not to be near the saturation point of the FDDI ring.

So, are you implying that if we use TCP/UDP/IP we will not really be
able to access the syncronous or other special features of FDDI? (This
is not a challange, its an honest question) Are there ways to set
network policy so that large CLAIMs are not allowed?

Again, our applications will be in control of all nodes on the net, it
is not being used as a normal workstation style network, but dedicated
to specific applications.

-- 
Bob Berger  -  SONY Advanced Video Technology Center
677 River Oaks Parkway  San Jose, CA 95134 408-944-4964 FAX:  408-954-1027  
INTERNET: berger@sfc.sony.com   UUCP: [uunet,mips]!sonyusa!sfcsun!berger

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 91 20:45:39 GMT
From:      blarson@blars.UUCP
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.sys.prime
Subject:   Re: SUMMARY: Van Jacobsen's "Fat Pipe" Modifications

In article <28122@adm.brl.mil> Michael Panosh - Unix Support@BRL.MIL, writes:
>PS: Bob Larson (blarson@sis.usc.edu), you were way our in your comments
>    on the 50 Series software.  Xelink is a fine product and we sell it
>    depending on customer requirements.  But in this instance the 515>    Series is not the bottle neck, the network is!!

If you belive the 50 series is not a bottleneck, I recomend you read
"What's new with Primos TCP/IP?" by Goeorge Khater (a Prime employee
then -- was he layed off?), handed out at his talk at the 1990 NPUG.
Total FTP throuput tops out at 52 kbytes/second on an unloaded
ethernet, and the maximum throuput of the LHC300 controler is
documented there at 60 kbytes/second.  Some of your other systems get
twice t
" (in your own tests) on your (overloaded?) ethernet.  The 50
series LHC300 board with TCP/IP done on board definiatly is a throuput
problem.  (The LHC300 has a 80286 that does the TCP/IP protocol in
Primes normal TCP/IP package, but not in their alternate package named
Xelink.)  Before you start calling your customers liars in public I
recomend you check your facts.

-- 
blarson@abode.ttank.com		blarson@usc.edu
		C news and rn for os9/68S!

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 02:10:47 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip
Subject:   Re: Assigning one IP address into 2 ethernet addresses

In article <20620004@hpsgm2.sgp.hp.com> taybh@hpsgm2.sgp.hp.com (Tay Beng Hang) writes:
                [I've annotated the picture slightly]
}           X
} --------------------------------------------
}   |X.1                        |X.2
 ---                        -----
}  |A|---Z.1            W.1--|  B  |
 ---                        -----
}   |Y.1    Y                   |Y.2
} ----------------------------------------------
} Is it possible to assign one IP address into two different ethernet
} addresses (two ethernet card) for host A and B?  The purpose of doing
} this is to provide reliablity thru redundancy.  When one ethernet fails,
} the host A and B will automatically switch to another ethernet without
} the TCP application notice it because of there are 2 route paths.

I've looked at this problem before, though never actually built one.
The solutions we came up with depend on the routing capability of your systems,
and what your systems DO if they have two ethernet boards on them,
but basically look like this:
	- Give the Ethernets different network numbers, X and Y
	- Create some kind of unique additional network on each box, Z and W
		such as a SLIP line or just a loopback.
		Presumably these should be subnets, to avoid name-wasteage.
	- Turn on routing on each machine, so machine A lets everything know
		it can reach network Z, and B says it can reach W
	- Use the Z.1 and W.1 addresses for the destinations instead of X.A, X.B
Alternatively, if everything's good at subnetting, split network X up into
	many little size-4 subnets, using a subnet mask 255.255.255.252
	- Let Host A be X.01, B be X.05, C be X.09, etc.
	- configure routing so that the primary route for subnet X.*
		uses the X ethernet, and the secondary route uses the Y,
		(which may not have to be split into little subnets.)
	- Use X.* addresses to reach the machines
The latter approach sounds preferable, if it works.
Also, if you want to get fancy about load-balancing, split Y up into the same
subnets, and have half the applications programs talk to X.A and half to Y.A
-- 
				Pray for peace;      
					Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# No, that's covered by the Drug Exception to the 4th Amendment

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 04:20:54 GMT
From:      tim@sabus.UUCP (Tim Brown)
To:        comp.protocols.tcp-ip
Subject:   TCP via Radio.


I have heard that someone has implemented tcp-ip over radio.  I am
looking for any information I can get my hands on concerning this type
of tcp implementation.  Email responce is preferred, I can summarize
if there is alot of interest.

Thanks
Tim Brown
tim%sabus@uunet.uu.net
-- 
Tim Brown
The SABUS Group
2091 Cliffside Dr.		Anchorage, Alaska 99501
(907)277-4232			tim%sabus@uunet.uu.net

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 05:06:40 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

In comp.protocols.tcp-ip, venu@cirrus.com (Venu Nayar) writes:

    In <1991Oct18.141108.21940@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:

>>I was wondering, what is a generally supported maximum packet size on UDP?
 
>What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it

	Theoretically, the maximum size of an UDP packet is 64K, this is 
	derived from the length field in UDP packet which is 16 bit only. 
	If the application has data longer than 64K, it is the responsibility 
	of the application to fragment the data into several UDP packet and 
	transmit them one by one. UDP protocol does NOT fragment the data 
	at all.  Note that the actual size of data that can be transmitted 
	in one UDP packet depends very much on the implementation 
	(buffer size between application process and the protocol). For 
	example, in most BSD socket implementations of UDP, 8k is the 
	most portable size that an application can send in one UDP pakcet. 
	I guess this is the reason why 8K was taken as the NFS packet size.

>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium. 
>Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.

	This is true.

 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgm2.sgp.hp.com   |
| Singapore 0410                      |            taybh@hpsgnlc.sgp.hp.com  |
| Republic of Singapore		      | HPDesk:    HP3200/67                 |
 ----------------------------------------------------------------------------
    

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 06:32:18 GMT
From:      andrewf@syacus.acus.oz.au (Andrew Friedman)
To:        comp.protocols.tcp-ip
Subject:   ITU standards guaranteed (Was: ITU standards available online)

schwartz@latour.cs.colorado.edu (Michael Schwartz) writes:

>As announced recently at Interop, the International Telecommunication
>Union standards documents (including the CCITT Blue Book) are now available
>online...
>...
>The standards are being offered free of charge and we
>expressly waive all guarantees and warranties.  If you want a guaranteed
>version of the standards, you MUST refer to the printed versions
>available for purchase from the International Telecommunication Union.

Ah, so the printed versions of standards are guaranteed.  So the next
time a broken CCITT standard causes your organisation to lose mucho
dollars, you sue the ITU. 

Come to think of it I never did see a disclaimer on any CCITT standard. 
You know the sort, "...no warranty, either express or implied is offered
to the fitness or suitability of this standard for any purpose."

>Sincerely,
>	Carl Malamud
>	Michael Schwartz

Please excuse my mischief.  I assume you meant to say you can
not guarantee the online versions are the same as the printed versions. 
Nevertheless, thank you for your good work in making the standards
available on line. 

Regards,

Andrew

P.S.  I don't think you could sue the ITU anyway since its an organ of
the United Nations.  I presume citizens of member nations of the U.N. 
are precluded from sueing it. 
-- 
                  |  Tel: +61 2 390 1338  | Internet: andrewf@syacus.acus.oz.au
 Andrew Friedman  |  Fax: +61 2 390 1391  |   ACSnet: andrewf@syacus.acus.oz

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 07:28:16 GMT
From:      sandeep@dowland.ee.uts.EDU.AU (Sandeep Chandra)
To:        comp.protocols.tcp-ip
Subject:   NETBLT source code anyone ?

Hi netters,

I am looking for the latest version of NETBLT (NETwork BLock Transfer)
transport protocol source code which can be supported on the SUN systems.

I understand this protocol described in RFC 998 (Clark, Lambert, Zhang) has
been implemented for an IBM PC/AT but I am keen on getting similar code
for the SUNOs environment (SUNOs 4.1.1 on a SunSPARC II). 

Any pointers will be greatly appreciated. Also any comments about the 
choice of this on an Ethernet LAN from those who have used it will be valuable.

Ta,

PS : Email directly on the address below will be great !

Sandeep Chandra		sandeep@ee.uts.edu.au
Multimedia Group 	^^^^^^^^^^^^^^^^^^^^^
University of Technology
Broadway
SYDNEY 2007 

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 09:18:47 GMT
From:      root@netdev.comsys.COM (Superuser)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SCO Unix - SunOs slow xfer prob.


 We just set up an IPC ( Sun 4.1.1 ) connected to a 486 PC running SCO unix
3.2.2. Performance of the LAN is no where close to useful. NFS times out,
and FTP throughput is at 1 to 15 KB/sec. 

 As a test, we placed an 8Mhz 286 on the LAN with the Clarkson drivers and
KA9Q on top. Performance between it and each of the Unix systems was better
than that between the Sun and SCO boxes. 

 We've checked addressing, ifconfig, all the known possible gotchas here, and
we are out of gas. 


 If you have seen such a problem ( and came across the solution ), your comments
are most welcome.

 -Alex

-- 

alex@netdev.comsys.com			Communication Systems Research
{cs.utexas.edu}!texsun!netdev!alex      Dallas, Texas 75252

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 12:49:29 GMT
From:      galina@watson.ibm.com_ (Galina Kofman)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP as a collection of library routines

In  <1991Oct18.145512.207@bwdls61.bnr.ca>  mleech@bnr.ca (Marcus Leech) writes:
> I have a student here who has some spare time ;-)  He wants to do a MOTIF
>   FTP client implementation.  Has anyone built an FTP API library that
>   could be used?
>
>
> --
> Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
> mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
> ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

TCPIP for OS/2 from IBM offers FTP API library.

Galina Kofman.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 14:12:04 GMT
From:      nerd@percival.rain.com (Michael Galassi)
To:        comp.protocols.tcp-ip
Subject:   Re: subnets with different masks

graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) writes:

>Why only one?  RFC1219 describes a variable-subnet method for maximal address
>allocations.

Its one thing for the RFCs to describe a technique, its another for the
masses to be able to use it.  The current revisions of RIP don't propagate
a netmask or even the number of network bits with the routes so we stick
with the same netmask within a given network.  Surely other routing protocols
allow this, maybe HELLO, or creative use of static/default routes but those
of us with large SLIP based networks are painfully aware of the limitations
of RIP.  (I'd love to be proven wrong)

>Saying that 'you can only have *one* subnet mask throughout your
>network' is rather like saying 'your class B net *must* have the same mask
>as all the other class B networks', isn't it?

Huh, how do you come up with this?  When I route to a 'B' network other
than the one(s) I attach to directly no netmask is used or needed, I
assume some gateway machine to that network will know how to deal with
the address I select.
-- 
I won't take a stand on perl vs emacs	| Michael Galassi
'til I see /vmunix.pl or /vmunix.elc.	| nerd@percival.rain.com

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 14:33:07 GMT
From:      SNODFK@vm.sas.com
To:        comp.unix.aix,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: Looking for MVS rexec and rsh


Scott -

I've written a version of both rexec and rsh in C for IBM TCP/IP for MVS
(works for both v1 and v2).  I would be happy to send you the source and help
files if you're interested.

Diana Fox
snodfk@mvs.sas.com
(919)677-8000, x7684
SAS Institute, Inc., Cary, NC

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 15:25:38 GMT
From:      ws04medi@hpuircz.italy.HP.COM (Saverio Saggese)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP via Radio.


>I have heard that someone has implemented tcp-ip over radio.  I am
>looking for any information I can get my hands on concerning this type
>of tcp implementation.  Email responce is preferred, I can summarize
>if there is alot of interest.

PLS ask to any Radioamateur you know : we are using tcp-ip protocol to
exchange bullettins and files but the explanation is too extensive 
here !
If youy have trouble contact American Radio Realy League -ARRL- !

73 de iw2eyn   Saverio

 ----------------------------+------------+------------------------------------
 Saverio Saggese             |            |        INTERNET ADDRESSES :        
 Hewlett Packard Italiana SpA|  MEDICAL   |------------------------------------
 Via. G. Di Vittorio 9       |  _ ___ ___ |     76106.1764@compuserve.com      
 20063 Cernusco s/N  (MI)    | /_\ _  | | |      ws04medi@hpuircc.hp.com       
 Italy                       |/   \ _ |_| | Saverio_Saggese@hp8200.desk.hp.com 
 voice ..39-2-92199593       |            |                                    
 ----------------------------+------------+------------------------------------

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 16:21:19 GMT
From:      danson@lion.udel.edu (Doug Anson)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: SCO Unix - SunOs slow xfer prob.

In article <1991Oct21.091847.2357@netdev.comsys.com>, root@netdev.comsys.COM (Superuser) writes:
|> 
|>  We just set up an IPC ( Sun 4.1.1 ) connected to a 486 PC running SCO unix
|> 3.2.2. Performance of the LAN is no where close to useful. NFS times out,
|> and FTP throughput is at 1 to 15 KB/sec. 
|> 
|>  As a test, we placed an 8Mhz 286 on the LAN with the Clarkson drivers and
|> KA9Q on top. Performance between it and each of the Unix systems was better
|> than that between the Sun and SCO boxes. 
|> 
|>  We've checked addressing, ifconfig, all the known possible gotchas here, and
|> we are out of gas. 
|> 
|> 
|>  If you have seen such a problem ( and came across the solution ), your comments
|> are most welcome.
|> 
|>  -Alex
|> 
|> -- 
|> 
|> alex@netdev.comsys.com			Communication Systems Research
|> {cs.utexas.edu}!texsun!netdev!alex      Dallas, Texas 75252

I have a similar problem.  I run UHC SVR4 running on an 386/33 with 8megs
ram and no ethernet card.  When I do a `ping -s localhost` on the machine
a 64 bit packet takes 10ms to make the route.  On an IPC, it takes 0-1ms.  To
me 10ms seems a little long for the loopback mechanism.

Are there any tunables to fix this?
cheers!
doug anson
danson@udel.edu
Univ of Del.
ASEL
  

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 17:17:38 GMT
From:      berg@physik.tu-muenchen.de (Stephen R. van den Berg)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

Venu Nayar writes:
>Stephen R. van den Berg writes:
 
>>I was wondering, what is a generally supported maximum packet size on UDP?
 
>	What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium. 
>	Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.

Let me rephrase the question then, given these split up packets, does
portability (and reliability) somehow suffer beyond a certain critical UDP
packet size?  (i.e. does it matter in how many physical packets one UDP
packet is splitted?)

Someone suggested that 8KB UDP packets can be transmitted across most of
the Internet without problems;  seems like a bit optimistic to me, or is it?
--
Sincerely,                                berg@messua.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

Real programmers don't just die, they produce core dumps.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 17:41:31 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Security (RFC 1108)

In article <1991Oct17.141115.3690@walter.bellcore.com> jchen@manticore.NoSubdomain.NoDomain (Jason Chen) writes:
>RFC 1122 refers to RFC 1108 for ip security issues. But I could not find
>that RFC at a number of archive sites. Is 1108 obsoleted? If it is, by which
>one?

A while back RFC number 1108 was reserved for a "soon-to-be-released" IPSO
document.  When RFC1122 was written, RFC1108 was expected to happen.  Now
it appears that there is some question whether RFC1108 will ever happen.

Art

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 18:38:40 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

>>	What UDP does is to take the data that comes from the application
>>layer (which may be of any length) and encapsulate it in the header. Hence a
>>UDP packet can be of any length.

I don't think this answer is correct, but as usual, it depends a lot
on the implementation.  I think you'll find most UDP implementations
do indeed have an upper limit on the size of data that a user process
can send as a UDP datagram.  Remember that what goes out of UDP has to
go through IP, and there may also be an IP limit.  I think the only
absolute guarantee is that IP must handle a 576-byte IP datagram.  I
also think that this 576-byte guarantee is why you sometimes see some
applications never exceeding around 512-bytes of user data in a UDP
datagram (e.g., the DNS and TFTP).

Most current BSD-derived systems initialize the limit when the socket
is created--look at udp_sendspace and udp_recvspace in netinet/udp_usrreq.c
in any of the BSD sources.  Most systems initialize these to just over
8k bytes.  As I recall, 4.3BSD Tahoe set these to 2k bytes, but I think
they're back at 8k with Reno.  You can also change these after the socket
is created with setsockopt() and either SO_SNDBUF or SO_RCVBUF.  I know
that there are systems out there with smaller limits.

	Rich Stevens  (rstevens@noao.edu)

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 18:54:39 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>>I was wondering, what is a generally supported maximum packet size on UDP?

venu@cirrus.com (Venu Nayar) writes:
>	What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value.

But, if you want the answer for an Ethernet-based LAN, between two
systems on the same physical medium, and you don't want fragmentation
to happen, remember that the maximum-sized Ethernet packet is 1536 bytes.
A UDP header is 8 bytes, an IP header is 20 bytes, an Ethernet header
is 18 bytes, and the trailing checksum is 2 bytes.  My calculation
therefore yields 1488 bytes for data in a non-fragmented UDP packet.

Am I off by a few bytes?

-rich

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 20:10:25 GMT
From:      pxv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.protocols.tcp-ip
Subject:   Can we use tn3270 protocol to do  a file transfer ?

I guess the subject says most of it, except that I have the source code
for tn3270 and am trying to figure-out how can I use it do a file
transfer between my unix machine and the IBM mainframe.

I did look at a thing called tnrecv but am not quite sure if that will
beuseful..

any ideas ?

thanks !

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 20:36:01 GMT
From:      nisc@phoebus.nisc.sri.com (SRI NISC)
To:        comp.protocols.tcp-ip
Subject:   Internet Domain survey

Network Information Systems Center                             October 1991
SRI International                                    Internet Domain Survey


             ZONE (Zealot Of Name Edification) Survey Results

                
                Hosts:                  617,000  [minimum]
                Domains:                18,000   [approximately]


                  Number of IP Addresses per Host
                Addresses               Hosts
                    1                   606187
                    2                   8057
                    3                   988
                    4                   529
                    5                   261


                 Top 36 Most Popular Top-Level Domains
            215488 edu         9395 no             300 mx
            161801 com         8202 jp             292 gr
             41123 gov         8044 net            251 hk
             26475 au          7945 uk             244 br
             25781 de          2802 at             208 is
             22091 ca          1771 il             138 sg
             21805 mil         1729 dk             102 us
             17393 org         1442 es              94 su
             13807 se          1385 kr              74 pl
             12514 fr          1318 nz              28 cs
             11513 ch           915 it              25 tn
             10546 nl           401 ie              14 hu
             10395 fi           374 be               8 ph


                       Top 50 Most Popular Host Names
 338 venus       214 mac1        185 eagle      168 titan      151 hal
 313 pluto       214 mac2        184 cisco      161 mac5       151 uranus
 300 mars        213 neptune     179 merlin     159 apollo     150 athena
 255 jupiter     206 cs          178 mac3       159 pc3        150 phoenix 
 248 saturn      204 newton      178 opus       157 io         149 alpha
 245 zeus        199 pc2         173 calvin     155 grumpy     148 earth 
 241 pc1         196 gw          172 thor       155 mac10      147 mac7   
 238 mercury     195 gauss       169 mac4       155 mozart     146 snoopy
 229 iris        190 hobbes      168 fred       154 mac6       142 sleepy
 227 orion       185 sirius      168 hermes     152 charon     142 sol

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 23:00:47 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs X.25 in a close environment

In article <20620005@hpsgm2.sgp.hp.com> taybh@hpsgm2.sgp.hp.com (Tay Beng Hang) writes:
]  Given two hosts situated in the close environment (location), which
]protocols (TCP vs X.25) is best suited to connect them in terms of 
]performance, reliability, flexibility, maintanence, expandability 
]and availiablity?  [...]

I'm assuming your environment is physically close enough together
that a LAN will work, and your applicaitons aren't already written.
Then go with TCP/IP.  If you need to go to a wide-area network,
you can always run TCP/IP over top of X.25 if X.25 is available.
X.25 is made to operate over a SINGLE network; TCP/IP is made to
operate over an internet of connected networks, which is more flexible.
Also, the applications you want are more likely to already exist for
TCP/IP than for x.25, and the programming environment is more flexible.

]  1) TCP/IP can run on top of LAN already installed, but X.25 requires 
]  a delicate link. Or X.25 can run on top of LAN (ethernet)?

X.25 normally also requires a switch, either on your location or
at a phone company or other network provider.

]  2) Both of them are not optimized for connecting hosts in a close
]  and short distance environment. But which one performs better?
]  X.25 because of dedicate link? In terms of protocols itself, which
]  one incurs more overhead? Any experience? No religion debate please.

TCP/IP over Ethernet normally requires less work for a given amount
of data transfer, and Ethernet runs at 10 Mbps instead of the 64 kbps
speed typical for X.25.  Some people have made X.25 go as fast as
1.5 Mbps, but it's a lot of work.

]  3) Both of them cannot handle failure of physical link. However,
]  if the X.25 card or LAN card are replicated, which one provides a
]  better failure-transparency (i.e. less impact on the application when
]  the link/LAN is down)?

X.25 depends on connections.  If a connection breaks, the layers
above get notified.  If the only protocol stack you're using is X.25,
this affects your application; if you have transport and session layers,
your application may not be bothered by it.  X.25 does provide
reliability within the connection, but that's low-level only.
TCP uses IP, which is connectionless - each packet gets routed separately,
so if a packet can't go through one connection, it can try another.
Because error recovery is done by the TCP layer, the connection can
switch physical paths without the application ever knowing, as long
as the timeout values aren't exceeded.
As far as physical connectivity goes, if you have an X.25 switch,
that's one more item to fail - but everything probably has to go
through the same switch.  With TCP/IP, you can have multiple connections
in parallel, and have it do the right thing.

Also, for some reason X.25 cards for PCs typically cost >$1000,
while Ethernet cards typically cost <$400.  Some of this is just
economies-of-scale, but I'd guess that the X.25 cards have more
parts, and are therefore more likely to fail?
-- 
				Pray for peace;      
					Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# No, that's covered by the Drug Exception to the 4th Amendment

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 91 23:14:28 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip
Subject:   X.25 <-> TCP Gateways (Was: Re: X25 access via TCP)

In article <561@ctsx.celtech.COM> dms@celtech.COM (Dave Stanhope) writes:
]Sorry to go into so much detail but people keep
]trying to sell me routers or telnet to pad translators, neither of

Unlike Dave, I *am* trying to find something that sounds a lot like
a "telnet-to-pad translator".  I'd like to be able to provide a
reasonable interface to a public X.25 network so that people who
connect through dial-up or dedicated pads with X.3/X.28/X.29 can
connect to a TCP/IP network for telnet and maybe SMTP.

The crude way is to provide a computer with X.25 login capability and telnet,
but this means deassembling and reassembling packets of characters,
and moving them between kernel and user a lot, possibly even one
character at a time?
It would be nice to have something that negotiated all the
PAD and telnet options with some reasonable sort of translation,
and ideally used a streams or similar approach to shuffle most
packets between the x.25 and telnet stacks in the kernel,
or alternatively to have the capability built into a router.

Does anybody make something like that?  Thanks!
-- 
				Pray for peace;      
					Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# No, that's covered by the Drug Exception to the 4th Amendment

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 00:35:31 GMT
From:      mrs@charlie.secs.csun.edu (Mike Stump)
To:        comp.protocols.tcp-ip
Subject:   NSFnet not working?

Gee, doesn't the below indicate some sort of problem?  :-( ^5
It seems to be causing my nameds to fits.

traceroute nic.ddn.mil
traceroute to nic.ddn.mil (192.112.36.5), 30 hops max, 38 byte packets
...
 6  nss.sdsc.edu (132.249.16.10)  140 ms  140 ms  120 ms
 7  129.140.6.14 (129.140.6.14)  140 ms 129.140.6.78 (129.140.6.78)  160 ms 129.140.6.14 (129.140.6.14)  160 ms
 8  129.140.75.6 (129.140.75.6)  180 ms  180 ms  200 ms
 9  129.140.11.14 (129.140.11.14)  180 ms 129.140.11.78 (129.140.11.78)  240 ms
 1120 ms
10  129.140.73.11 (129.140.73.11)  300 ms *  420 ms
11  129.140.9.74 (129.140.9.74)  340 ms  480 ms  1100 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * 129.140.73.11 (129.140.73.11)  840 ms
17  129.140.75.9 (129.140.75.9)  640 ms  1100 ms  800 ms
18  * 129.140.73.11 (129.140.73.11)  1020 ms  1820 ms
19  129.140.75.9 (129.140.75.9)  1020 ms  880 ms  940 ms
20  129.140.73.11 (129.140.73.11)  960 ms  1000 ms  1080 ms
21  129.140.75.9 (129.140.75.9)  860 ms  1080 ms  1180 ms
22  129.140.73.11 (129.140.73.11)  1060 ms  1100 ms  1240 ms
23  129.140.75.9 (129.140.75.9)  1440 ms * *


Non-authoritative answer:
11.73.140.129.in-addr.arpa      host name = College_Park.MD.NSS.NSF.NET

Non-authoritative answer:
9.75.140.129.in-addr.arpa       host name = Houston.TX.NSS.NSF.NET
-- 
If I can get mail to you via a legally registered fully qualified
domain name, you could be on Saturn for all I care.

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

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 01:06:48 GMT
From:      hayes@blaise.trl.OZ.AU (Mark Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: ITU standards guaranteed (Was: ITU standards available online)

andrewf@syacus.acus.oz.au (Andrew Friedman) writes:

>schwartz@latour.cs.colorado.edu (Michael Schwartz) writes:
 
>>As announced recently at Interop, the International Telecommunication
>>Union standards documents (including the CCITT Blue Book) are now available
>>online...
>>...
>>The standards are being offered free of charge and we
>>expressly waive all guarantees and warranties.  If you want a guaranteed
>>version of the standards, you MUST refer to the printed versions
>>available for purchase from the International Telecommunication Union.
 
>Ah, so the printed versions of standards are guaranteed.  So the next
>time a broken CCITT standard causes your organisation to lose mucho
>dollars, you sue the ITU. 
 
>Come to think of it I never did see a disclaimer on any CCITT standard. 
>You know the sort, "...no warranty, either express or implied is offered
>to the fitness or suitability of this standard for any purpose."

Ah, but the CCITT does not publish standards, they publish
*Recommendations* :-)

Cheers,
mdh
-----------------------------------------------------------------
Mark Hayes					Research Labs,
m.hayes@trl.oz.au				Telecom Australia

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 01:47:34 GMT
From:      tgriffith01@cc.curtin.edu.au
To:        comp.protocols.tcp-ip
Subject:   Re: WAVE: A message for Matt Young

In article <18192@leadsv.UUCP>, netnews@leadsv.UUCP (Leads Network News) writes:
> In article <1991Oct11.155440.556@bigsur.uucp>, jcobban@bcars5.UUCP (Jim Cobban) writes:
>>In Article: 9590 of comp.protocols.tcp-ip
>>
> 
> Reply:
> 
>   Yes, what you say is true.  A WAVE protocol with a Wave interpreter at each
> node, by itself, facilitates malicious virus distribution.  
> 
>   However, if we build in management to the protocol, connecting that management
> to existing security features, we can minimize the danger.
> 
>   Viruses exist because they are powerful and simple.  To me that translates
> into potentially tremendous usefulness to a computer based society.  Lets
> formalize them and take advantage of their usefulness.
> 
>   Cars kill, airplanes crash, TCP can cause broadcast storms, and Waves 
> can be mis-used.  Now lets get on with the job.
> 
>                Matt
Matt,

I've been trying your Reply-to: address of young@force.decnet.lockheed.com but
keep on getting a bounced message in reply.  Do you have an alternate
address?

>>> RCPT To:<young>
<<< 550-YOUNG; %MAIL-E-NOSUCHUSR, no such user YOUNG at node FORCE
<<< 550
550 <young@force.decnet.lockheed.com>... User unknown

--------------------+--------------------------------------------------------
Don Griffiths       | JANET    munnari!cc.curtin.edu.au!Griffiths_DN@uk.ac.ukc
Information Systems | UUCP     uunet!munnari!cc.curtin.edu.au!Griffiths_DN     
Curtin University   | Bitnet   Griffiths_DN%cc.curtin.edu.au@cunyvm.bitnet
GPO Box U1987       | PSImail  psi%050529452300030::Griffiths_DN
PERTH, 6000         | Internet Griffiths_DN@cc.curtin.edu.au
Western Australia   | 
--------------------+----------------------------------------------------------
Telex : AA-92983 CURTIN    Fax : +61-9-351-3076    Telephone : +61-9-351-7691
-------------------------------------------------------------------------------

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 02:27:27 GMT
From:      jalonso@sobeco.com (j.alonso)
To:        comp.protocols.tcp-ip
Subject:   boot rom for wd8013??

I'd like to know if anyone has any info on a boot rom for a wd8013
ethernet card.  I know there are some roms available which allow a pc
to become "diskless" units and boot right from the wd8013 card on to
a PC-LAN (NOVELL).  What I'm looking for is something that will do the same
but allow a tcp/ip connection.
Please respond direct if possible.  Thank you
joe@spectr     uunet!spectr!joe

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 11:34:53 GMT
From:      kev@sol.acs.unt.edu (Mullet Kevin Wright)
To:        alt.sys.sun,info.sun-managers,info.sun-nets,comp.protocols.snmp,comp.info.snmp,comp.protocols.tcp-ip
Subject:   Running Sun Net Manager on a non-Sun.


Are there any brave souls out there who are running Sun Net Manager
on a non-Sun workstation?  Is there a reason why this shouldn't be done?
Any and all experiences and opinions welcome.

Please mail to me.  I'll summarize and repost to the net.

-Kevin Mullet
 University of North Texas Computing Center

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 14:32:58 GMT
From:      stacy@sobeco.com (Stacy L. Millions)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q and WD Elite16s

In <7897@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:

>I wish to use KA9Q with a new Western Digital Elite 16 ethernet card.  I know
>people locally using KA9Q with older 8003 and 8013 cards but I haven't found a
>packet driver for the new cards.

I just recently (last week) installed KA9Q on a PC using both an 'elite'
and an 'elite 16'. Both cards worked fine with the 8003 packet driver
that was provided with KA9Q, it even recognized the 'elite 16' as a
16bit card.

-stacy

-- 
"He'll live."                                                 stacy@sobeco.com
    - Arnold Schwarzenegger _Terminator 2_                     stacy@sobeco.ca
                                                            uunet!sobeco!stacy

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 15:19:39 GMT
From:      johna@mobdig.ncal.mobdig.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   GSI and the NIC

To all Netland Net Gurus who might have an answer for this.

I expect the new GSI NIC to be slow, but as of late, it appears to have
dropped off the net.  All attempts at contact whether they're electronic
or voice fail. 

Does anyone have any inside info as to what's going on at the NIC and
when we might have a (small) hope of internet service?
-- 
John Antypas/Software Engineer
MobleDigital Corp.
johna@mobdig.com			(Modern way)
...!{rtech, uupsi, soft21}!mobdig!johna {People into tried and true}

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 17:17:25 GMT
From:      exudjr@exu.ericsson.se (David Richard)
To:        comp.protocols.tcp-ip
Subject:   fault-tolerant communication architecture

I am posting this for a coworker.  Do not respond to me.
Please respond to this person directly.

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

This question is concerning the Internet Protocol (IP)
maintenance capability to support a fault tolerant communication
architecture. We are currently investigating the support of two subnetworks
to interconnet mutiple hosts (e.g. a host is connected to two subnetworks).
Our main goal is to maintain reliable transport connections between
applications distributed over mutiple hosts though one of the subnetwork
may become deffictive. 
 
The question is whether the IP supports a total
loop back test capability if not, do you have any suggestions ?

Francis Dinha

Ericsson Network Systems, MS L03  | Phone: 214-997-6595
P.O. Box 833875                   | Internet: exufdi@exu.ericsson.se
Richardson, TX 75083-3875         | 
--
Ericsson Network Systems, MS L03  | Phone: 214-997-0923
P.O. Box 833875                   | Internet: exudjr@exu.ericsson.se
Richardson, TX 75083-3875         | Who's Joe Frank?

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 17:19:48 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q and WD Elite16s

> I wrote:
> 
> I wish to use KA9Q with a new Western Digital Elite 16 ethernet card.  I know
> people locally using KA9Q with older 8003 and 8013 cards but I haven't found
> a
> packet driver for the new cards.
> 
> Can someone point me in the right direction?

Several people have informed me that 8003PKDR.EXE works just fine.  Thanks
everyone.

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

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 17:50:15 GMT
From:      shih@fir.eecs.ucdavis.edu (Alan S. Shih)
To:        comp.protocols.tcp-ip
Subject:   How to auto-connect slip?

Hello netlanders got a situation that I don't know
where to start:

I am using slip to connect to school, however, I have a very noisy 
line connection so once very often the connection will be dead.
How slip detect there is a loss of connection? and how do I use it
to start re-connection process?I often time need the system to be
connected even if noone on the console.


Any info is greatly appreciated!!!


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

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 18:13:57 GMT
From:      ea08+@andrew.cmu.edu (Eric A. Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet not working?

Basically, the nic.ddn.mil host has been having serious problems for a
while now.  The various regional networks are working on resolving the
problem.
          -Eric the vaguely competent
*********************************************************
"After processing 379,220 news postings, we find that 
 349,492 words were used."
           -The Mad Hatter
"You are very smart, shut up."
           -In "The Princess Bride"
*********************************************************

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 19:42:12 GMT
From:      michaels@ember.cisco.com (Robert Michaels)
To:        comp.protocols.tcp-ip
Subject:   Where is the NIC?


I know that this may not be the appropriate list for this question but I'm
not sure where else to ask. I wanted to report a problem to the NIC that
we have been having with reverse domain name requests. So I sent mail to
hostmaster@nic.ddn.mil. Only now I see there eventhough there is an address
for such a host there doesn't appear to be a machine there to receive mail?

What gives? Who is running the network these days? Does this mailing list
even work anymore? 

Any help would be most appreciated. Please mail response directly to me.

Thanks,
Robert Michaels

michaels@xkl.com

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 20:07:48 GMT
From:      brien@topcat.b11.ingr.com (Brien Gilliam)
To:        comp.protocols.tcp-ip
Subject:   Looking for BOOTP source

Does anyone know where I can get public domain source for 'bootpd'?

Thanks...


-- 
 ----------------------------------------------------------------------------
| Brien C. Gilliam                       |    brien@topcat.b11.ingr.COM      |
| System Software Integration            |-----------------------------------|
| Intergraph Corporation                 |    Prayer, the last refuge of a   |
| Huntsville, AL 35894                   |    scoundrel.                     |
| (205)730-5652                          |                  - Lisa Simpson   |
 ----------------------------------------------------------------------------

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 20:13:16 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet not working?

Can someone with more knowledge of what's happened here shed some
light on this whole affair.  I recall seeing a posting by the NSF
in May concerning "DCA funding for Internet registration will
soon end.  That coupled with the expiration of NFS's grant to
BBN for the NNSC ...".  They were talking about network information
services for the interim-NREN.  Is that in any way related to the
switch of the NIC from SRI to GSI?  Does anyone know just who GSI
really is?  I assume they underbid SRI for this contract from DCA?
Someone asked weeks ago, after the first posting from SRI about
the changeover, for someone from GSI to stand up and introduce
themselves, but GSI seems like an unknown still.  Thanks.

	Rich Stevens  (rstevens@noao.edu)

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 20:28:00 GMT
From:      martillo@clearpoint.com (Martillo)
To:        comp.protocols.tcp-ip
Subject:   InterOp Debate


At InterOp, there was a debate over routing issues.  Radia Pearlman,
Milo Medin, Dave Clarke and others took part.

Pearlman was advocating the use of IS-IS routing in place of OSPF even
though IS-IS does not guarantee the "best" possible route because she
claimed it really did not make a difference if now and then a packet
took a less than optimal route.

If "best" is evaluated in terms of cost, such an assertion is really not
valid, and many people would care if a significant fraction of packets
were taking higher cost (i.e.  less than optimal routes).  Of course,
the PTTs would not mind such non-optimal routing as it increases their
profit. 

Dave Clarke and his opponent were debating the desirability of common
routing for IP and OSI packets.  Dave Clarkes observations on complexity
and true goals in general were eminently reasonable.  But in some cases
the use of different routing logic and routing suites for IP and OSI
packets seems absolutely necessary because OSI allows the construction
of protocol stacks where every protocol layer is connection oriented and
where higher protocol layers depend on the reliability of lower protocol
layers. 

OSI packets involved in such protocol stacks might require entirely
different routing procedures from IP packets, so that common routing of
IP packets and such OSI packets would seem inappropriate. 

Also I have to wonder whether OSI packets at corresponding protocol
layers always carry the same sorts of information useful to routing as
would be carried by comparable DOD Internet packets.  I could make a
good case that in some internets large IP packets which contain UDP
messages may optimally follow different routes than small IP packets
which contain TCP messages.  If in some cases routing different subsets
of IP packets differently makes sense, then forcing the common routing
of IP and OSI packets in general may be even quite unreasonable. 

In a sense, we can accept complexity and even try to make use of it
through the reasonable partitioning of the routing problem or we can
quixotically try to obliterate complexity and develop "uncomplex"
systems (like OSI) in which the routing problem has not be partitioned
and which will probably achieve rather uniformly mediocre yet uncomplex
performance. 

Joachim Carlo Santos Martillo Ajami


-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 22:34:41 GMT
From:      huston@process.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP over ISDN

In article <1991Oct1.145216.13897@dvnspc1.Dev.Unisys.COM>, ja@dvnspc1.Dev.Unisys.COM (Jak Amado) writes:
> I am investigating uses of TCP-IP over ISDN. Regarding this subject, I am
> looking for information on any:
>    - RFC
>    - implementation
>    - study
>    - standard
>    - draft standard
>    - work under way
>    - justification, market analysis
>    - ideas, thoughts, bits of thoughts
>    - etc.
> 

Send mail to isdn-subscribe@list.prime.com - it's the isdn@list.prime.com
list for discussing ISDN, including running IP over it in various forms.

Steve Huston                    Process Software Corporation
huston@process.com		+1 508 879 6994

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 91 22:36:35 GMT
From:      tim@introl.uucp (Tim Chase)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   What's a "directed broadcast"?


Could somebody tell me what a "directed broadcast" is?  I recently set up
a SLIP link between a Sparc 1+ with 4.1 and another system.  The only problem
was that as soon as in.routed was started, a bizzarre storm of data started
flowing between the two systems intil I turned off the "ip_dirbroadcast"
flag.  Once that was turned off, all seemed fine.  Am I missing something
by turning it off?  Any idea why this storm was happening in the first place.

I suspect this might be a FAQ so any pointers by email would be much
appreciated.

					- Tim Chase
					  tim@introl.com


-- 
Tim Chase		           Introl Corp. Milwaukee, WI USA
UUCP: spool.mu.edu!introl!tim	Internet: tim@introl.introl.com
   or tim@introl.uucp		   Phone: +1 (414) 327-7171

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 02:19:50 GMT
From:      mpd@anomaly.sbs.com (Michael P. Deignan)
To:        ne.nearnet.tech,comp.protocols.tcp-ip
Subject:   Re: NIC move.

dyer@spdcc.COM (Steve Dyer) writes:

>Can we assume it was that SRI was underbid?  If so, it surely shows.

I could underbid SRI too, and put the NIC on a Commodore 64. Does that
mean I should be awarded the contract?

Clearly, someone didn't properly define the requirements here.

MD
-- 
--  Michael P. Deignan                 / Sex is hereditary. If your 
--  Domain: mpd@anomaly.sbs.com         /  parents never had it, chances 
--    UUCP: ...!uunet!rayssd!anomaly!mpd /   are you won't either...
-- Telebit: +1 401 455 0347               /

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 04:07:08 GMT
From:      keith@sequoia.UUCP (Keith Pyle)
To:        comp.protocols.tcp-ip
Subject:   Help Request: More than One Packet Driver

I am attempting to set up a PC using the Clarkson packet drivers and
need assistance with some problems I have encountered.  My goal is to:

(1) run an SNMP package called ExpressView (from David Systems, makers
of 10BaseT concentrators) under Windows, and

(2) run a telnet/ftp client, ftp server package such as the one from
Clarkson or WinQVT simultaneously under Windows.

These packages use a packet driver to access the ethernet card.
ExpressView claims to require that the packet driver loaded for it use
software interrupt 0x69.  I have it running successfully now and, in my
tests, I found that it could not access the network unless interrupt
0x69 was used.  ExpressView does use a special Windows driver that it
provides.  I suspect that this may be the reason for the specific
interrupt.

I have also successfully run the telnet packages mentioned from Windows
without ExpressView running.  Both of these packages seem (relatively)
insensitive to the software interrupt used.

When I first attempted to use both packages at once, I found that one
instance of the packet driver at interrupt 0x69 was not sufficient.
That is, both ExpressView and the other package would hang when the
second one was started.  (I didn't find this particularly surprising
:-)  Loading the packet driver twice with different software interrupts
also failed.

At this point, I installed a second ethernet card in the machine.  Now,
I have a 3C501 for ExpressView and a 3C503 for other uses.  Initially,
I loaded the driver for ExpressView with interrupt 0x69 and the 3C503
driver with 0x60.  ExpressView would not work at all in this
configuration.  Experimentation showed that having any packet driver
loaded, even for a different card, with a lower software interrupt
prevented ExpressView from working.  I surmise that this is due to a
programming error where one part of the code scans for a driver in the
allowable range, much like PC Telnet does, but another part demands
that 0x69 be used.

My current configuration is to:

(1) load the 3C503 driver with hardware interrupt 5, I/O address 0x300,
software interrupt 0x6a, and

(2) load the 3C501 driver with hardware interrupt 3, I/O address 0x310,
software interrupt 0x69.

Each card has a separate IP address and host name assigned.  With this
configuration, ExpressView works correctly.  However, WinQVT reports
that its IP address is in use by the other card when rarp is used to
determine the IP address.  I have verified that each package operates
correctly alone and uses the correct card (by the old disconnect the
cable trick).  Separately, they do use the correct IP address as well.

Given all of the above, my questions are:

(1) Is there a configuration that should work using one ethernet card?

(2) Is it permissible to have more than one instance of a packet driver
per card, given different software interrupts?  If allowable, are there
any special considerations which I did not address as described above?

(3) Is there any problem with having more than one instance of a packet
driver when each instance is associated with a different ethernet
card?

(4) Does the failure of ExpressView when a driver with an interrupt
less than 0x69 is present suggest an error on their part or in my
configuration?

(5) Why does WinQVT report that the other card is using the same IP
address as its card expects to use when rarp is enabled?

Any hints, nudges, kicks, etc. in the right direction would be
appreciated.
-- 
-----------------------------------------------------------------------------
Keith Pyle                                UUCP: ...!cs.utexas.edu!execu!keith
Comshare, Inc., Austin, Texas             Internet: keith@execu.com
-----------------------------------------------------------------------------

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 04:18:34 GMT
From:      ferriby@perot.com
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Abysmal GSI/NIC service, WAS:Re: Updating root info.

In article <1991Oct22.141708.27208@rock.concert.net>, fty@sunvis.rtpnc.epa.gov (Frank Terhaar-Yonkers) writes:
> 
> Ditto for our network: 134.67
> 
> It's been a MONTH and the PTR records have not been updated.
> Pretty crappy service indeed ...
> 
>  >In article <1991Oct22.125839.9215@src.honeywell.com>, bergum@src.honeywell.com (David Bergum) writes:
>  >I desparately need to have the root ns records updated for my domain to
>  >reflect changes in my servers, but I have not gotten any response from
>  >HOSTMASTER.  Is there an alternate authority that can make changes to the
>  >root servers?  The old NIC was able to make changes in several days,
>  >usually, but I have had my request in since October 4 with no response.
>  
>  cheers - Frank Terhaar-Yonkers
> 	  fty@sunvis.rtpnc.epa.gov
>           U.S. EPA
>           RTP,  NC

I agree.  I've been waiting on an application for additional network numbers
since 1 October.  I have hounded GSI every day for an answer.  Monday the
13th I was verbally told that they were approved.  Friday the 18th I was
verbally given the numbers.  I can't proceed without an official document
in hand and every day someone at GSI tells me there going to send them to me.
I frankly would not care if they could smoke signal them to me if it would
be considered official.  (SSCP - Smoke Signal Control Protocol - That is,
perhaps, what IBM meant...  ;-| )

It appears to me that the service cutover between SRI and GSI was poorly
planned and is still incomplete.  I hope for GSI that the problems that
they are experiencing get resolved soon -- the "quality of cybernetic life"
is at stake.

--                             
John Ferriby
Perot Systems Corporation    Telephone: +1-313-641-3660
4555 Corporate Drive         Internet: ferriby@perot.com
Troy, MI 48098-6353          UUCP: {uunet,decwrl,sun}!perot!ferriby

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 07:48:39 GMT
From:      ojr@itk.unit.no (Ornulf Rodseth)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and Ethernet in real time control?


I'm not sure if this is the correct place for a question like this,
but anyway:

Do anyone have a good reference on why TCP/IP on an Ethernet is good
enough for real time control? The main argument against Ethernet is
the lack of determinism. The argument against TCP/IP are many;
complexity of the supporting software, no easy to use priority, high
overhead etc.

I would also like to get references on peoples, organizations or
companies that have used TCP/IP in real time control and demonstrated
its usefulness. Any other stuff with relevance to these subjects are
also welcomed.

Please mail me and I'll summarize for the list.


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

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 13:06:00 GMT
From:      mhall@ducvax.auburn.edu (MARK HALL)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Ethernet/VTAM Print problems

Hello all,
     I'll begin with a summary of our existing configuration,
and then ask my question.  If this is posted to the wrong group,
please provide other groups for follow-up.
     Currently, our office uses EXTRA! and 3270 cards to connect
to our mainframe.  One feature we have with this configuration is
a mainframe printer associated with each PC.
     In an effort to improve our workstations and move toward the
stated direction of the organization, we will be installing an 
ethernet using TCP/IP.  Question:  Is there any software that will
accept VTAM output, place it in ethernet packets, and pass it to 
the correct IP address?  
     All help will be appreciated!

P.S.  I've reviewed LPD; it's close, but doesn't function
  as we would prefer.

Mark Hall(N4ZUK)                 MHall@Ducvax.Auburn.Edu
144 Parker Hall                  
Auburn University, AL  36849 

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 14:24:32 GMT
From:      dxe@cassidy (Dan Ellsweig - Network planning)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP test suites


Greetings

We are about to bring our IBM mainframes into the IP world. We
are looking at the IBM implementation of the TCP stack in MVS.
I am wondering if there is an accepted test suite
available in the internet public domain?? This would be extremely
useful when comparing this new product against the functionality
currently available in our IP network.

Thanks
-- 
*****************************************************************************
Dan Ellsweig    **   Salomon Technology Services      **  dxe@malta.sbi.com
                **   Route 3   East Rutherford, N.J.  **
*****************************************************************************

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 15:00:55 GMT
From:      mike@ap542.uucp (Mike Hoffmann)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   Sendmail, IDA, BIND on SVR4

Hello to all!

I am urgently looking for help on getting sendmail 5.61 w/ IDA extensions
running on our SVR4 box using BIND.

I haver ported BIND 4.8.3 and it runs fine as far as I can see (I am *not*
a guru on this 1/2 :-)

I have managed to get the sendmail compiled and (seemingly) running using
the /usr/ucb/cc compiler.

When doing tests though,first I noticed that for some reason I can't
work w/o a sendmail.fc file. Is this generally so? All my previous sm
experiences have been with *very* old versions, that were provided on
our machines, but at least they worked.

Then, after I waited to get an .fc file and start a simple test
(like sendmail -v user@somehost.localdomain.domain)
I get an "authoritative answer from nameserver: host not found" or something
with that meaning, even though this host is perfectly accessible via
ftp or telnet, and nslookup also gives OK information on this system.
This remote system has it's own running BIND, but as of yet only an old
sendmail running.

I've run through the docs, but got hopelessly lost.

Please, this is our first attempt at getting access to the Internet and
will become something as the "example installation" on which the decision
is based if the project is scraped or not. (Nice fix I'm in, isn't it? :-( )

Thanks to any guru who's willing to help!
Mike

P.S.: response via e-mail to mike%ap542@ztivax.uucp, or the Internet address
in my sig.
-- 
Mike Hoffmann, Siemens-Nixdorf AG, SNI AP 712  
UUCP: mike@ap542.uucp | INTERNET: mike%ap542@ztivax.siemens.com
May all your seals be smiling! (lawder@ohsu3b2.ohsu.EDU)

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 15:19:32 GMT
From:      berger@dcox (Mike Berger)
To:        comp.protocols.tcp-ip
Subject:   Re: Can we use tn3270 protocol to do a file transfer ?

pxv0618@hertz.njit.edu (Paranjothi Varadarajan) writes:
>I guess the subject says most of it, except that I have the source code
>for tn3270 and am trying to figure-out how can I use it do a file
>transfer between my unix machine and the IBM mainframe.
*----
If you have PC/VM Bond on your IBM mainframe, the 3270 protocol
has facilities for file transfer (using IND$FILE commands).  I
don't know the low level protocol details.
--
	Mike Berger
	Department of Statistics, University of Illinois
	AT&TNET     217-244-6067
	Internet    berger@atropa.stat.uiuc.edu

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 15:54:00 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

In article <1991Oct18.172357.1381@cirrus.com> venu@cirrus.com (Venu Nayar) writes:
>In <1991Oct18.141108.21940@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>
>>I was wondering, what is a generally supported maximum packet size on UDP?
>
>	What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium. 
>	Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.

While it is true in theory that a UDP datagram can be up to 65K,  most
implementations have default or hard limits on the size of UDP datagrams
that the networking code will accept.  I believe the question was aimed
at finding a safe value that will be accepted by most machines.

Art

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 16:01:44 GMT
From:      matthew@ooc.uva.nl (Matthew Lewis)
To:        comp.unix.aix,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   WANTED: experiences with PPP and SLIP on an RS/6000 under AIX

Hello!  As the subject says... The problem is the following:  we have a
number of offices scattered around the Netherlands.  Each office has at
least on RS/6000.  A number of the offices are connected via bridges (no
comments please :-), while many others are too small to justify the expense
of a permanent connection.  The principle traffic to these offices will be
e-mail.

We are investigating the different ways to ship mail back and forth, and
have, of course, considered plain-and-simple UUCP.  UUCP has message size
limits, so we would also like to find out about serial-line network
connections.  The budget is up, so we also have to use existing hardware
(i.e., no new Ciscos, no Netblazers, etc).  We tried the SLIP
implementation that comes with AIX 2.2.1, and had problems.

My questions are:

1.  Is there a PPP implementation for the RS/6000?

2.  Is there another implementation of SLIP?

3.  Is there a way to set up SLIP or PPP to establish the connection if
there is a packet waiting?

4.  How do you get around the problem of getting mail if one systems calls
the other with outgoing mail?  Someone mentioned UUCP over IP, but does
that still have the 100K limitation?

I've set followups to the AIX group.  Reply if you like via e-mail, and I
will summarize.

Thanks in advance.

Matthew Lewis
Sys admin, CICT
University of Amsterdam
-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 16:14:52 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP via Radio.

ws04medi@hpuircz.italy.HP.COM (Saverio Saggese) writes:
>>I have heard that someone has implemented tcp-ip over radio. ...
>>Email responce is preferred, I can summarize if there is alot of interest.
 
>PLS ask to any Radioamateur you know : we are using tcp-ip protocol...
>If you have trouble contact American Radio Realy League -ARRL- !

The original poster should probably follow this up with a more specific
inquiry.  Data via amateur radio (ham, shortwave) has been transfered using
old protocols ever since the Baudot (or however that's spelled) character
set was invented.  Modern wireless TCP/IP, for me, conjures up an image
of short-haul, high-speed LANs intended for temporary use or for
connecting buildings where underground conduit is not feasible.  Those
are two entirely different market segments.

-rich

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 16:30:37 GMT
From:      cattelld@prlhp1.prl.philips.co.uk (David Cattell)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   HELP: Setting IP options with setsockopt()



Has anybody out there ever tried setting options on a socket using
setsockopt() ? I'm particularly interested in setting up a strict
route at the IP level for a UDP/datagram on a Sun.

After going around and around in the manuals I came up with code 
similar to the fragment given below. 'sd' is a datagram socket
the product of socket() and bind() calls. When this code executes
the perror() call produces:

	setsockopt: Invalid argument


---------------- Code Fragment ---------------------------------

	strict_route = (char *) calloc( 100, sizeof( char ) );
	
	proto = getprotobyname( "ip" );
	
	strict_route[0] = (char) 137;
	strict_route[1] = (char) 11;
	strict_route[2] = (char) 4;	
	strict_route[3] = (char) 130;
	strict_route[4] = (char) 141;
	strict_route[5] = (char) 10;
	strict_route[6] = (char) 153;
	strict_route[7] = (char) 130;
	strict_route[8] = (char) 141;
	strict_route[9] = (char) 13;
	strict_route[10] = (char) 2;
	strict_route[11] = (char) 0;
	
	route_opt_len = 11;
	
        if ( setsockopt( sd, proto->p_proto, IP_OPTIONS, 
			strict_route, route_opt_len ) == -1 )
		perror( "setsockopt" );

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

To attempt to eliminate an invalid format in strict_route[] I replaced
it and route_opt_len with 0's and got no errors. So is the format
of strict_route[] incorrect?

Trying the code on an Apollo (bit of history for you there) causes it
to claim that the options are not supported at that level. This I think
refers to the IP_OPTIONS argument as the complaint persists when I
set the last 2 args to 0 again. This in itself is rather odd.

I'd really appreciate a few words of wisdom on this as it's getting 
to be frustrating. What am I doing wrong.

Please email me direct at: cattell@prl.philips.co.uk


Dave Cattell
Philips Research, England.

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 16:44:46 GMT
From:      jon@netlabs.com (Jonathan Biggar)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Abysmal GSI/NIC service, WAS: Re: Updating root info.

Netlabs just attached to Cerfnet on October 1, and I sent my domain
registration the next day to get our name servers on line.  I still haven't
heard anything at all.  This is causing some difficulties, because there
are a number of ftp servers that do not allow connections from machines
that are not registered in the DNS.

What gives?

Jon Biggar
jon@netlabs.com

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 18:20:24 GMT
From:      peter@ski.austin.ibm.com (Peter Jeffe 512.838.4019)
To:        comp.protocols.tcp-ip
Subject:   rcp ftruncate() and nfs

In the BSD tahoe code there was an ftruncate() call added to rcp that
attempts to truncate the created (remote) file to the size of the
original.  The problem is that this fails if the original mode is not
writeable, and the target file is on an NFS-mounted filesystem.  It
succeeds on a local target file because it is still open for writing,
even though its mode is not writeable.

Does anyone have any insight into why this call is in there and what
harm might be done if it is yanked?  Apparently it doesn't exist in
the Sun 4.1.1 code.

-- 
peter jeffe  ...cs.utexas.edu!ibmchs!ski.austin.ibm.com!peter

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 18:49:18 GMT
From:      randy@ux1.cso.uiuc.edu (Randall E. Cotton)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC

johna@mobdig.ncal.mobdig.com (John Antypas) writes:

>To all Netland Net Gurus who might have an answer for this.
 
>I expect the new GSI NIC to be slow, but as of late, it appears to have
>dropped off the net.  All attempts at contact whether they're electronic
>or voice fail. 
 
>Does anyone have any inside info as to what's going on at the NIC and
>when we might have a (small) hope of internet service?
>-- 
>John Antypas/Software Engineer
>MobleDigital Corp.
>johna@mobdig.com			(Modern way)
>...!{rtech, uupsi, soft21}!mobdig!johna {People into tried and true}

When you try to do a whois database lookup with the old machine
(nisc.sri.com aka sri-nic.arpa) you get a little text blurb that points
you to the new machine (nic.ddn.mil) and includes a toll free number
for GSI - 1-800-365-3642. I called and inquired about the reachability
of nic.ddn.mil. It seems that they didn't forsee the ammount of traffic
and there is a network link somewhere (presumably between Milnet and
Internet) that is being ridiculously overloaded. I asked what the speed
of this overloaded link was and they said "You don't want to know".
This explains the fact that although nic.ddn.mil is actually out there
(some ping requests get replied to) the drop rate is heinous (around
90% from U of Illinois at Champaign). They say they're working on
getting a T1 link.
-- 
--------------------------------------------------------------------------------
Randall Cotton                                             Disclaimer: any views
Computing Services Office Network Support                      expressed are the
University of Illinois Urbana/Champaign                   sole opinion of my dog

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 19:27:46 GMT
From:      callon@bigfut.enet.dec.com
To:        comp.protocols.tcp-ip, comp.protocols.tcp-ip.usenet
Subject:   re: InterOp Debate (response to trip report by Joachim Martillo)

From:	BIGFUT::CALLON       23-OCT-1991 11:57:20.36
To:	NM%DECWRL::"martillo@clearpoint.com"
CC:	MIPSBX::THOMAS, RADIA::PERLMAN, CALLON
Subj:	re: InterOp Debate


Joachim;

I think that there is some confusion implicit in your
message. Unfortunately, the debate format did not leave
enough time to go over the various routing proposals in
enough detail (Radia did this in a two day tutorial, but
that is another story -- most of the debate audience
probably didn't go to Radia's tutorial).

I will let Radia comment on the "best" route issue 
(actually, neither OSPF nor IS-IS provides the guaranteed
"best" route -- the allowance of sub-optimal routes is a
complex tradeoff versus scalability and robustness).

Regarding the desireability of common routing and the
connection-oriented OSI stack: The IS-IS protocol provides
routing for OSI CLNP (the connectionless network protocol),
and not for X.25. Thus, the Integrated IS-IS only uses
common routes for CLNP and for IP, not for X.25 packets. 
CLNP was actually designed based on IP, and thus the two
protocols are very similar (the main difference is that CLNP
allows for longer addresses -- necessary if you want to
scale to a worldwide internet).

I would agree that X.25 (OSI Connection-oriented traffic)
should be handled independently from CLNP and IP traffic for
the reason that you stated -- particularly, that X.25 traffic
requires very different handling (reliable delivery, strict
flow control, etc). 

In terms of "OSI pakets at corresponding layers always carry
the same sorts of information...". For both IP and OSI CLNP,
the routing is done on the basis of a destination address
(and optionally TOS information) contained in the network
layer header. Thus, given the similarity of TOS handling
between the approaches, any differences between the approaches 
can be reduced to the differences in how they handle routing
to specific destination addresses. However, they also both 
allow IP addresses and OSI addresses to be handled
independently, and for external routing to be handled
independently. Thus, the differences in routes chosen comes
down to differences in picking routes between routers.  

However, neither approach allows for routing based on anything
other than destination address and type of service. Thus, for
example, your comment about "large IP packets which contain UDP
messages may optimally follow different routes than small IP
packets which contain TCP messages" again is not a difference
between the two approaches: If you use a different TOS for the 
two approaches, then each approach handles this. If, on the other
hand, you want to route according to packet length, then neither
approach will allow this (neither IS-IS nor OSPF considers packet
length in routing -- the old "fuzzballs" which were used in Dave
Mill's NSFNET backbone allowed some provision for packet length,
but this did not work particularly well and has not been adopted
by any other routing protocol that I am aware of).

Ross

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 23:03:42 GMT
From:      jwp@bernie.sal.wisc.edu (Jeffrey W Percival)
To:        comp.protocols.tcp-ip
Subject:   Questions from a socket novice

I am new to sockets, and am not too interested in reinventing the wheel
if I don't have to...

I am creating a client/server application, and need reliable, sequenced
transmission, so I chose a TCP socket stream.  Now, my client and
server exchange messages (of my own creation) but TCP stream sockets do
not preserve message boundaries, so I think I have to restore the
illusion of quantized messages myself, right?  Is the common solution
for this need to create a layer of software in each process that
restores the message-oriented transfer?

If so, can someone give me a thumbnail sketch on how this is done?  How
does one end of the socket "synchronize" to the messages (assuming the
other end can screw up a message)?  How is a partial message handled,
in the case where the network introduces some time gap within a
message?  Does the "message restoration" layer buffer things up as they
appear?

I ask these things because it seems like this should have been worked
out a billion times before...
-- 
Jeffrey W Percival (jwp@larry.sal.wisc.edu) (608)262-8686

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 23:40:22 GMT
From:      chet@Advansoft.COM (Chet Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet not working? (Should be NIC.DDN.MIL not working)

>>>>> On 22 Oct 91, Rich Stevens said:

rich> Can someone with more knowledge of what's happened here shed
rich> some light on this whole affair. 

And please post it to the net. I've seen a few people in this group
ask what's going on, but have seen no explanation. This seems like a
serious problem. Somebody must have some info.

rich>  I recall seeing a posting by the NSF in May concerning "DCA
rich> funding for Internet registration will soon end.  That coupled
rich> with the expiration of NFS's grant to BBN for the NNSC ...".
rich> They were talking about network information services for the
rich> interim-NREN.  Is that in any way related to the switch of the
rich> NIC from SRI to GSI?  Does anyone know just who GSI really is?
rich> I assume they underbid SRI for this contract from DCA?  Someone
rich> asked weeks ago, after the first posting from SRI about the
rich> changeover, for someone from GSI to stand up and introduce
rich> themselves, but GSI seems like an unknown still.  Thanks.

rich> 	Rich Stevens  (rstevens@noao.edu)
--
Chet Wood     .      chet@advansoft.com      .     (408)727-3357 X269
    .    Advansoft Research Corporation  
         .      4301 Great America Parkway, Suite 600    
              .            Santa Clara, CA 95054, USA    

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 91 23:42:48 GMT
From:      jspencer@cass.ma02.bull.com (Joel Spencer)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over x.25 to HP-UX

hi.  i am trying to connect my unix machine to a HP-UX
unix machine via tcp/ip over x.25.  i am getting through to the
HP machine and am receiving a DTE (HP) originated cleardown.  i 
do not have an HP manual and was wondering if anyone knows the
private HP clear down reason codes.  what i see in the
cleardown (x.25) packet is:

cause= 00  (i.e. the cleardown is from the remote computer)
diagnostic= 0xe4 (228 in decimal)

does anyone know the meaning of the 0xe4 reason code??

thanks,

-- 
=======================================================================
Joel Spencer
Bull HN Worldwide Information Systems
Billerica, Massachusetts USA

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 00:05:48 GMT
From:      wkt@sserve (Warren Toomey)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP via Radio.

From article by richb@kronos.com (Rich Braun):
> ws04medi@hpuircz.italy.HP.COM (Saverio Saggese) writes:
>>>I have heard that someone has implemented tcp-ip over radio. ...
>>>Email responce is preferred, I can summarize if there is alot of interest.
 
>>PLS ask to any Radioamateur you know : we are using tcp-ip protocol...
>>If you have trouble contact American Radio Realy League -ARRL- !
> 
> The original poster should probably follow this up with a more specific
> inquiry.  Data via amateur radio (ham, shortwave) has been transfered using
> old protocols ever since the Baudot (or however that's spelled) character
> set was invented.

Yes, but amateurs have also picked up _new_ protocols along the way. We are
not living in the dark ages :-)

Phil Karn (of Karn's algorithm fame) has written a tcp/ip package for
amateur (and others) use. It runs on PCs, Amigas and Macs, and provides
the tcp/ip protocol stack, sockets, many of the normal applications
(finger, telnet, ftp, smtp, echo, discard, rip), and supports Ethernet
interfaces using the Clarkson packet drivers, as well as SLIP, PPP, and
well as an AX.25 interface for amateur radio use. The PC and Amiga versions
have internal multitasking, allowing all the servers and clients to run
at the `same' time.

> Modern wireless TCP/IP, for me, conjures up an image
> of short-haul, high-speed LANs intended for temporary use or for
> connecting buildings where underground conduit is not feasible.  Those
> are two entirely different market segments.

Amateur radio tcp/ip use is at baud rates from 1200bps up to 56Kbps, and
perhaps higher, and from HF frequencies up to microwave.

You can pick up the binaries, and source, and docs, and much more, if you
ftp to ucsd.edu, and cd into the (pub?/)hamradio/ka9q directory.


       Warren Toomey VK1XWT, cold but happy
      Deep in the bowels of ADFA Comp Science.
  `POSIX Job Control?! POXY job control more like!'

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 02:26:44 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver


   (1) Is there a configuration that should work using one ethernet card?

No.  The problem is that you cannot decide which TCP/IP protocol stack should
receive which TCP/IP packets.

   (2) Is it permissible to have more than one instance of a packet driver
   per card, given different software interrupts?  If allowable, are there
   any special considerations which I did not address as described above?

No.  A packet driver needs to have total control over a board.  Same for
any other Ethernet driver, NDIS, ODI, built-in, whatever.

   (3) Is there any problem with having more than one instance of a packet
   driver when each instance is associated with a different ethernet
   card?

It's only a problem when your network package expects that it can scan for
a packet driver, and use the first one it finds.

   (4) Does the failure of ExpressView when a driver with an interrupt
   less than 0x69 is present suggest an error on their part or in my
   configuration?

Couldn't really say.  Perhaps they just like the number 69?

   (5) Why does WinQVT report that the other card is using the same IP
   address as its card expects to use when rarp is enabled?

It shouldn't.  What it's doing is ARPing for its own IP address, and the
protocol stack running the other card is replying.

--
--russ <nelson@clutx.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.

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 05:26:44 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC

In article <1991Oct23.184918.18999@ux1.cso.uiuc.edu> randy@ux1.cso.uiuc.edu (Randall E. Cotton) writes:
>                It seems that [GSI] didn't forsee the amount of traffic

There are two sides to this. It is one thing that a bidder
underestimates the scope of the work. It is just as bad that the
contracting agency doesn't sort this out before award. I can understand
why SRI would be reluctant to circulate details about their traffic to
help out competing bidders, but certainly DISA would have been able to
obtain statistics about the traffic through FIX-WEST from NSFnet.

>and there is a network link somewhere (presumably between Milnet and
>Internet) that is being ridiculously overloaded.

The MILNET, by virtue of being an interconnected TCP/IP network, is part
of the Internet. The choke point is between MILNET and GSI, although I
am willing to bet that the traffic from MERIT is choking up the rest of
MILNET as well.

>                                                 I asked what the speed
>of this overloaded link was and they said "You don't want to know".

I believe the MILNET port is a 56 kbps X.25 DDN Access line.

>They say they're working on getting a T1 link.

The rumor mill said NSF might donate a T1 link to bypass MILNET for root
name service requests. In self defense.

Seen from here, it looks like NSFnet is timing out the connectivity due
to high transit delays (caused by overzealous buffering). This causes
constant route flapping. Traceroute from here mostly show routing loops
either in our regional or in the T1 NSFnet, followed by ENETUNREACH from
the nearest T1 NSS.

I agree, this is a disaster, worthy of blemishing somebody's resume.

I suspect we could improve the situation if the root name server list
were re-sorted to put C.NYSER.NET and NS.NASA.GOV at the top of the
root server list, and put NIC.DDN.MIL at the bottom. This just might
keep top-level domain queries from the NSF side out of MILNET
altogether.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 12:39:45 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet not working? (Should be NIC.DDN.MIL not working)

In <CHET.91Oct23164022@comet.Advansoft.COM> chet@Advansoft.COM (Chet Wood) writes:

>>>>>> On 22 Oct 91, Rich Stevens said:
 
>rich>  I recall seeing a posting by the NSF in May concerning "DCA
>rich> funding for Internet registration will soon end.  That coupled
>rich> with the expiration of NFS's grant to BBN for the NNSC ...".

Just a small clarification here.  The NNSC is still alive and well.
Some staff changes may have made things look a bit confusing (for example,
I was on sabbatical in Sweden until a couple of weeks ago, but now I'm back)
but we're here and funded to keep providing services until NSF's super-NIC
proposal gets awarded in early 1992.

Note this doesn't mean we have any influence about what goes on with NIC.DDN.MIL

Craig Partridge
craig@nnsc.nsf.net

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 14:41:47 GMT
From:      schommer@rhrk.uni-kl.de (Michael Schommer [Inf-FSE])
To:        comp.unix.questions,comp.unix.aix,bit.listserv.aix,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,bit.listserv.ibmtcp-l
Subject:   RS6000 + PCs in one Network



  Hi Folks !!

  I'm looking for somebody who has connected PCs to an IBM RS6000 via
  Token Ring or Ethernet, using some kind of DOS TCP-software, and is
  using the PCs as X-terminals (using some kind of X-software).

  If you have successfully done this task - please feel free to share your
  experiences with me. Simply send me some EMail.

  Thank you in advance..
                                                Saari

 Michael H. Schommer                                schommer@rhrk.uni-kl.de
 Am Glockenturm 10                                ixmo@informatik.uni-kl.de
 6750 Kaiserslautern                                         IRCNICK: Saari
                                                     Amateur Radio: DC 3 VR
 Vox: 0631 / 78514                   "Phantasie ist wichtiger als Wissen !"
 Btx: 063178455-0001                                      (Albert Einstein)

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 15:11:43 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: InterOp Debate (response to trip report by Joachim Martillo)

Ross Calon wrote:
                                                  If, on the other
   hand, you want to route according to packet length, then neither
   approach will allow this (neither IS-IS nor OSPF considers packet
   length in routing -- the old "fuzzballs" which were used in Dave
   Mill's NSFNET backbone allowed some provision for packet length,
   but this did not work particularly well and has not been adopted
   by any other routing protocol that I am aware of).

In fact, it is a bad idea to make routing decisions based on packet
length in a general-purpose system.  Consider a router implementation
that decides short packets must be interactive and should be given
priority over long packets, which must be FTP.  Now put a "real time"
transaction oriented application on this network.  Imagine that a
typical transaction is 10% longer than the maximum packet length in some
network which the transaction will traverse.  Some network layer entity
will split the transaction into two packets, most likely a long one
followed by a short one.  Farther downstram, if the load is heavy, the
short packet will be given priority and the long packet will be delayed.
Since the application is real time, most likely either the arrival of
the second packet will trigger the receiver to ask for retransmission,
or the extra delay in delivery of the first packet will lead to a delay
in response which triggers a timer-based retransmission by the sender.

Alex
 

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 15:36:15 GMT
From:      dc@micronics.com (Darren Croke)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

In article <1991Oct18.172357.1381@cirrus.com> venu@cirrus.com (Venu Nayar) writes:
>In <1991Oct18.141108.21940@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>
>>I was wondering, what is a generally supported maximum packet size on UDP?
>
>	What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium. 
>	Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.

The 4.3 bsd implementation maintains a global called udp_recvspace. 
This variable is initialized with the following line of code -

u_long  udp_recvspace = 4 * (1024+sizeof(struct sockaddr_in)); /* 4 1K dgrams */

During the creation of a udp socket, this variable is passed to a 
routine called soreserve() which sets the hiwater mark for the receive 
socket buffer which effectively limits received udp datagram size.

Obviously, anyone using this code can increase the value but I'm sure 
you'll find implementations out there that have gone with the default.

-- 
 Darren Croke         Micronics Computers
 dc@micronics.com     X Terminal Division
                          (415) 651-2300

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 19:43:38 GMT
From:      bhelm@sisters.cs.uoregon.edu (B. Robert Helm)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Anyone building network-manageable applications?


Our research group at the University of Oregon has gotten interested
in the problems of designing network applications which are manageable
by network management protocols.  For example, what would it take to
make e-mail system manageable by SNMP?  What elements would go into
the MIB, for instance?

Do you know anyone working on this problem, for either SNMP or CMIS/CMIP?
If so, I would appreciate pointers.  I will make a digest and could mail
it to the list if there is interest.

Rob Helm (bhelm@cs.uoregon.edu)
Department of Computer and Information Science
University of Oregon
Eugene, OR 97403
(01) (503) 346-4424

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 23:03:32 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC

In article <1991Oct24.052644.17033@spectrum.CMC.COM>, lars@spectrum.CMC.COM (Lars Poulsen) writes:
|> 
|> I suspect we could improve the situation if the root name server list
|> were re-sorted to put C.NYSER.NET and NS.NASA.GOV at the top of the
|> root server list, and put NIC.DDN.MIL at the bottom. This just might
|> keep top-level domain queries from the NSF side out of MILNET
|> altogether.

Unfortunately, this does not solve all problems. In particular, it does not
solve the problem that the other root servers are unable to zone transfer to
the master (NS.NIC.DDN.MIL) to refresh their databases... There was a recent
message on either 'namedroppers' or 'bind' showing how out of date the serial
numbers on various root servers are...

This whole debacle is really inexcusable - it doesn't take a genius to figure
out that a 56KB X.25 link to the MILNET would be inadequate for the central NIC
facility. A quick examination of history will show that SRI moved the root
server off of a MILNET-only path quite some time ago precisely because of a
congestion problem they were seeing (for those who don't remember, the root
server used to be on the TOPS-20 NIC.DDN.MIL which was only reachable via
MILNET; it was moved to a Sun connected to a BARRNet/NSFNet-connected network 
well over a year ago).

	--Vince

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 91 23:55:12 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   KA9Q display problem

Thanks to pointers received from readers of this group we've now got ka9q
running on a small ethernet with Western Digital Elite16 ethernet cards.  We
are experiencing a small display anomaly when telneting into the hosts -
perhaps someone can explain it to me.

Frequently when text is displayed there is a small problem at the beginning of
the line.  Text that SHOULD look like this:

Line 1
Line 2
Line 3
Line 4
Line 5

Will instead look like this:

Line 1
 ine 2
 Line 3
 Line 4
Line 5

Note that the first line with a problem seems to have the first character
replaced by a space, while the others are not missing any characters but
instead have a space INSERTED before them.

Has anyone else seen this?

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

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 01:24:13 GMT
From:      kudzu@tfs.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC


PING nic.ddn.mil: 100 data bytes

----nic.ddn.mil PING Statistics----
100 packets transmitted, 31 packets received, 69% packet loss
round-trip (ms)  min/avg/max = 1616/4057/10032


PING nic.funet.fi: 100 data bytes

----nic.funet.fi PING Statistics----
100 packets transmitted, 83 packets received, 17% packet loss
round-trip (ms)  min/avg/max = 366/448/733


I miss SRI, don't you?
-- 
Michael Sierchio                               TRW Financial Systems
                                                  1947 Center Street
kudzu@tfs.com                                Berkeley, CA 94704-1105
                                                        510.704.3380

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 02:46:51 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip
Subject:   Mailing list for KA9Q / NOS

How do I get myself on the mailing list for KA9Q,  more specifically LPD ?
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 08:04:23 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: subnets with different masks

nerd@percival.rain.com (Michael Galassi) writes:

>>Why only one?  RFC1219 describes a variable-subnet method for maximal address
>>allocations.
>Its one thing for the RFCs to describe a technique, its another for the
>masses to be able to use it.  The current revisions of RIP don't propagate

But it's still *possible*

>a netmask or even the number of network bits with the routes so we stick
>with the same netmask within a given network.  Surely other routing protocols
>allow this, maybe HELLO, or creative use of static/default routes but those
>of us with large SLIP based networks are painfully aware of the limitations
>of RIP.  (I'd love to be proven wrong)

I'm disagreeing with the idea that all subnets *should* have the same mask.
If current software can't handle it, then that's a pretty good reason to 
keep to one mask, but it shouldn't have to be so.
Are you sure it's a problem with RIP? Why should it need to announce masks?
(I admit to not having read the RIP rfc).  Isn't the problem the host
gateway code which doesn't allow for different masks?

>>Saying that 'you can only have *one* subnet mask throughout your
>>network' is rather like saying 'your class B net *must* have the same mask
>>as all the other class B networks', isn't it?
>Huh, how do you come up with this?  When I route to a 'B' network other
>than the one(s) I attach to directly no netmask is used or needed, I
>assume some gateway machine to that network will know how to deal with
>the address I select.
 
OK, I wasn't at all clear about what I meant. That was a bit of provocation
that failed badly *B^) But the clue is in your last phrase 'I assume..
gateway..will know..'.  You don't need to know what subnetting the other net
uses, you let the gateway handle that. As far as you're concerned, any
address eg 128.128.x.y goes to the same place.  It's exactly the same *within*
that net: say the main mask is 255.255.255.0 then if a host on 128.128.1.0
announces (via RIP) that it's a gateway to 128.128.2.0 then any packet
addressed to 128.128.2.x gets sent to it. The other hosts won't care if
really that host has 4 interfaces with netmask 255.255.255.240 to nets
128.128.2.16, 128.128.2.32, 128.128.2.48..  As long as the net structure is
kept hierarchical then it's OK. It would be incorrect to try to put a net
128.128.2.128 on the other side of a different host on net 128.128.1.0.  I
don't think RIP would like that! The gateway's RIP announcements to the
sub-subnet would be a bit messy: all the  128.128.2.n nets & all 16
(from the sub-subnet's point of view) possible 128.128.1.n nets. In fact,
would the sub-subnet machines recognise addresses 128.128.1.1-16 as valid
hosts at all? (or 128.128.1.32 ... 128.128.1.240-254)  Do they need to? 
Default static routes would be cleaner. 

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 08:30:15 GMT
From:      plipp@iaik.tu-graz.ac.at (Peter Lipp)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver

In article <42820@sequoia.UUCP> you write:
>(1) run an SNMP package called ExpressView (from David Systems, makers
>of 10BaseT concentrators) under Windows, and
Could you please give me some details about this package (costs, features, 
adress of company) or simply the latter, so that I can find out myself. What are
your impressions?
>
>(1) Is there a configuration that should work using one ethernet card?
I dont believe so, since SNMP and WINQVN use TCP/IP both (i think), WINQVNT
has it's own protocol stack and so both would have to say to the packet-driver:
give me all packets of type 800. Will bring the driver to desparation....

>(2) Is it permissible to have more than one instance of a packet driver
>per card, given different software interrupts?  If allowable, are there
>any special considerations which I did not address as described above?
No, the driver is level 2 of the ISO-Model. So - no chance.

>(3) Is there any problem with having more than one instance of a packet
>driver when each instance is associated with a different ethernet
>card?
No, we use such a configuration for bridging two ethernet-segments. But we
do not use any protocol-stacks or commercial products on top, we have our
own bridge-program developed. 
>
>(4) Does the failure of ExpressView when a driver with an interrupt
>less than 0x69 is present suggest an error on their part or in my
>configuration?
I do not know ExpressView, but I'd guess that this shoud indicate an error.
QVN has the interrupt specified in the .rc-file, so should be no problem. 
You could try to find out if ExpressView uses the first driver by trying by trying to use it by some other program. There should be an error-message if the
reqestet type is in use.
>
>(5) Why does WinQVT report that the other card is using the same IP
>address as its card expects to use when rarp is enabled?
This certainly is strange. Why are you using rarp anyway? Which machine is
your rarp server?
>
Sure, this helps not too much, but may be a little.
Have luck.
Peter


Dipl.Ing. Dr. Peter Lipp - Institute for Applied Information Processing
Technische Universitaet Graz, Austria (University of Technology, Graz, Austria)
plipp@iaik.tu-graz.ac.at

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 09:24:10 GMT
From:      timg@hpgnd.grenoble.hp.com (Tim GILL)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over x.25 to HP-UX

The HP-UX x25 header files contain:

 DIAG_ISO_OSI_CONNREJECT_PERM 228

 To me this indicates you are not registered on the HP side. This is probably
 related to the ipmap file on the HP side. This file is typically 
 /etc/x25/ipmap (but the name can be whatever..) and it contains lines
 as follows:

 192.1.1.44	4085551212  -URC -ARC
  IP address      X.121     options such as use reverse charge, accept reverse
			    charge, a CUG to use, etc.

 If there isn't any way to map the calling address with an IP address the
 inbound call will get cleared.  Once added to the file, x25init must be run
 again to activate the new address:  /etc/x25init -a /etc/x25/ipmap.  This does
 not effect existing connections. Typically, on the HP console a message
 similar to "X.121 to IP reverse map failed, calling address is ......" will
 be issued when the above condition is true.

 It is also possible that IP over X25 was not activated on the HP side. This
 is optional when installing/configuring the X.25 subsystem. But I imagine 
 you've already checked that out.  HP x25 also expects a protocol id of
 cc in the call packet to indicate IP as the destination protocol.

 Tim GILL

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 11:33:07 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC

In comp.protocols.tcp-ip, article <1991Oct24.230332.2990@CSD-NewsHost.Stanford.EDU>,
  vaf@Valinor.Stanford.EDU (Vince Fuller) writes:
< In article <1991Oct24.052644.17033@spectrum.CMC.COM>, lars@spectrum.CMC.COM (Lars Poulsen) writes:
< |> 
< |> I suspect we could improve the situation if the root name server list
< |> were re-sorted to put C.NYSER.NET and NS.NASA.GOV at the top of the
< |> root server list, and put NIC.DDN.MIL at the bottom. This just might
< |> keep top-level domain queries from the NSF side out of MILNET
< |> altogether.
< 
< Unfortunately, this does not solve all problems. In particular, it does not
< solve the problem that the other root servers are unable to zone transfer to
< the master (NS.NIC.DDN.MIL) to refresh their databases... There was a recent
< message on either 'namedroppers' or 'bind' showing how out of date the serial
< numbers on various root servers are...

On the other hand, if the root queries are redirected to other servers,
presumably the lines get less congested, and said other servers are then able
to run their zone transfers. _If_ enugh people actually do that reordering.

< This whole debacle is really inexcusable - it doesn't take a genius to figure
< out that a 56KB X.25 link to the MILNET would be inadequate for the central NIC
< facility.

Too true... Unfortunately, that insight alone doesn't improve the situation.
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 11:37:32 GMT
From:      tim@dell.co.uk (Tim Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: boot rom for wd8013??

Sorry this is requoted - it didn't get out the first time !

In <tim.688220737@holly> tim@dell.co.uk (Tim Wright) writes:

>In <1991Oct22.022727.5863@sobeco.com> jalonso@sobeco.com (j.alonso) writes:
 
>>I'd like to know if anyone has any info on a boot rom for a wd8013
>>ethernet card.  I know there are some roms available which allow a pc
>>to become "diskless" units and boot right from the wd8013 card on to
>>a PC-LAN (NOVELL).  What I'm looking for is something that will do the same
>>but allow a tcp/ip connection.
 
>This may be of more general interest.
>There is a company which sells a TCP/IP boot prom for various cards
>including the WD8003/8013 and very good it is too.
>The details are:
>Carl Schasiepen GmbH,
>Harkortstrasse 25, Postfach 22 60
>4030 Ratingen 1  Tiefenbroich
>Germany
>Tel: +49 2102 4906-0
>Telex: +49 2102 320

Tim
-- 
Tim Wright, Dell Computer Corp., Bracknell    |  Domain: tim@dell.co.uk
Berkshire, UK, RG12 1RW. Tel: +44-344-860456  |  Uucp: ...!ukc!delluk!tim
Smoke me a Kipper, I'll be back for breakfast - Red Dwarf

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 12:21:42 GMT
From:      sph@logitek.co.uk (Stephen Hope)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 <-> TCP Gateways (Was: Re: X25 access via TCP)

wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes:

>In article <561@ctsx.celtech.COM> dms@celtech.COM (Dave Stanhope) writes:
>]Sorry to go into so much detail but people keep
>]trying to sell me routers or telnet to pad translators, neither of
 
>Unlike Dave, I *am* trying to find something that sounds a lot like
>a "telnet-to-pad translator".  I'd like to be able to provide a
>reasonable interface to a public X.25 network so that people who
>connect through dial-up or dedicated pads with X.3/X.28/X.29 can
>connect to a TCP/IP network for telnet and maybe SMTP.
 
>The crude way is to provide a computer with X.25 login capability and telnet,
>but this means deassembling and reassembling packets of characters,
>and moving them between kernel and user a lot, possibly even one
>character at a time?
>It would be nice to have something that negotiated all the
>PAD and telnet options with some reasonable sort of translation,
>and ideally used a streams or similar approach to shuffle most
>packets between the x.25 and telnet stacks in the kernel,
>or alternatively to have the capability built into a router.
 
>Does anybody make something like that?  Thanks!
>-- 

cisco CPT-100 (I think this is the part number). This provides Telnet
<-> LAT <-> X25 Conversion in any direction. Also, the IGS router
will / has this type of capability, but only on versions with recent
firmware and 4M? of RAM

Also, 3Com make version of the CS/1 terminal server which act as XNS
or TCP/IP X25 gateways. These will also act as routers.

Stephen Hope

#include <std.disclaimer>

>				Pray for peace;      
>					Bill
># Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
># No, that's covered by the Drug Exception to the 4th Amendment

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 14:10:05 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC

In article <1991Oct24.052644.17033@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
=In article <1991Oct23.184918.18999@ux1.cso.uiuc.edu> randy@ux1.cso.uiuc.edu (Randall E. Cotton) writes:
=>                It seems that [GSI] didn't forsee the amount of traffic

=There are two sides to this. It is one thing that a bidder
=underestimates the scope of the work. It is just as bad that the
=contracting agency doesn't sort this out before award. I can understand
=why SRI would be reluctant to circulate details about their traffic to
=help out competing bidders, but certainly DISA would have been able to
=obtain statistics about the traffic through FIX-WEST from NSFnet.

It is the contractees' obligation to specify the level of performance
the bidders will have to provide. It would also seem that SRI would have
been obligated to provide this information to DISA on a regular basis,
as part of a monthly status report. (Responded to x thousand DNS requests,
sent out y hundred RFCs via the mail server, handled z thousand FTP
connections, got pinged fourteen billion times by someone testing their
software, etc.)

Apparently, there's been a major foulup. I can't see any excuse for 
something like this happening. Fortunantly, it's not impacting me, but
it's causing a lot of people a lot of trouble.

Perhaps we need to scrap the "lowest bidder" system, and start averaging
all bids--then award it to whoever is closest to the average.

-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
Become a pheresis donor. Loan your blood to the Red Cross for a couple
of hours. They, and cancer patients, will appreciate it.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 16:54:39 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   FDDI Concentrators

How do FDDI concentrators handle traffic between two of its directly
connected (single attach) ports? Is there some kind of filtering or
does all traffic sent on one port show up on all other ports?

What do prices per/port look like right now and say 6-12 months out.


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

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 22:06:15 GMT
From:      darrell@cypress.UCSC.EDU (Darrell Long)
To:        comp.dcom.modems,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Help with C-SL/IP

I am running SL/IP with compressed headers from my Sun SLC using a MultiTech
v.32/v.42{bis} modem to a Cisco terminal server via telnet to my Sun IPX.  If
it sounds a bit convoluted, well, it is...  The OS is SunOS 4.1.1.

The problem that I am having is that individual rlogin/telnet sessions will
freeze up for several seconds to several minutes at a time.  Looking at the
lights on the modem nothing is getting transmitted.  Type anything I like in
the window and nothing happens (the little light on the modem does flash).

The strange thing is that other connections will work just fine even other 
rlogin/telnet sessions.  FTP, rsh, NFS (!), SMTP, none of these seem to 
exhibit the problem.

Has anyone else seen this problem?  The answer may very well be to switch to
PPP, I don't know.  Any help will be greatly appreciated.


Many thanks, DL

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 91 22:25:45 GMT
From:      jspencer@cass.ma02.bull.com (Joel Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over x.25 to HP-UX

In article <990001@hpgnd.grenoble.hp.com> timg@hpgnd.grenoble.hp.com (Tim GILL) writes:
>The HP-UX x25 header files contain:
>
> DIAG_ISO_OSI_CONNREJECT_PERM 228
>
Tim thanks.  as it turns out the configuration was correct.  but the
reason it would not work is that when i sent the call
request packet i only included the CALLED address.  the pdn replaces
the CALLED address with the CALLING address as the packets
transverses the network.  but, the single address was what caused the
cleardown.

as soon as i changed my config. to send CALLED and CALLING addresses
the HP happily accepted the tcp over x.25 connect request.

interesting, n'est-ce pas?

btw, i would expect that Grenoble (in particular, Echirolles) would
be a good place for Bull/HP interconnect checkout!!!
-- 
=======================================================================
Joel Spencer
Bull HN Worldwide Information Systems
Billerica, Massachusetts USA

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 91 03:50:01 GMT
From:      jamin@jerico.usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   tcplib: A Library of TCP Internetwork Traffic Characteristics

The following technical report and the source library it describes are
available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
(Jerico's IP address is 128.125.51.6.) The directory contains the following 
files:

  2275 README
 19773 libtcp_ds31_ultrix41.a.Z
 19759 libtcp_hp90_hpux847.a.Z
 15984 libtcp_sun3_sunos411.a.Z
 16334 libtcp_sun4_sunos411.a.Z
  1267 tcpapps.h
  3134 tcplib.1
 96921 tcplib.tar.Z
761135 tcplibtr.ps.Z

All you need to transfer to use the library are: README, tcpapps.h, tcplib.1, 
and one of libtcp* that matches your setup.  You need tcplib.tar.Z only if you 
must generate the library yourself.  The file tcplibtr.ps.Z is the PostScript 
version of the tech. report which is introduced below:


    tcplib: A Library of TCP Internetwork Traffic Characteristics

                  Peter B. Danzig       Sugih Jamin

                       Computer Science Department, 
                    University of Southern California,
                    Los Angeles, California 90089-0781

                        traffic@excalibur.usc.edu

                               CS-SYS-91-01

1. Introduction
  When simulating computer networks, it is necessary to specify the traffic
between network nodes.  Typically, simulation studies of wide-area tcp/ip
networks model traffic as a combination of Poisson processes and maximal rate
streams--corresponding to telnet traffic and large file transfers respectively.
Such traffic models are justified when the modeler wants to show, for example,
that his flow control or gateway scheduling algorithm responds well to worst
case traffic or when essentially nothing is known about the real network
traffic.  However, such models do not reveal how similarly robust algorithms
respond to the common case load.
  This paper describes tcplib, a library to help generate realistic tcp/ip
network traffic.  Tcplib is motivated by our observation that present-day
wide-area tcp/ip traffic cannot be accurately modeled with simple analytical
expressions, but instead requires a combination of detailed knowledge of the
end-user applications responsible for the traffic and certain measured
probability distributions [Caceres91].  We collected three-day traces of wide-
area Internet traffic at UC Berkeley, University of Southern California, and
Bell Communications Research.  Our study identified that out of more than 35
different application programs, ftp, smtp, nntp, vmnet, telnet, and rlogin are
responsible for 96% of wide-area tcp/ip bytes.  Two related studies, one at
University College London and the other at Lawrence Berkeley Laboratory,
identified a subset of these six applications as responsible for most of their
wide-area tcp traffic [Crowcroft91] [Paxson91]. Tcplib models five of these six
applications.  It excluded vmnet, an IBM mail exchange application , because it
was absent from three of the five traces.
-- 
sugih                                             Use e-mail, save a tree.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 91 19:28:10 GMT
From:      gritton@altar.ee.byu.edu (Jamie Gritton)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Revolution (was Re: Alternate NICs)

In article <1991Oct26.014100.27160@decuac.dec.com> mjr@hussar.dco.dec.com
(Marcus J. Ranum) writes:
> michael@resonex.uucp (Michael Bryan) writes:
>>(Actually there is some amount of seriousness in the above... Is the
>>idea of a commercially or privately run NIC (hopefully more responsive
>>than GSI) totally unreasonable?)
>Maybe if we all got down on our knees and begged uunet?

   This seems actually a very serious subject. A long time ago (way before
my time), the internet used to be ARPA. Now it isn't. We need to keep up
with changing times.

   The internet is not the U.S. government. In fact, it isn't U.S. anything.
The time has come to get away from U.S. government control. Were I not an
American myself I would feel even worse about them telling me what to do.
   There are other people out there acting as root nameservers. One of them
could pick up the responsibility of being the master server. UUNET, or some
other commercial network service provider could do an excellent job. Of course
they would charge for this service, but isn't it worth it?
   A worldwide Internet not directly affiliated with any government bodies
could come up with the resources to have someone do such duties as a root
nameserver, an RFC depository/mediator, and hostmaster, and an assigned
number authority.

   Now comes the hard part: The U.S. government will not want to give up its
position of power in the internet. This is the reason for the new subject.
Whatever network service provider that did these things would have to really
stick its neck out with those of us who side with them for our independence.
The time has come to act!

   I doubt that anyone such as UUNET would go for such a dangerous position.
But something should be done. Or at least this should be food for thought.
This could use an extra disclaimer: my views are certainly my own. Brigham
Young University is not advicating this move, I'm sure. Don't sue them; don't
take away their government contracts. This is just personal opinion.

   Think about it.

--
James Gritton - gritton@ee.byu.edu - I disclaim

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 00:10:52 GMT
From:      lyndon@aupair.cs.athabascau.ca (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Revolution (was Re: Alternate NICs)

gritton@altar.ee.byu.edu (Jamie Gritton) writes:

>   I doubt that anyone such as UUNET would go for such a dangerous position.

Why not? SRI provided the service in exchange for money. GSI is providing (!)
it for (I suspect) less money. UUNET's fees to date have been very reasonable
for their current services. I'm sure they have a MUCH better idea of what it
would actually cost to operate the master root name server than GSI appears
to have.

Also, given your concern about the Internet going "international"
I would think they would be the most logical place to put the master,
based on their connectivity to Europe.

--
           atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca
                    Packet: ve6bbm@ve6mc.ab.can.noam
        As a math atheist, I should be excused from this.   --Calvin

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 06:29:19 GMT
From:      jamin@jerico.usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   tcplib tech report errata

> The following technical report and the source library it describes are
> available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
> (Jerico's IP address is 128.125.51.6.) The directory contains the following 
> files:
> 
>   2275 README
>  19773 libtcp_ds31_ultrix41.a.Z
>  19759 libtcp_hp90_hpux847.a.Z
>  15984 libtcp_sun3_sunos411.a.Z
>  16334 libtcp_sun4_sunos411.a.Z
>   1267 tcpapps.h
>   3134 tcplib.1
>  96921 tcplib.tar.Z
> 104781 tcplibtr.ps.Z

We just upgraded the operating system of our Macintoshes to System 7.
The printer driver that comes with the new system generates postscript
files incompatible with our macps program setup.  Some people have 
experienced difficulties printing out the tech. report tcplibtr.ps.
We have replaced the copy in the ftp directory with a printable one.
Those of you who got the version earlier than Oct 26 22:54 PDT might
want to make another trip to jerico.

We apologize for any inconveniences this caused and we would like to 
thank those who pointed out the problem to us.

-- 
sugih                                             Use e-mail, save a tree.

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 10:19:37 GMT
From:      t_anstey@darwin.ntu.edu.au
To:        comp.protocols.tcp-ip
Subject:   WHERE IS THE LATEST KA9Q ??

KA9Q was the first program that I ever set out to find out about when we
were first connected to the INTERNET. I started reading NEWS and got a
series of comments like, "I guess I could always use KA9Q". 

So I started out on the hunt for KA9Q as my introduction to what the INTERNET
could offer us. I could not have chosen a better subject to pursue and I am
indebted to Phil Kahn, firstly for writing it and then making it available.

A week ago I suddenly needed an IPX/IP router and of course KA9Q came to mind.
I decided to get the updated version and that is when the "S___ hit the fan".

I started with ARCHIE. It told me there were over 100+ sites offering it, and
after chasing around I can say most are out of date. The most sensible site
said that KA9Q file had been relocated to UCSD.DE ( I may be wrong it was
late). Needless to say this sensible approach was at, you've guessed it in 
one THUMPER.BELLCORE.COM, thank you Phil Karn again.

Now the disparity in versions across a series of FTP sites is a whole new
question I would like to raise. It is very generous to offer an FTP site but
are you going to keep it up to date. Clearly not. Seems to me a lot of disk
space wasted and a lot of confusion all round.

Anyway, what I would like to know is, where can I find the latest KA9Q and
the documentation. The version I have is 910614 and the documentation is
dated March 3 1991. Niether the software nor the documentation know about
BOOTPD yet documentation dated May 28, 1991, which is not complete, and I 
do not have any software, references BOOTPD which I am very interested.

If anyone can help me with the search please mail me direct as well as posting
to the list. Also a final plea for sanity from all the FTP offerers, if you
are going to do it, please keep it up to date, and make ARCHIEs life a bit
simpler.



Tery Anstey 
Computer Services
Northern Territory University
Darwin, NT

INTERNET: T_ANSTEY@DARWIN.NTU.EDU.AU

(No fancy end note, I cannot be bothered, bothering others)

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 20:54:55 GMT
From:      RXR300G%ODUVM.BITNET@ncsuvm.cc.ncsu.edu
To:        comp.protocols.tcp-ip
Subject:   who calls tcp_usrreq.c

I am trying to find out how tcp_usrreq.c is called. Or working backwards I
would like to know for example how tcp is called when an application program
calls the connect system call(in other words how SYSCALL(connect

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 23:07:43 GMT
From:      merlin@sulaco.Lonestar.ORG (David Hayes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Revolution (was Re: Alternate NICs)

In article <GRITTON.91Oct26152810@altar.ee.byu.edu> gritton@ee.byu.edu writes:
>   Now comes the hard part: The U.S. government will not want to give up its
>position of power in the internet. This is the reason for the new subject.
>James Gritton - gritton@ee.byu.edu - I disclaim

Now for the hard part: Cost. BYU, among other present US-Goverment-sponsored
internet sites, has access to a very nice T-1 (soon to be T-3) backbone,
the NSFnet. The reason the US goverment gets any control at all is that it
pays for those T-1 spans. (NSFnet members pay fees to their regional carrier.
Those fees only cover operations costs in the carrier's area - the national
backbone T-1 lines, the NSFnet proper, are free to the regionals.)

The Government would be out of the Internet business tomorrow if BYU, and
all the other Internet sites getting goverment subsidies, wanted to join
Alternet (UUnet's TCP/IP service). 

One problem holding up commercial internet services is this: One of the best
resources available on the net is the FTP archives. Commercial members who
have not been "blessed" by the goverment can't get access to these sites.
They can join Alternet, or PSInet, or CERFnet, but those commercial IP
providers are not permitted to pass traffic from non-blessed sites to 
the government-funded portions of the Internet.

Perhaps if each of the NSF regionals would buy a T-1 span to one or more of
the commercial providers, there would be a better market for commercial
users interested in TCP/IP.

	David Hayes, TCP/IP Specialist
	N-Team, Inc. Network Consultants
	817-929-9179

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 23:27:41 GMT
From:      gt5793a@prism.gatech.EDU (Kell Canty)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   TCP/IP interface w/the kernal


Hello everyone,

I'm trying to learn about the implementation of TCP/IP.
I've got Comer's "Internetworking with TCP/IP" volume II
and have read a lot of the RFC`s.  I recently added
ppp support to my Sun and ftp'd the BSD4.3 tcp/ip
source to learn more about it.  I feel comfortable with
the concepts and code in Comer's book, but aspects of the
BSD source are losing me.  I think the problem is mainly
with the interface between the networking code and
the kernal.  I'm just not getting some of it.  Also,
the functions (macros??) splimp(),splnet and splx() 
leave me completely stumped.  I find no references to them
except in odd system header files (like netisr.h ).  They
seem to have something to do with s.w. interupts but that's
about all I can find out.  Portions of the BSD code are 
surrounded with them almost like a mutex_lock/mutex_unlock
pairing.  Can someone point me to any literature about
the interface between the kernal and the networking code?
Also if anyone could give me a run down on the spl*
stuff I would GREATLY appreciate it.

Thanks,

Kell
-- 
James Kell Canty
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt5793a
Internet: gt5793a@prism.gatech.edu

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 91 23:35:43 GMT
From:      my@laverde.nsc.com (Michael Yip)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article km@mathcs.emory.edu (Ken Mandelberg) writes:
|> How do FDDI concentrators handle traffic between two of its directly
|> connected (single attach) ports? Is there some kind of filtering or
|> does all traffic sent on one port show up on all other ports?
|> 
|> What do prices per/port look like right now and say 6-12 months out.


All the traffic is just "flow-thru" between the two ports.  
No routing, no bridging and no filtering.

Consider the following diagram of the data going withing
a simple single attach concentrator ...

  +-------------------------<----------+
  |                                    |
  |   S     M1    M2    M3    M4       |
  +--+  +--+  +--+  +--+  +--+  +->MAC-+
     |  |  |  |  |  |  |  |  |  |
     V  ^  V  ^  V  ^  V  ^  V  ^
       
Network traffic comes in from the S-Port (or A, B Port), then
it goes thru all the M-Ports, reaches the MAC of the concentrator
and then gets out on the S-Port.

Of course more expensive concentrator can probably segment the
FDDI rings within the concentrator and perform routing between
the segmented rings ... but that's totally somethign else.  ;-)

The $/port is about $900-1200 now and it will go down when more
companies introduce FDDI products.  Maybe it will go down to 
$500 to $700 in the next half year but who knows.

By the way, if you are designing a FDDI network, make sure that
you use concentrators to connect stations together, that save you
a lot of time in debugging the fddi rings.  ;-)

-- Mike

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 08:18:41 GMT
From:      chan@aim1.UUCP (Neville Chamberlain)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SUMMARY: Novell and Clarkson co-exist

MANY thanks to all the folks who replied so promptly to my question.  
It seems that the question should belong in some FAQ, but as there 
were a number of requests for more info if I got it, I have decided 
to post a summary.  (Just counted; replies totalled in excess 
of 1000 lines!)

The original question was something like:

   >vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
   >We have a number of PC's and Unix boxes connected via Ethernet and
   >TCP-IP using the Clarkson packet drivers and NCSA Telnet and FTP.
   >We have added a Novell file server onto the backbone, but do not seem
   >able to get reliable access to both the Unix systems and the Novell
   >server at the same time.
   >
   >The setup looks as follows:
   >
   >  ------+-------+-------+------+----+---------------- Ethernet
   >        |       |       |      |    |
   >	    PC    Novell   Unix    PC   PC  ...
   >
   >What I want to do is to load IPX and NET3, log on to the Novell 
   >server, and then still be able to run Telnet and FTP.  We have
   >had limited success doing this; depending on the order in which
   >the different programs are loaded various one fail.
   >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In our setup, we tried to load the packet Clarkson packet drivers (we are
using WD8003e cards), then IPX, and then NET3 (we are running Novell 2.15).
The cause of the problem (of course) is that both the Clarkson packet
driver and IPX think that they own the card, and they end up fighting
for control.  The solution is to use a version of IPX that will talk to
the packet driver instead of trying to take control of the card.  Such
a version was developed by Brigham Young University, and is called IPXBYU.

My (working) setup now loads the drivers as follows:

   WD8003E -n 0x61 2 0x2A0 0xD000
   IPXBYU
   NET3

followed by the Novell login commands, etc.  This setup allows me to log
on to the Novell file server, telnet to my Unix server, and happily 
ftp files between all three machines.  As far as the Unix machine is
concerned, my drives P, Q, etc are just local to my machine...

The -n option on the WD8003e load line lets the packet driver send 
Novell ethernet packets to the Novell file servers and "standard" 
ethernet packets to other hosts.

IPXBYU can be obtained from sun.soe.clarkson.edu; get a file called
/pub/novell/novell.exe.uu by anonymous ftp from sun.soe.clarkson.edu.
The Clarkson drivers are also available at this site (drivers.zip).
Apparently NOVELL.EXE contains full instructions on creating an 
IPXBYU for your machines; I can not FTP from here, but the binary 
versions of IPXBYU that I got work just fine.

Again, many thanks to all who replied.
-- 
.............................................................
Neville Chamberlain                   :Tel: +27 (21) 419-2690      
Aztec Information Management          :Fax: +27 (21) 21-1040
chan@aim1.UUCP

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 09:32:44 GMT
From:      sra@idx.com
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Help with SLIP on PC/Windows 3.0!

I'm trying to verify reliability of
  ftp's slip (actually slp16550 & slpdrv - a FIFO uart!) under
    ms windows 3.00a under
      qemm 5.12
  connected to
    multinet static slip under
      vms 5.4-3
  at 4800 baud direct connect.

I can't get this beast to work reliably.  Sometimes it works and (most) of the
time, it locks up.  I'm try to run (in two windows), a simple task-to-task
routine and one telnet session.  In the telnet session, I'm simply doing a
directory command or a type/page.  The telnet session freezes in the middle.
After that, even ping gets a timeout.  I can exit the telnet session and
windows continues but the slip line is lost!  Only rebooting the PC helps.

I've set up a PIF to give extra memory to the telnet session, emulate text,
etc.  I'm only trying 4800 'cuz 9600 was just as bad.

Anybody had experience?  Got any ideas?  thanks... steve

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

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 10:09:10 GMT
From:      martillo@clearpoint.com (Martillo)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,talk.politics.misc
Subject:   Re: Revolution (was Re: Alternate NICs)

In article <GRITTON.91Oct26152810@altar.ee.byu.edu>, gritton@altar.ee.byu.edu (Jamie Gritton) writes:
: In article <1991Oct26.014100.27160@decuac.dec.com> mjr@hussar.dco.dec.com
: (Marcus J. Ranum) writes:
: : michael@resonex.uucp (Michael Bryan) writes:
: ::(Actually there is some amount of seriousness in the above... Is the
: ::idea of a commercially or privately run NIC (hopefully more responsive
: ::than GSI) totally unreasonable?)
: :Maybe if we all got down on our knees and begged uunet?
 
:    This seems actually a very serious subject. A long time ago (way before
: my time), the internet used to be ARPA. Now it isn't. We need to keep up
: with changing times.
 
:    The internet is not the U.S. government. In fact, it isn't U.S. anything.
: The time has come to get away from U.S. government control. Were I not an
: American myself I would feel even worse about them telling me what to do.
:    There are other people out there acting as root nameservers. One of them
: could pick up the responsibility of being the master server. UUNET, or some
: other commercial network service provider could do an excellent job. Of course
: they would charge for this service, but isn't it worth it?
:    A worldwide Internet not directly affiliated with any government bodies
: could come up with the resources to have someone do such duties as a root
: nameserver, an RFC depository/mediator, and hostmaster, and an assigned
: number authority.
 
:    Now comes the hard part: The U.S. government will not want to give up its
: position of power in the internet. This is the reason for the new subject.
: Whatever network service provider that did these things would have to really
: stick its neck out with those of us who side with them for our independence.
: The time has come to act!
 
:    I doubt that anyone such as UUNET would go for such a dangerous position.
: But something should be done. Or at least this should be food for thought.
: This could use an extra disclaimer: my views are certainly my own. Brigham
: Young University is not advicating this move, I'm sure. Don't sue them; don't
: take away their government contracts. This is just personal opinion.
 
:    Think about it.

Directly or indirectly the U.S.  government is probably the largest
internet product consumer and is probably the only internet product
consumer capable of looking out for consumer interests.  Eliminate U.S. 
government influence over the internet, and the internet will become
dominated by a cartel of manufacturers and network services providers. 
Ever hear of OPEC? That is a cartel dominated by producers and compliant
distributers.  The creation of a similar cartel in computer networking
is a bad idea.  Already, manufacturer dominated IETF working groups are
standardizing protocols in such a way as to hinder the introduction of
less expensive higher performance products which compete with the
existing product lines of manufacturers who would prefer to reap profit
without the need for innovation. 

Now this situation could indicate simply a lack of understanding of
newer technologies or it could indicate darker purposes of crushing new
and more creative competition.  In either case, elimination of US
government influence at this point could have grave consequences. 

: James Gritton - gritton@ee.byu.edu - I disclaim

Joachim Carlo Santos Martillo Ajami
-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 10:34:10 GMT
From:      philip@vogon.cetia.fr (Philip Peake)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Abysmal GSI/NIC service, WAS: Re: Updating root info.

In article <RIKITAKE.91Oct28153241@jrdzzz.jrd.dec.com>, rikitake@jrd.dec.com (Kenji J. Rikitake) writes:
|> 
|> I can't help following-up to this article: Internet users in Japan are
|> currently suffering from serious inconvenience due to lack of
|> approval in in-addr.arpa zone. (Sorry if I am using a wrong
|> terminology)
|> 
|> In article <1991Oct23.164446.11899@netlabs.com> jon@netlabs.com (Jonathan Biggar) writes:
|> 
|> >   This is causing some difficulties, because there
|> >   are a number of ftp servers that do not allow connections from machines
|> >   that are not registered in the DNS.

Add (at least) one French domain to the un-happy list.
We are awaiting our in-addr.arpa records to be added to the root nameservers,
and suffering the same problems as noted above - not only that, there
is at least one site which bounces SMTP connections when he can't do
a reverse lookup.

Philip

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 12:27:27 GMT
From:      birchall@pilot.njin.net (Shag)
To:        comp.protocols.tcp-ip,talk.politics.misc
Subject:   Re: Revolution (was Re: Alternate NICs)

Why do we have to worry about who's controlling what?  It shouldn't be too
terribly difficult for each subnet to have its own NIC... With the X.500 stuff
coming through, information on users and domains (a big chunk of the NICs)
will be pretty commonplace anyway.  I mean, NIC doesn't give you a whole lot
more than you can get through host, nslookup, and finger, leastwise it never
did for me....

						-shag
-- 
+----------------------------------------------------------------------+
| Dan "Shag" Birchall, Official Random, NJ Intercampus Network.        +-+
| The NJ Intercampus Network is not responsible for me.  They're glad. | |
| For further disclaimers, contact information, and lyrics, finger me. | |
+-+--------------------------------------------------------------------+ |
  +----------------------------------------------------------------------+

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 13:37:39 GMT
From:      barrett@daisy.ee.und.ac.za (Alan P Barrett)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   SMTP HELO verification

In article <1991Oct28.103410.24760@cetia.fr>,
philip@vogon.cetia.fr (Philip Peake) writes:
> We are awaiting our in-addr.arpa records to be added to the root
> nameservers, and suffering the same problems as noted above - not only
> that, there is at least one site which bounces SMTP connections when
> he can't do a reverse lookup.

Tell him about RFC1123 section 5.2.5:

	 However, the receiver MUST NOT refuse to accept a message, even
	 if the sender's HELO command fails verification.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 16:18:38 GMT
From:      martillo@clearpoint.com (Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: InterOp Debate (response to trip report by Joachim Martillo)

In article <9110231924.AA15261@enet-gw.pa.dec.com>, callon@bigfut.enet.dec.com writes:

> I would agree that X.25 (OSI Connection-oriented traffic)
> should be handled independently from CLNP and IP traffic for
> the reason that you stated -- particularly, that X.25 traffic
> requires very different handling (reliable delivery, strict
> flow control, etc). 
 
> In terms of "OSI pakets at corresponding layers always carry
> the same sorts of information...". For both IP and OSI CLNP,
> the routing is done on the basis of a destination address
> (and optionally TOS information) contained in the network
> layer header. 

Perhaps, I misunderstood but the whole SSAP/DSAP formalism which appears
throughout the OSI formalism tends to hide from lower protocol layers
exactly what sort of upper layer protocol packets they are carrying
especially because SAPs at a given protocol layer can be local to each
network within a catenet.  The last time I went to an ISO OSI talk,
people were really hyped on the late binding of SAP pairs which seemed
to imply dynamic allocation as well as late-binding.  In contrast, IP
packets containing UDP packets invariably have the type field set to UDP
during the whole voyage from source host to destination host within the
DARPA Internet.  IP routers can always know exactly what sort of data is
being routed.  IS's don't necessarily have the ability to obtain this
information. 

> However, neither approach allows for routing based on anything
> other than destination address and type of service. 

Not true.  A developer could build an IP or OSI router to route on the
basis of the phases of the moon if he so desired.  Now such a router
might not be terribly useful, but an IP router could be built which
learned lots of information about the packets on a connection specified
by source IP address, port, type and destination IP address, port, type. 
As the router learned such information, the router could make different
routing choices. 

Now no one has built such a router, but only because building such a
router is hard not because building such a router is impossible, nor is
there any theoretical reason to assert such a router would perform
badly.  In fact, such a router might actually improve network
performance.  A similar problem exists in disk subsystems and some disk
subsystems have been built which use heterogeneous caching strategies to
improve file system performance over a range of applications. 

>                                                      Thus, for
> example, your comment about "large IP packets which contain UDP
> messages may optimally follow different routes than small IP
> packets which contain TCP messages" again is not a difference
> between the two approaches: If you use a different TOS for the 
> two approaches, then each approach handles this. If, on the other
> hand, you want to route according to packet length, then neither
> approach will allow this (neither IS-IS nor OSPF considers packet
> length in routing -- the old "fuzzballs" which were used in Dave
> Mill's NSFNET backbone allowed some provision for packet length,
> but this did not work particularly well and has not been adopted
> by any other routing protocol that I am aware of).

Actually, in discussing heterogeous routing strategies, I did not mean
to limit myself to existent routers.  When I mentioned large UDP
packets, I meant to suggest NFS packets.  Everything else being equal,
NFS performance does improve when NFS packets are routed through
networks with large enough maximum transmit unit size that fragmentation
can decrease. 

If cost is a factor, the nature of NFS packet loss recovery strategy can
make a lower cost network actually more costly to use than a higher cost
network.  Such behavior is not limited to NFS. 

As for TOS, TOS approaches are to some extent useful, but they run into
the omniscience problem.  Unless you know for all time exactly when a
protocol is defined what types of service are necessary, you will
eventually find that eventually some traffic needs to specify and
undefined type of service in order to be routed most efficiently. 
Intelligent knowledgeable routers with packet smarts could be a useful
adjunct to TOS strategies. 

> Ross

Joachim Carlo Santos Martillo Ajami




-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 17:06:22 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

In article <1991Oct21.185439.6938@kronos.com> richb@kronos.com (Rich Braun) writes:
>berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>But, if you want the answer for an Ethernet-based LAN, between two
>systems on the same physical medium, and you don't want fragmentation
>to happen, remember that the maximum-sized Ethernet packet is 1536 bytes.
>A UDP header is 8 bytes, an IP header is 20 bytes, an Ethernet header
>is 18 bytes, and the trailing checksum is 2 bytes.  My calculation
>therefore yields 1488 bytes for data in a non-fragmented UDP packet.
>
>Am I off by a few bytes?

A few.

The Information field of an Ethernet packet is only 1500 bytes, so your
numbers are a bit high (really 1472 bytes of UDP data).  And the Ethernet
FCS is actually 4 bytes.

>-rich

Art

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 17:44:37 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: SMTP HELO verification

Alan P Barrett <barrett@daisy.ee.und.ac.za> writes:
:
:   In article <1991Oct28.103410.24760@cetia.fr>,
:   philip@vogon.cetia.fr (Philip Peake) writes:
:   > We are awaiting our in-addr.arpa records to be added to the root
:   > nameservers, and suffering the same problems as noted above - not only
:   > that, there is at least one site which bounces SMTP connections when
:   > he can't do a reverse lookup.
:
:   Tell him about RFC1123 section 5.2.5:
:
:	     However, the receiver MUST NOT refuse to accept a message, even
:	     if the sender's HELO command fails verification.

To quote a little more from that paragraph:

         The HELO receiver MAY verify that the HELO parameter really
         corresponds to the IP address of the sender.  However, the
         receiver MUST NOT refuse to accept a message, even if the
         sender's HELO command fails verification.

We're talking about mapping from domain name to IP address, which is
an application layer verification procedure.

The "bounced SMTP connection" stems from a dubious session layer
verification procedure which entails ensuring that it can map the
incoming IP address to a domain name.  (I.e. the reverse of the HELO
verification.)

With FTP, I can understand that some would like to know who they're
talking to, and having a reverse mapping is an indication that the
client is not totally fake.  However, SMTP doesn't really need this
low-level verification, since it has a higher-level verification
procedure.

I would consider it harmful to basic electronic mail service to engage
in any verification (with possible rejection) at all.  A comment to
the same effect that we recommended later in the same sub-sub-clause,
could be useful:

         IMPLEMENTATION:
              When HELO parameter validation fails, a suggested
              procedure is to insert a note about the unknown
              authenticity of the sender into the message header (e.g.,
              in the "Received:"  line).

</Erik>

--
Erik Naggum              ISO/IEC JTC 1/SC 18/WG 8             +47-2-836-863
Naggum Software             SGML, HyTime, SMDL             <erik@naggum.no>
0118 OSLO, NORWAY        Vice Chair, SGML SIGhyper        <enag@ifi.uio.no>
ISO 646,2022,2108,6429,6937,8613,8859,8879,9070,9899,9945,10646,10743,10744

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 17:48:13 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <8175@emory.mathcs.emory.edu>, km@mathcs.emory.edu (Ken Mandelberg) writes:
|>
|>How do FDDI concentrators handle traffic between two of its directly
|>connected (single attach) ports? Is there some kind of filtering or
|>does all traffic sent on one port show up on all other ports?
|>
|>What do prices per/port look like right now and say 6-12 months out.
|>
|>
|>-- 
|>Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
|>Emory University    | {rutgers,gatech}!emory!km    UUCP 
|>Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
|>Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611
|>
An FDDI concentrator is a multi-port repeater; whatever goes into one port
comes out the others.  It's bit for bit transparent except for re-timing
which may cause the inter-packet gaps to change slightly.

	paul

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 19:14:01 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: SMTP HELO verification

In article <ENAG.91Oct28184437@gyda.ifi.uio.no> enag@ifi.uio.no (Erik
Naggum) writes: 
>However, SMTP doesn't really need this
>low-level verification, since it has a higher-level verification
>procedure.

What would that be?  SMTP has nothing built into it to ensure that the
mail you are getting is indeed from the person who it claims to have
sent it.  There needs to be, at the present time, some checks on the
lower layers to make sure that you can trace the mail back through the
network, should the need arise.

However, I agree that mail should NEVER be bounced because the reverse
lookup failed.  EVER!  At most the mail should have something stuffed
into the Received lines, or possibly an additional header added like
"Comment: This mail looks forged to me." but even that is going too
far.

Reverse lookup doesn't even solve the problem of untraceable mail.  It
is still fairly easy to send untracable mail on the internet today.
There are enough sites running older versions of sendmail (or are
running programs that aren't even based on sendmail at all) that don't
put where the connection really came from in the Received lines.  As
long as these guys exist on the ineternet, anybody can forge
untraceable mail.

While it is desirable to make make more secure, this new security
shouldn't EVER cause mail to not be delivered.  After all, the post
office will deliver any mail that it gets.  It is up the the recipient
to verify that it wasn't forged or otherwise fabricated.

Warner

-- 
Warner Losh		imp@Solbourne.COM	  MMP to DoD #882
"Red hair is caused by sugar and lust," the woman, who was blond, confided.
"Highly evolved beings do not indulge in sugar and lust." -- Tom Robbins

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 21:14:21 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Revolution (was Re: Alternate NICs)

lyndon@aupair.cs.athabascau.ca (Lyndon Nerenberg) writes:
>UUNET's fees to date have been very reasonable
>for their current services.

Not clear to me.  UUNET was originally founded as a non-profit offshoot of
USENIX, but it's unaffiliated now and operates with a profit motive (this
is the information I have).

And I do know that our company's 30 hours of UUCP connect time per month
would cost about $200 at UUNET's "reasonable" rates vs. the $40 we pay
through an independent service.  A full newsfeed via UUNET's UUCP service
would cost more than we'd pay for an online Internet connection (which
would offer far more than mere netnews).

-rich

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 21:29:34 GMT
From:      rmilner@zia.aoc.nrao.edu (Ruth Milner)
To:        comp.protocols.tcp-ip
Subject:   Re: GSI and the NIC

In article <1991Oct23.184918.18999@ux1.cso.uiuc.edu> randy@ux1.cso.uiuc.edu (Randall E. Cotton) writes:
>
>It seems that they didn't forsee the ammount of traffic
>and there is a network link somewhere ... that is being ridiculously 
>overloaded. I asked what the speed
>of this overloaded link was and they said "You don't want to know".

Given how long SRI had been running the NIC, and how much statistical 
information they had about traffic and traffic patterns, there is *no excuse* 
for the new management not knowing what to expect. Looks like they just didn't 
do their homework.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                  Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 21:32:41 GMT
From:      rikitake@jrd.dec.com (Kenji J. Rikitake)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Abysmal GSI/NIC service, WAS: Re: Updating root info.


I can't help following-up to this article: Internet users in Japan are
currently suffering from serious inconvenience due to lack of
approval in in-addr.arpa zone. (Sorry if I am using a wrong
terminology)

In article <1991Oct23.164446.11899@netlabs.com> jon@netlabs.com (Jonathan Biggar) writes:

>   This is causing some difficulties, because there
>   are a number of ftp servers that do not allow connections from machines
>   that are not registered in the DNS.

From Japan only 3 networks have in-addr.arpa domains approved:
wide.ad.jp, tisn.ad.jp, and sra.co.jp.

When I try to perform anonymous ftp from my u-tokyo.ac.jp account to
uunet.uu.net, they just kick me out. :-< :-<

>   What gives?

I wish I knew.

-- Kenji
--
Kenji Rikitake // kenji@macrofield.org // kenji@komaba.c.u-tokyo.ac.jp
VMS/Japanese Development engineer, DEC Japan R&D Center // rikitake@jrd.dec.com

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 22:25:40 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: SMTP HELO verification

Warner Losh <imp@solbourne.com> writes:
:
:   In article <ENAG.91Oct28184437@gyda.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: 
:   >However, SMTP doesn't really need this
:   >low-level verification, since it has a higher-level verification
:   >procedure.
:
:   What would that be?

See RFC 1123 5.2.5, quoted in my message.  An SMTP server may want to
make an attempt to "verify" that the domain name given as the HELO
parameter (1) exists (it's required to be a domain name with an A
record), (2) is the peer it's talking to.  However, since it's not
allowed to do anything but put "(not authenticated)" or somesuch
comment in the Received line, it's rather useless.  See below.

:   SMTP has nothing built into it to ensure that the mail you are
:   getting is indeed from the person who it claims to have sent it.

This is a different level of authentication and verification
altogether.  We were talking about verifying _hosts_ not users.
Please don't confuse things more than necessary.

:   There needs to be, at the present time, some checks on the lower
:   layers to make sure that you can trace the mail back through the
:   network, should the need arise.

RFC 1123 already specifies this.  (Have you been paying proper
attention to RFC 1123?)

      5.2.8  DATA Command: RFC-821 Section 4.1.1

         Every receiver-SMTP (not just one that "accepts a message for
         relaying or for final delivery" [SMTP:1]) MUST insert a
         "Received:" line at the beginning of a message.  In this line,
         called a "time stamp line" in RFC-821:

         *    The FROM field SHOULD contain both (1) the name of the
              source host as presented in the HELO command and (2) a
              domain literal containing the IP address of the source,
              determined from the TCP connection.

	 [ ... ]

This suffices for the task of tracing mail back through the network.

:   However, I agree that mail should NEVER be bounced because the reverse
:   lookup failed.  EVER!  At most the mail should have something stuffed
:   into the Received lines, or possibly an additional header added like
:   "Comment: This mail looks forged to me." but even that is going too
:   far.

Yes, we agree on this, already.

:   Reverse lookup doesn't even solve the problem of untraceable mail.  It
:   is still fairly easy to send untracable mail on the internet today.
:   There are enough sites running older versions of sendmail (or are
:   running programs that aren't even based on sendmail at all) that don't
:   put where the connection really came from in the Received lines.  As
:   long as these guys exist on the ineternet, anybody can forge
:   untraceable mail.
:
:   While it is desirable to make make more secure, this new security
:   shouldn't EVER cause mail to not be delivered.  After all, the post
:   office will deliver any mail that it gets.  It is up the the recipient
:   to verify that it wasn't forged or otherwise fabricated.

Good, so we agree on the necessity to do the verification and
rejection at the UA side, not at the MTA side.

</Erik>

--
Erik Naggum              ISO/IEC JTC 1/SC 18/WG 8             +47-2-836-863
Naggum Software             SGML, HyTime, SMDL             <erik@naggum.no>
0118 OSLO, NORWAY        Vice Chair, SGML SIGhyper        <enag@ifi.uio.no>
ISO 646,2022,2108,6429,6937,8613,8859,8879,9070,9899,9945,10646,10743,10744

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 22:27:28 GMT
From:      birchall@pilot.njin.net (Shag)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: SMTP HELO verification

Warner writes:
>However, I agree that mail should NEVER be bounced because the reverse
>lookup failed.  EVER!  At most the mail should have something stuffed
>into the Received lines, or possibly an additional header added like
>"Comment: This mail looks forged to me." but even that is going too
>far.

I've seen a lot of mail delivered (and caused a lot of mail to be delivered,
by playing with port 25 on random machines when the link to my account is
down) with fields like
	Apparently-from: root@shagnet.shag.net
	Probably-from: whitman.rutgers.edu
[In this case, Whitman is a dialin server that I use].  It would appear that
at least _some_ (if not most) mail thingies look at the HELO and either say,
"I know that {machine|domain}, it's okay" or "I don't know that name, but I'll
stick it in... just to be on the safe side, though, I'd better stick in the
name of the machine this connection is originating from."  Where they get the
connect info I don't know... netstat or something internal that approximates
it, mebbe?  [@set me=non-technical!]

					-shag
-- 
+----------------------------------------------------------------------+
| Dan "Shag" Birchall, Official Random, NJ Intercampus Network.        +-+
| The NJ Intercampus Network is not responsible for me.  They're glad. | |
| For further disclaimers, contact information, and lyrics, finger me. | |
+-+--------------------------------------------------------------------+ |
  +----------------------------------------------------------------------+

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 23:27:33 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <1991Oct27.233543.28653@berlioz.nsc.com>, my@laverde.nsc.com (Michael Yip) writes:
> ...
> By the way, if you are designing a FDDI network, make sure that
> you use concentrators to connect stations together, that save you
> a lot of time in debugging the fddi rings.  ;-)

Everything else in this article was clear and accurate.  Unfortunately,
that last statement is not exactly true.

Many people claim concentrators somehow filter bad packets or data from
unreliable or broken hosts.  That is false.  The nastiness of a bad station
goes everywhere.  A station that trashes the token does so without the let
or hindrence of any concentrators.  The only host debugging that
concentrators help is in CMT problems.  Significant CMT incompatibilities
have been rare for two years in the big, multi-vendor test/show (which none
of the participants can talk about, lest the sponsor of the show needs
another example of the consequences of loose lips).

FDDI concentrators have many of the same characteristics as ethernet hubs:
    Both can make it easier and quicker to shake down a big network.
    Both are significantly more expensive than simply hooking hosts together.
	(FDDI concentrators increase the number of PHY's in the ring by
	at least 1/concentator, but decrease the number of optical bypasses,
	if you choose to have bypasses.)
    Both have many people who have decided that the way to make money is to
    	sell FUD to MIS and IS departments.
    Both can and do break and cause problems to the rest of the network.
	FDDI concentrators are worse in this regard, because the hassles of
	FDDI and especially SMT make concentrators necessarily smarter and
	more complicated than many ethernet hubs.
    Both are unjustifiable in labs or machine rooms, where you have complete
	control and knowledge over what is or is not connected, where
	adding yet another computer and its network connections reduces the
	reliability of the whole system.

FDDI concentrators have two additional advantages:
    Concentrators are required for "single-attachment" stations.  If you
	have SAS hosts, then you have either only 2 computers or you have
	concentrators.

    Concentrators make partitioning of big rings less likely, if you
	assume that they have uninterruptible power supplies, are safe from
	tampering, and are otherwise less likely to die than stations.

FDDI concentrators have one particular disadvantage:
    Concentrators eliminate the potential speed advantage of Dual-MAC
	stations.   (It is not unreasonable, illegal, non-standard, or
	fattening to hope get more than the about 85Mbit/sec that is the
	maximum for a single-MAC station.)


Vernon Schryver,  vjs@sgi.com

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 91 23:49:43 GMT
From:      v026202a@stc-cards.cte.stortek.com (Hal Swanson)
To:        comp.protocols.tcp-ip
Subject:   EXOS migration

We have EXOS LAN service for VMS running with a EXOS 204 card.  I know both
the hardware and software are no longer supported.  There are several
application servers running on the VAX linked with SRVMAIN and XSRVINIT
collecting data from clients also running EXOS hardware and software via
sockets.  I need equivalents for SRVMAIN and XSRVINIT which will run on
either MULTINET or WIN/TCP.  I'd like to hear from someone having previously
done this, or find source equivalents for the two EXOS modules referenced.

Any response gladly welcomed.
-- 
Hal Swanson -  StorageTek (OIS Systems Support Group)
Internet: Hal_Swanson@Stortek.Com
USmail:	StorageTek / Louisville, CO / 80028-8110
Phone:	(303) 673-6063

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 01:25:53 GMT
From:      PETER@psychnet.psychol.utas.edu.au (Peter R. Tattam)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver

I have some suggestions which might aid the use of multiple stacks for the 
same ethernet type.

Firstly, when a packet is received, it must be scanned for the packet type, 
so that the packet most likely available for use.

Why not pass that info to the upcall processing the packet on the initial 
phase.  The receiver can process the packet temporarily and decide whether 
to keep it or to pass it on to another stack.  If it doesn't want it, it can 
pass a nil pointer similar to when it doesn't have space for it.

All that is required is for the packet driver to extended it's tables 
somewhat, and for the receiver call to add a little more info (most likely 
the info is available in registers already).

This extended capability could be advertised in the same ways as other 
extended features, thus maintaining functionality.  (It could even be an 
additional interrupt function call).

Has this been thought of before, or have I missed something in the packet 
driver spec. Sorry to any others who have thought of it.

This feature might also allow the elimination of TCP protocol managers when 
running windows or other multi-tasking environments.


Any thoughts?


Peter
----------------------------------------------------------------------------
P.Tattam                                    International Phone 61-02-202346
Programmer, Psychology Department           Australia     Phone   002-202346
University of Tasmania, Hobart, Tasmania, Australia
----------------------------------------------------------------------------

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 03:25:31 GMT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver

In article <PETER.85@psychnet.psychol.utas.edu.au>, PETER@psychnet.psychol.utas.edu.au (Peter R. Tattam) writes:
> I have some suggestions which might aid the use of multiple stacks for the 
> same ethernet type.
> 
> Firstly, when a packet is received, it must be scanned for the packet type, 
> so that the packet most likely available for use.
> 
> Why not pass that info to the upcall processing the packet on the initial 
> phase.  The receiver can process the packet temporarily and decide whether 
> to keep it or to pass it on to another stack.  If it doesn't want it, it can 
> pass a nil pointer similar to when it doesn't have space for it.
> 
> All that is required is for the packet driver to extended it's tables 
> somewhat, and for the receiver call to add a little more info (most likely 
> the info is available in registers already).
> 
> This extended capability could be advertised in the same ways as other 
> extended features, thus maintaining functionality.  (It could even be an 
> additional interrupt function call).
> 
> Has this been thought of before, or have I missed something in the packet 
> driver spec. Sorry to any others who have thought of it.
> 
> This feature might also allow the elimination of TCP protocol managers when 
> running windows or other multi-tasking environments.
> 
> 
> Any thoughts?
> 
> 
> Peter
> ----------------------------------------------------------------------------
> P.Tattam                                    International Phone 61-02-202346
> Programmer, Psychology Department           Australia     Phone   002-202346
> University of Tasmania, Hobart, Tasmania, Australia
> ----------------------------------------------------------------------------
Peter,
	Yes indeed. The draft of the next Packet Driver Spec has a
provision for look/peek-ahead. It can cost a little performance but that's
nothing compared to the gained advantages. NDIS does the same, only matters
get pretty complicated quickly with NDIS. A fully working look-ahead scheme
is a polling one rather than a dispatch-on-value one. That is, two bytes of
TYPE field are insufficient when dealing with say 802.3 SNAP (ok, it's a LEN
field in that case) so we don't know in advance which stack wants the packet.
NDIS uses the polling method. Whatever the method, the inspection has to be
very fast because it is occuring at interrupt level with goodness knows what
else happening. That means TCP won't get a chance to think about it, and that
lets out running multiple protocol stacks of too-similar a nature. Both NDIS
and ODI provide buffer space to stash packets, as expensive as that is, but
Packet Drivers do not so the pkt acceptance decision process needs to be a 
clean quick one with no returns. Also, the pkt receiver is called at interrupt
level from the Packet Driver and the mainline protocol code is too long a
path (and too messy to reenter) for it to have a thoughtful consideration of
many bytes.
	You can easily (he says) play with these concepts by writing an
intermediary program accepting packets from the PD and offering them polling 
style to protocol stacks. The other step is locating protocol stacks willing
to play that game.
	Joe D.

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 07:58:54 GMT
From:      PETER@psychnet.psychol.utas.edu.au (Peter R. Tattam)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver

In article <1991Oct28.212531.50136@cc.usu.edu> jrd@cc.usu.edu (Joe R. Doupnik) writes:
>Peter,
>       Yes indeed. The draft of the next Packet Driver Spec has a
>provision for look/peek-ahead. It can cost a little performance but that's
>nothing compared to the gained advantages. NDIS does the same, only matters
>get pretty complicated quickly with NDIS. A fully working look-ahead scheme
>is a polling one rather than a dispatch-on-value one. That is, two bytes of
>TYPE field are insufficient when dealing with say 802.3 SNAP (ok, it's a LEN
>field in that case) so we don't know in advance which stack wants the packet.
>NDIS uses the polling method. Whatever the method, the inspection has to be
>very fast because it is occuring at interrupt level with goodness knows what
>else happening. That means TCP won't get a chance to think about it, and that
>lets out running multiple protocol stacks of too-similar a nature. Both NDIS
>and ODI provide buffer space to stash packets, as expensive as that is, but
>Packet Drivers do not so the pkt acceptance decision process needs to be a 
>clean quick one with no returns. Also, the pkt receiver is called at interrupt
>level from the Packet Driver and the mainline protocol code is too long a
>path (and too messy to reenter) for it to have a thoughtful consideration of
>many bytes.
>       You can easily (he says) play with these concepts by writing an
>intermediary program accepting packets from the PD and offering them polling 
>style to protocol stacks. The other step is locating protocol stacks willing
>to play that game.
>       Joe D.

Ok.  I thought about the fact that you may not have enough time to process 
the packet at interrupt level.  The problem is where to put the data, and 
how long that data needs to live.

There would appear to be two solutions, both with pros and cons.

1.  Put some packet bufferring in the driver.  This should be done at 
installation time because the memory needs to be shared among different 
programs.  Unfortunately this uses premium memory so may defeat the purpose.

2.  When a packet arrives, the first program provides a buffer for it, and 
processing continues as normal.  On the second call, the program can see if 
it still wants the packet.  This need not occur at interrupt level. If the 
program does not want it, the packet driver can simply pass it on to further 
recievers.  In this case, a call is made to the next ethertype receiver 
which provides a packet to copy it into. The end result is that the packet 
will be copied from buffer to buffer until it is accepted or discarded 
completely. The disadvantage with this method is that the packet will be 
repeatedly copied.  This however need not occur at interrupt level, but at 
some intermediate level.  The packet driver need only stay at interrupt 
level when a packet is immediately received.  Once the initial buffer has 
been received, the processor could fork into another task to perform the 
next set of tests.  This forked process would have the job of dispatching 
any packets for processing, and stay in existence until there are none left 
to process. The only extra memory required is some flag for each receiver 
hook to say that it is ready to fork (maybe this could be an extension of an 
already existing state variable), and either an extra stack for the fork 
process, or doubling the size of the normal interrupt stack.

This is in line with the existing philosophy of the packet driver.  The only 
overhead is that of copying the packet more than once. This should not be a 
problem for a serious program.

What do you think?


Peter
----------------------------------------------------------------------------
P.Tattam                                    International Phone 61-02-202346
Programmer, Psychology Department           Australia     Phone   002-202346
University of Tasmania, Hobart, Tasmania, Australia
----------------------------------------------------------------------------

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 14:24:29 GMT
From:      ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun BOS Software)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP, portable maximum packet size.

>But, if you want the answer for an Ethernet-based LAN, between two
>systems on the same physical medium, and you don't want fragmentation
>to happen, remember that the maximum-sized Ethernet packet is 1536 bytes.
>A UDP header is 8 bytes, an IP header is 20 bytes, an Ethernet header
>is 18 bytes, and the trailing checksum is 2 bytes.  My calculation
>therefore yields 1488 bytes for data in a non-fragmented UDP packet.

Close...

The total time from the start of one Ethernet frame to the start of the
next is a minimum of ~1538 byte times.  This includes 12 byte times of
interframe spacing and 8 byte times of preamble along with the actual
frame size of 1518 bytes.

Of that 1518 bytes, 4 are FCS, leaving 1514.  Another 6 are destination
Ethernet address, 6 are source Ethernet address, and 2 are type,
leaving 1500 bytes for user data in each frame.  (This assumes you're
using the DIX Ethernet Version II frame format.  If instead you're
using IEEE 802.3 frame format, the 2 byte "type" field becomes the
"length" field and an additional 5 bytes are consumed by the "SNAP"
header.)

Of that 1500 bytes, at least 20 go to an IP header, and 8 go to the UDP
header, leaving a maximum 1472 bytes of application data in each
frame.  (If the IP header includes "options", it will be larger and the
space for application data will be smaller.  Also some of the
"application" data may be an RPC header.)
---
chuck kollars <ckollars@East.Sun.COM>		(located in Boston)
Systems and Network Administration Group (SNAG)

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 15:44:15 GMT
From:      RXR300G%ODUVM.BITNET@ncsuvm.cc.ncsu.edu
To:        comp.protocols.tcp-ip
Subject:   repost of tcp-ip question

I am reposting this request since I did not get more than one response.
probably it is because I did not mention my internet email address.
my question follows:
   when an application program calls connect system call how does it call
tcp_usrreq.c. connect code has SYSCALL(connect) and SYCALL is macro written
in assembly like code. I would appreciate it if
any one can clearly explain how tcp is called by the socket layer
my email is radha_s@cs.odu.edu
thanks very much ,

-Ramesh.





email : ra

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 16:32:13 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: Revolution (was Re: Alternate NICs)

In article <1991Oct28.211421.5569@kronos.com> richb@kronos.com (Rich Braun) writes:
>lyndon@aupair.cs.athabascau.ca (Lyndon Nerenberg) writes:
>>UUNET's fees to date have been very reasonable
>>for their current services.
 
> [ ... ]
 
>And I do know that our company's 30 hours of UUCP connect time per month
>would cost about $200 at UUNET's "reasonable" rates vs. the $40 we pay
>through an independent service.  A full newsfeed via UUNET's UUCP service
>would cost more than we'd pay for an online Internet connection (which
>would offer far more than mere netnews).

Where did you get these rates? We get about half of a full feed, which takes
70-80 hours/month, and average $200-$250 in charges, not including telephone
bills. 30 hours would be less than $120/month, not $200.

An online Internet connection has been quoted at under $1500; another
admin here in town said he couldn't locate service for under $2000. A full
feed from Uunet would run about $400-$500/month. Where in the heck are you
able to get an Internet link for that?

(Yes, I'd like a link a whole lot! And I could probably justify it at
that price range!)

-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
Become a pheresis donor. Loan your blood to the Red Cross for a couple
of hours. They, and cancer patients, will appreciate it.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 16:55:02 GMT
From:      KKEYTE@ESOC.BITNET (Karl Keyte)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   UDP/IP Question

I have a (probably simple) problem.  I'm trying to broadcast a UDP datagram
across our network.  Below is a piece of test code which I used.  It fails
at the 'sendto' with 'errno' set to 49 (Can't assign requested address).
Anyone any idea what's wrong?  Replies to me directly (KKEYTE@ESOC.BITNET)
would be appreciated.

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

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>





void main (void)
{
   int                        mode,
                              sock;
   struct sockaddr_in         destination,
                              sname;
   char                       buf[80];
   void                       err (char *);

   if ((sock = socket (AF_INET, SOCK_DGRAM, 0)) < 0)
      err ("!error creating socket");

   sname.sin_family = AF_INET;
   sname.sin_addr.s_addr = htonl (INADDR_ANY);
   sname.sin_port = htons (6543);

   if (bind (sock, (struct sockaddr *) &sname, sizeof (sname)) < 0)
      err ("!error binding name to socket");

   mode = 1;
   if (setsockopt (sock, SOL_SOCKET, SO_BROADCAST, (char *) &mode,
                   sizeof (mode)) < 0)
      err ("!error setting BROADCAST mode");

   destination.sin_family = AF_INET;
   destination.sin_addr.s_addr = htonl (INADDR_BROADCAST);
   destination.sin_port = 0;

   if (sendto (sock, buf, 80, 0, (struct sockaddr *) &destination,
               sizeof (destination)) < 0)
      err ("!error sending packet");
}





void err (char *s)
{
   int          reason;

   reason = errno;

   fprintf (stderr, "bro: %s", (*s=='!')? s+1 : s);

   if (errno)
      fprintf (stderr, " ([%d] %s)\n", reason, sys_errlist[reason]);
   else
      fprintf (stderr, "\n");

   if (*s=='!')
      exit (1);
}

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 16:57:52 GMT
From:      kudzu@tfs.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: Revolution (was Re: Alternate NICs)

In article <1991Oct28.211421.5569@kronos.com> richb@kronos.com (Rich Braun) writes:
>Not clear to me.  UUNET was originally founded as a non-profit offshoot of
>USENIX, but it's unaffiliated now and operates with a profit motive (this
>is the information I have).
>

UUNET is a not-for-profit corporation.  But that's okay, most other
netters are just as careful about the *facts* they post as you are.

-- 
Michael Sierchio                               TRW Financial Systems
                                                  1947 Center Street
kudzu@tfs.com                                Berkeley, CA 94704-1105
                                                        510.704.3380

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 18:03:10 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: SMTP HELO verification

In article <ENAG.91Oct28184437@gyda.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes:
>The "bounced SMTP connection" stems from a dubious session layer
>verification procedure which entails ensuring that it can map the
>incoming IP address to a domain name.  (I.e. the reverse of the HELO
>verification.)

No.  The bounced SMTP connections are caused, at least in the cases that
I had to investigate, by either MMDF or PMDF (I can't remember which one
right now) being configured to refuse to accept mail whose HELO parameter
didn't match the IP connection.  It has nothing at all to do with the
session layer.

In my first reply, I neglected to note this fact.  Other than that, it seems
that we're saying the same thing.

In another article, enag@ifi.uio.no writes:
>[[ HELO verification RFC quote removed ]]
>This suffices for the task of tracing mail back through the network.

Since the HELO verification is an option (since it says SHOULD in the RFC)
not all sites implement it.  So, if you want to send untraceable mail, send
it through a site that doesn't have this feature in their mailer software.
However, I'm finding it harder and harder to find sites that don't 
implement the HELO verification as time goes by.

Warner
-- 
Warner Losh		imp@Solbourne.COM	  MMP to DoD #882
"Red hair is caused by sugar and lust," the woman, who was blond, confided.
"Highly evolved beings do not indulge in sugar and lust." -- Tom Robbins

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 18:03:57 GMT
From:      jrd@cc.usu.edu (Joe R. Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver

In article <PETER.92@psychnet.psychol.utas.edu.au>, PETER@psychnet.psychol.utas.edu.au (Peter R. Tattam) writes:
> In article <1991Oct28.212531.50136@cc.usu.edu> jrd@cc.usu.edu (Joe R. Doupnik) writes:
>>Peter,
>>       Yes indeed. The draft of the next Packet Driver Spec has a
>>provision for look/peek-ahead. It can cost a little performance but that's
>>nothing compared to the gained advantages. NDIS does the same, only matters
>>get pretty complicated quickly with NDIS. A fully working look-ahead scheme
>>is a polling one rather than a dispatch-on-value one. That is, two bytes of
>>TYPE field are insufficient when dealing with say 802.3 SNAP (ok, it's a LEN
>>field in that case) so we don't know in advance which stack wants the packet.
>>NDIS uses the polling method. Whatever the method, the inspection has to be
>>very fast because it is occuring at interrupt level with goodness knows what
>>else happening. That means TCP won't get a chance to think about it, and that
>>lets out running multiple protocol stacks of too-similar a nature. Both NDIS
>>and ODI provide buffer space to stash packets, as expensive as that is, but
>>Packet Drivers do not so the pkt acceptance decision process needs to be a 
>>clean quick one with no returns. Also, the pkt receiver is called at interrupt
>>level from the Packet Driver and the mainline protocol code is too long a
>>path (and too messy to reenter) for it to have a thoughtful consideration of
>>many bytes.
>>       You can easily (he says) play with these concepts by writing an
>>intermediary program accepting packets from the PD and offering them polling 
>>style to protocol stacks. The other step is locating protocol stacks willing
>>to play that game.
>>       Joe D.
> 
> Ok.  I thought about the fact that you may not have enough time to process 
> the packet at interrupt level.  The problem is where to put the data, and 
> how long that data needs to live.
> 
> There would appear to be two solutions, both with pros and cons.
> 
> 1.  Put some packet bufferring in the driver.  This should be done at 
> installation time because the memory needs to be shared among different 
> programs.  Unfortunately this uses premium memory so may defeat the purpose.
> 
> 2.  When a packet arrives, the first program provides a buffer for it, and 
> processing continues as normal.  On the second call, the program can see if 
> it still wants the packet.  This need not occur at interrupt level. 

	Not really. The first PD call requests the address of a buffer and
the second call transfers the packet to the buffer. The called application
has no idea of what's in the packet until the second call completes. Further,
all this is at interrupt level (from the PD and board). There are tonnes of
packets arriving at the board so processing has to be very fast.

> If the 
> program does not want it, the packet driver can simply pass it on to further 
> recievers.  In this case, a call is made to the next ethertype receiver 
> which provides a packet to copy it into. The end result is that the packet 
> will be copied from buffer to buffer until it is accepted or discarded 
> completely. The disadvantage with this method is that the packet will be 
> repeatedly copied.  This however need not occur at interrupt level, but at 
> some intermediate level.  The packet driver need only stay at interrupt 
> level when a packet is immediately received.  Once the initial buffer has 
> been received, the processor could fork into another task to perform the 
> next set of tests. 

	This is DOS rather than Unix so forget forking and intermediate levels
and such. All the thread stuff has to be written by hand for the system under
consideration. One can't keep copying a packet from place to place without
running out of time. Meanwhile the Ethernet board still has the packet in
it's buffer and other packets are arriving etc. Not practical.

> This forked process would have the job of dispatching 
> any packets for processing, and stay in existence until there are none left 
> to process. The only extra memory required is some flag for each receiver 
> hook to say that it is ready to fork (maybe this could be an extension of an 
> already existing state variable), and either an extra stack for the fork 
> process, or doubling the size of the normal interrupt stack.

	There is no simple "interrupt stack"; there are several stacks involved
to match who has control at any moment. The applications stack is typically
very large indeed.
 
> This is in line with the existing philosophy of the packet driver.  The only 
> overhead is that of copying the packet more than once. This should not be a 
> problem for a serious program.
> 
> What do you think?

	I think you should try to implement this stuff as a brassboard and
see the problems involved.
 
> 
> Peter
> ----------------------------------------------------------------------------
> P.Tattam                                    International Phone 61-02-202346
> Programmer, Psychology Department           Australia     Phone   002-202346
> University of Tasmania, Hobart, Tasmania, Australia
> ----------------------------------------------------------------------------
	Joe D.

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 18:11:31 GMT
From:      sblair@upurbmw.dell.com (Steven C. Blair "Your Friendly Hostmaster")
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   FDDI<-> ENET router infor SOUGHT


Am starting an FDDI project here for advanced engineering requirements.
Will be using SynOptics FDDI concentrator to achieve SAS status for
most nodes on the "ring".

Wanted information on experiences with FDDI<->Enet routers. Interop
was a disappointment in that *unnamed* vendors who work in routers
seemed to have incredibly unreliable products.(IE: "oh yeah, we're
on the ring", they said, so I checked their consoles, and found
enet interfaces up, but FDDI connections down, after 40->200Mb's
of data traffic).

If worse comes to worse, I can use a machine with FDDI on the concentrator
side, and keep it's enet connection up, to the backbone.

Please followup on *NEWS* I would like that all share in learning...

thanks



-- 
Steve Blair	DELL UNIX NETWORK OPERATIONS sblair@upurbmw.dell.com
=====================================================================
**Would someone please tell SCO, that the PC in their Advertisement**
**is a >286<  and that it has a DISK FAILURE CODE on it, please **

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 19:09:06 GMT
From:      leonard@arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   A good word for the new GSI/NIC

I'd like to put in a *good* word for the new GSI/NIC.

I know it's frustrating to try to connect up via the Internet
to the GSI/NIC.  And I hate not being able to access WHOIS.
But that's life.  If there's only a 56Kb X.25 pipe to them, then
we're just stuck with poor connectivity for the time being.

But as far as I can tell, calling them up definitely *does*
work.  Last week, I called them at 1-800-365-3642, because I
needed to apply for a new AS (Autonomous System) number.  The
fellow who answered the phone right off the bat seemed helpful
and reasonably knowledgeable.  They mailed me a hardcopy of
the application form the very same day.

Now, I haven't returned the form yet, so I can't vouch for how
fast they'll process my request.  But I don't think it to be
an unreasonable inconvenience to have to communicate with them,
for the short term, through voice phone and hardcopy mail.

(Of course, you can't update the master zone files via voice 
phone and hardcopy mail.  Maybe GSI should FedEx floppies with
the zone files to the other root servers till they get their
network link upgraded.)

- Aaron

---

DDN Network Information Center
Government Systems, Inc.
14200 Park Meadow Dr., Suite 200
Chantilly VA 22021

1 800 365 3642
1 703 802 4535
1 703 802 8376 (FAX)

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 19:20:26 GMT
From:      aprm%gd@SHAFTER-EMH2.ARMY.MIL (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   you're back!

Text: 

Hooray!  I just got my first postings of this digest after a week or
more of nothing.  I thought the new NIC had burned down, or perhaps fell
into a sink hole.  I hope it's working better than it was there just
before it fell silent.  Now, if only my DDN gateway knows the IP
address, this will get through.
 
Gary Dunn, USARPAC DCSRM IMO                 |
Ft. Shafter LAN: aprm%gd               _   _ |
DDN: aprm%gd@shafter-emh2.army.mil    /.\ /.\|
Work phone:  (808) 438-2716           \_/|\_/
FAX: (808) 438-8954                      |
                                        /
 
	"We have probed the earth, excavated it, 
	burned it, ripped things from it, buried 
	things in it. . . .That does not fit my 
	definition of a good tenant.  If we were 
	here on a month-to-month basis, we would 
	have been evicted long ago." 
		Rose Elizabeth Bird 

 --- End of Message -----------

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 20:41:21 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: A good word for the new GSI/NIC

>I know it's frustrating to try to connect up via the Internet
>to the GSI/NIC.  And I hate not being able to access WHOIS.
>But that's life.  If there's only a 56Kb X.25 pipe to them, then
>we're just stuck with poor connectivity for the time being.

	That was kind of what spurred my original joking remark
about uunet. They've got connections Ivan Boesky would envy. I
doubt in all seriousness that they'd want to take it on, but there's
the commerical internet exchange association whose various members
currently operate CERFnet, AlterNet, PSInet, and uunet - the represent
both a hell of a lot of internet expertise and a hell of a lot of
good connectivity. We couldn't exactly *draft* uunet and force them
to do it :) but CIX is in the business of providing these services -
maybe someone could point out to the powers that be that there's a
bunch of people with the technical knowhow and the connectivity, who
are already doing this stuff, and doing it well.

mjr.
-- 
	Open Systems means freedom in computing. Just like freedom in
law or philosophical disciplines, you can expect its proponents to argue
over what it means until long after it's a dead issue.
					- notebooks of a heretic, 1991

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 21:10:32 GMT
From:      husain@cres.UUCP (Iqbal Husain)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <p6or510@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>FDDI concentrators have one particular disadvantage:
>    Concentrators eliminate the potential speed advantage of Dual-MAC
>	stations.   (It is not unreasonable, illegal, non-standard, or
>	fattening to hope get more than the about 85Mbit/sec that is the
>	maximum for a single-MAC station.)
>
>Vernon Schryver,  vjs@sgi.com

I agree with most of Vernon's comments, except the question of cost. 

As he mentions, concentrators allow single attach stations to be 
connected to the network. SAS adapters are considerably less 
expensive than "dual-attach" stations (DAS). 

Concentrators provide electronic bypass capability for each attached 
station. The cost of optical bypass switches is not negligible 
& I suspect very few use it.

The disadvantage of not being able to use both rings for > 85Mbit/sec 
is small compared to the additional cost of the second mac. Note that 
this is not simply a dual attach station - it is also a dual 
attach dual MAC station. Moreover, there are other problems that are 
associated with using the secondary as another ring - IP addressing 
comes to mind - what happens to the individual IP addresses when the 
ring is wrapped; the two macs may need to route IP between each other; etc.
These problems may have been solved or there are work arounds - I have 
yet to see them. Also, correct me if I am wrong, one loses the 
redundancy of the secondary ring, if that ring ring is used for 
traffic.

The industry trend is going towards using concentrators - witness 
InterOp, where most of the booths were connected to concentrators.

Iqbal Husain
husain@crescendo.com
Above opinions are mine and not necessarily that of my employer..  

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 91 21:49:48 GMT
From:      ebersman@uunet.uu.net (Paul Ebersman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Revolution (was Re: Alternate NICs)

In <1991Oct27.230743.3616@sulaco.Lonestar.ORG> merlin@sulaco.Lonestar.ORG (David Hayes) writes:
>One problem holding up commercial internet services is this: One of the best
>resources available on the net is the FTP archives. Commercial members who
>have not been "blessed" by the goverment can't get access to these sites.
>They can join Alternet, or PSInet, or CERFnet, but those commercial IP
>providers are not permitted to pass traffic from non-blessed sites to 
>the government-funded portions of the Internet.

Most of our customers have NSFNet approval and can get directly to any
large archives. Also, any customer connected to us or one of the other
CIX (Commercial Internet eXchange) members can get to ftp.uu.net, which
has a modest archive (800 Meg B^) of its own.

There are other large archive sites, including MIT, which our customers
can get to without traversing the NSFNet backbone.

One of the major motivations of the CIX is to allow as much access as
possible to the largest number of sites via routes that do not require
NSFNet approval.

-- 
                   Paul A. Ebersman @ UUNET Communications
                   uunet!ebersman or ebersman@uunet.uu.net
       The difference between theory and practice in practice is greater
           than the difference between theory and practice in theory.

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 01:24:55 GMT
From:      jmb@ideas.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   faulty mailing lists?


this is not the regular method but,

after sending mail to the tcp-ip-request and not getting a satisfactory
response, i am taking this course.
1 - i was receiving multiple mailings of some posting, usally two, sometimes
        three.  after sending mail to the "moderators" --
2 - now i receive no mail from this list at all.
3 - so i re-subscribed to the list and
4 - still, i am not receiving mail from this list!!!
FLAME ON - I FOLLOW THIS LIST AVIDLY, PLEASE CORRECT THIS SITUATION
flame off

where are the list archives kept?
i would like to review the last two weeks of mail which i have missed.

thanks to all the readers of the list for your patience.

jon bresler
jmb@neckweed.ideas.com

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 01:46:35 GMT
From:      newnham@enzian.trl.OZ.AU (Simon Newnham)
To:        comp.protocols.tcp-ip
Subject:   Dynamic Window Congestion Control


Would someone be able to answer my question ?

I want to know if the versions of TCP most commonly in use today have a dynamic window congestion control mechanism built into them, so that they can work on pure datagram Networks which have a limited trunk capacity. 

	By 'dynamic window congestion control' I am referring to the facility described in RFC 896 (or something similar), which causes a data transmitter to perceive the receiver's window as being smaller than it actually is whenever there are signs of congestion in the datagram Network. This causes the transmitter to send less data between acknowledgements, and thus less buffer capacity is used by the connection in the congested intermediate nodes. If congestion continues, the perceived receiver window is reduc







ed further - and may infact be reduced to zero size ! (so that the transmitter sends no data). Then, when the congestion dissipates, the window size is perceived to be its real size, and the transmitter can once again send a full window size of data between acknowledgements. While this technique is suggested in RFC 896 - I don't know if it is commonly implemented.

If this mechanism is commonly implemented, what events does TCP monitor to detect the presence of Network Congestion ?

-	The receipt of ICMP source quench messages ?

-	The loss of a TCP segment ?

-	Both these events in combination ?

Could you tell me if there is an RFC which describes this mechanism in more detail than RFC 896 ?


I know there are a lot of TCP experts out there, so if I get no reply, I'll
assume that this mechanism is not commonly implemented.



Thanks in anticipation...

Simon Newnham

Telecom Australia Research Laboratories,
770 Blackburn Rd, Clayton, Victoria, 3108.
Australia.

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 07:35:25 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Request: More than One Packet Driver

jrd@cc.usu.edu (Joe R. Doupnik) writes:
>
>	Not really. The first PD call requests the address of a buffer and
>the second call transfers the packet to the buffer. The called application
>has no idea of what's in the packet until the second call completes. Further,
>all this is at interrupt level (from the PD and board). There are tonnes of
>packets arriving at the board so processing has to be very fast.
>

Just to give people an idea of how fast Joe means, consider small 100
byte packets arriving at our computer.  Each occupies about 89.6 microseconds
of Ethernet time.  It is quite possible for us to receive two packets in a row,
so we must complete our processing within that time or we start relying
on the packet buffers in the Ethernet card.

On a 16 bit ISA bus, the minimum transfer time for those 100 bytes is about
21.4 microseconds.  You also have to manage the card, manage the interrupt
controller, find memory for the packet, etc.

For hardware zealots I will include some other times in puzzel format. 
Microchannel cards are about equivalent for the 16 bit variety or almost
half the time for 32 bit versions.  For busmasterring cards the value is
usually about one half to one quarter the times you've just computed.

But the point is that there isn't much time to start with.  If you intend
to continue processing despite these interrupts then your ISR must be
much faster than the packet arrival times.  

I hope that helps a little.
Erick
-- 
----------------------------------------------------------------------------
Erick Engelke					   Watstar Computer Networks
Network Developer				      University of Waterloo
Erick@Development.Watstar.UWaterloo.ca		    (519) 885-1211 Ext. 2965

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 09:09:10 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   Re: Dynamic Window Congestion Control

In article <1991Oct30.014635.4968@trl.oz.au>, newnham@enzian.trl.OZ.AU (Simon Newnham) writes:
> 
> Would someone be able to answer my question ?
> 
> I want to know if the versions of TCP most commonly in use today have a
> dynamic window congestion control mechanism built into them, so that they can
> work on pure datagram Networks which have a limited trunk capacity.  

Before Van Jacobson work in 1988, TCP-IP was most often shipped with a simple
"flow control" algorithm, using a fixed size end to end window and a simple
timer adaptation scheme. The deficiency of this were demonstrated by many
authors, e.g. Lixia Zhang paper on "Why TCP timers dont work well". The
modification of Van's include an estimator of the round trip delay deviation
for accurate time-out estimation, and a "slow-start + congestion-avoidance"
mechanism for congestion control. The upgraded version is present in most
recent UNIX releases, e.g. SunOs 4.1 or ULTRIX 4.2.

Installing these updates resulted in a dramatic improvement of the "congestion
status" of the Internet. Research work is still ongoing to "perfect" these
algorithm e.g. for removing some unwanted "phase locking" effect, to adapt
them to new situations like transactional or real-time traffic, and to design
congestion resistant datagram switches. The researches are reported in
publications like ACM "Computer Communication Review", or Wiley's
"Internetworking research and experience".

Christian Huitema

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 14:16:00 GMT
From:      lin%muppet.decnet@CONSRT.ROCKWELL.COM ("MUPPET::LIN")
To:        comp.protocols.tcp-ip
Subject:   InterNet Connectivity in Asia?


Can anyone provide the information about the connectivity in Asia (Japan, Taiwan, China, Hong Kong, Singapore...)

Your information will be appreciated.

Weifan Lin

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 15:52:47 GMT
From:      rikitake@jrd.dec.com (Kenji Rikitake)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: A good word for the new GSI/NIC

In article <1991Oct29.120907.1963@arizona.edu> leonard@arizona.edu (Aaron Leonard) writes:
>   I know it's frustrating to try to connect up via the Internet
>   to the GSI/NIC.  And I hate not being able to access WHOIS.
>   But that's life.  If there's only a 56Kb X.25 pipe to them, then
>   we're just stuck with poor connectivity for the time being.

HUH???? JUST A FIFTY-SIX KAY BPS for such an important site, and with
ENCAPSULATED link???? *SIGH*

Now I understand why I can't reach nic.ddn.mil.

What about ns.nic.ddn.mil, BTW?

-- Kenji
--
Kenji Rikitake // VMS/Japanese Development, DEC Japan R&D Center
Outside Japan: kenji@macrofield.org // From Japan: kenji@komaba.c.u-tokyo.ac.jp

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 17:14:15 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: A good word for the new GSI/NIC

In article <1991Oct29.204121.2590@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
   ... CIX is in the business of providing these services ...

Did the CIX, any CIX members, or ANS bid on the new NIC contract?  If
not, then either they weren't offered the opportunity, or they decided
they didn't want the business.  If the latter, then maybe they were
simply wiser than GSI.  If the former, then one might rightfully ask
why.

If the CIX, a CIX member, or ANS submitted an unsuccessful bid for the
new NIC contract, then since the contract is still being let by the US
government, the bids and the records of the evaluation process might
be open for public perusal.  However, I hardly know how to read the
bureaucratese in a government services contract or a request for bids,
so someone else who's handier with the Freedom of Information Act will
have to do the honors.

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 17:37:21 GMT
From:      dhansen@amiganet.chi.il.us (Dave Hansen)
To:        comp.protocols.tcp-ip
Subject:   gateway usage help request

I've got both an ethernet TCP/IP LAN and an X.25 WAN.  They are both resident
on my Encore Concept MPX (non-UNIX) host.  From my Amiga PC's, I can telnet to
the Encore, then telnet from that system over X.25 to remote hosts, that is,
the Encore does support the TCP/IP protocal over X.25.  Shouldn't there be a
way with gateway configurations to tell either my Amiga or my Encore that the
gateway Internet address of the remote host is through the local Encore
system?  The Amiga TCP/IP is a fairly robust port of the Berkley UNIX code and
does include a gateway discussion (via route and routed).  The Encore code
appears to be more custom, and the configuration only asks what a gateway
system's name and Internet addresses are.  It seems to me that first the
Encore would have to recognize the Internet address of the remote request,
encapsulate the IP packet within X.25 frames and pass it on.  Either that or
the Amiga would have to have the IP address be the local Encore and contained
within this packet would be the Internet address of the remote system.  The
Encore then would have to recognize that the IP packet was a routed packet and
repacketize with the proper Internet address and then encapsulate frames for
X.25.  Anyone know where I'm not understanding this?  Thanx.

voice: (708)691-4747             Internet:dhansen@amiganet.chi.il.us

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 20:17:06 GMT
From:      ecd@cert.sei.cmu.edu (Edward DeHart)
To:        alt.security,comp.org.usenix,comp.unix.admin,comp.protocols.tcp-ip
Subject:   Third USENIX UNIX Security Symposium - Call for Papers


               Preliminary Announcement and Call for Papers

                 The Third USENIX UNIX Security Symposium
                                 Fall 1992

                            In cooperation with
                The Computer Emergency Response Team (CERT)

     The  goal  of  this  symposium  is  to  bring  together  security
     practitioners,  system administrators and system programmers, and
     anyone with an interest in computer security  as  it  relates  to
     networks  and  the  UNIX  operating  system.   The symposium will
     consist of tutorials, invited speakers, technical  presentations,
     and panel sessions.

     This will be a three-day, single-track symposium.  The first  day
     will  be  devoted  to  tutorial presentations.  The following two
     days will include technical  presentations  and  panel  sessions.
     There  will also be two evenings available for birds-of-a-feather
     sessions and work-in-progress sessions.  The dates  and  location
     of this symposium have not yet been determined.

     Papers are being solicited in areas including but not limited to:
        o User/system authentication
        o File system security
        o Network security
        o Security and system management
        o Security-enhanced versions of the UNIX operating system
        o Security tools
        o Network intrusions (including  case  studies  and  intrusion
          detection efforts)

     Important Dates

          Extended abstracts due             May 15, 1992
          Program Committee decisions made   June 15, 1992
          Camera-ready papers due            July 31, 1992

     Send seven copies of each submission to the program chair:

          Edward DeHart
          Computer Emergency Response Team
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh, PA  15213-3890
          (412) 268-6179
          ecd@cert.sei.cmu.edu

     Program Committee

          Ed DeHart (Program Chair)	     Matt Bishop
          Computer Emergency Response Team   Dartmouth College

          Bill Cheswick	                     Ana Maria De Alvare'
          Bell Laboratories                  Silicon Graphics, Inc.

          Jim Ellis                          Barbara Fraser
          Computer Emergency Response Team   Computer Emergency Response Team

          Ken van Wyk
	  Computer Emergency Response Team

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 22:24:32 GMT
From:      jcurran@NNSC.NSF.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Root Domain Service Status

The NSF Network Service Center has worked with GSI, the DDN NOC, and the
sites running root name service to bring the current nameservers back up 
to the present.  A copy of the root zone files have been staged to an NNSC 
system which has solid connectivity to the NSFNET.  All of the root nameservers
have obtained these zone files which reflect all of the changes made through 
October 24.  I have been able to verify that 6 of the 7 servers are now running
these zone files.

The NNSC is planning to continue such coordination until the new T1 circuit 
is in operation.

Thanks should go the many people involved at NASA, BRL, U Maryland, NORDUnet,
NYSERnet, SRI, DDN NOC, and GSI.

/John

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 91 23:59:59 GMT
From:      martillo@clearpoint.com (Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: InterOp Debate (response to trip report by Joachim Martillo)

In article <67012@bbn.BBN.COM>, mckenzie@bbn.com (Alex McKenzie) writes:

> In fact, it is a bad idea to make routing decisions based on packet
> length in a general-purpose system.  Consider a router implementation
> that decides short packets must be interactive and should be given
> priority over long packets, which must be FTP.  Now put a "real time"
> transaction oriented application on this network.  Imagine that a
> typical transaction is 10% longer than the maximum packet length in some
> network which the transaction will traverse.  Some network layer entity
> will split the transaction into two packets, most likely a long one
> followed by a short one.  Farther downstram, if the load is heavy, the
> short packet will be given priority and the long packet will be delayed.
> Since the application is real time, most likely either the arrival of
> the second packet will trigger the receiver to ask for retransmission,
> or the extra delay in delivery of the first packet will lead to a delay
> in response which triggers a timer-based retransmission by the sender.
 
> Alex

Actually, a smart router could determine that these short packets were
fragments and not run into the problem you pose.  In fact, a smart
router might want to route fragmented traffic in a fragment specific
way. 

Now I do not necessarily claim that such smart routing is the right
thing to do, because certainly there is a trade-off in that the router
must do more work, and if the router does more work, performance might
decrease in spite of any gains from selecting a route which is
particularly good for a specific type of traffic.  Or the router might
require a faster cpu and faster memory which would make the router a
costlier device. 

But I am suggesting that common routing of all DOD IP packets is not
obviously correct.  There is a similar issue in disk block caching and
file system performance can sometime be improved by using a
heterogeneous disk block caching strategy where the strategy depends on
the type of use to which the file is put. 

Now if a single routing strategy for DOD IP packets is not obviously the
best design, the benefits of a single routing strategy for OSI IP (CLNS)
packets and DOD IP packets is even less obvious especially because less
or different information about the sort of traffic being carried is
available in the OSI IP packet. 

In essence, Dave Clarke's argument that the world is a complex place and
that the issue of common routing of OSI and DOD IP packets is in some
sense a diversion from the real issue is eminently reasonable. 

Joachim Carlo Santos Martillo Ajami
-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 03:00:18 GMT
From:      cdoucet@mais.hydro.qc.ca (cdoucet)
To:        comp.protocols.tcp-ip
Subject:   MacTcp 1.1

Anybody know where i can find MacTcp 1.1

answer to cdoucet@mais.hydro.qc.ca

thanks in advance 

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 05:21:57 GMT
From:      leres@ace.ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: SMTP HELO verification

I consider the whole idea of doing HELO verification silly. My sendmail
believes anything you tell it; in effect, it only uses HELO to keep
from talking to itself. In addition it uses the raw ip address of the
peer in headers and logfiles. Not only is a raw ip address a better
clue when you're trying to find out who tried to "debug" your sendmail
but it seems a waste of dns resources to look every address up when a
human rarely looks at the result.

		Craig

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 08:10:16 GMT
From:      kaldis@remus.rutgers.edu (Theodore A. Kaldis)
To:        comp.protocols.tcp-ip
Subject:   Re: Revolution (was Re: Alternate NICs)

In article <Oct.28.07.27.27.1991.150@pilot.njin.net> birchall@pilot.njin.net (Shag) writes:

> [...] NIC doesn't give you a whole lot more than you can get through
> host, nslookup, and finger, leastwise it never did for me ...

But where does the information that is in the databases accessed by
host and nslookup originate in the first place?
-- 
   Theodore A. Kaldis
   {...}!rutgers!remus.rutgers.edu!kaldis
   kaldis@remus.rutgers.edu

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 11:39:16 GMT
From:      dfk@cwi.nl (Daniel Karrenberg)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: A good word for the new GSI/NIC

leonard@arizona.edu (Aaron Leonard) writes:

>I'd like to put in a *good* word for the new GSI/NIC.
 
>I know it's frustrating to try to connect up via the Internet
>to the GSI/NIC.  And I hate not being able to access WHOIS.
>But that's life.  

Try 

	whois -h mcsun.eu.net "-a key"

on Unix (or something equivalent on your system).

This is the whois server for the RIPE (European IP) community. It gives
you access to the RIPE, NSFnet and an *old* copy of the nic database for
networks and contact persons.  "key" can be a lastname or firstname, a 
netowrk number or network name or a DNS domain name (European coverage only
for DNS domains). Leaving out the -a flag will give you only the RIPE
entries.

The interface is different but -hey- thsi wasn't intended as a backup
for *the* NIC. 

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

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 12:01:52 GMT
From:      mrs@charlie.secs.csun.edu (Mike Stump)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Revolution (was Re: Alternate NICs)

In article <1991Oct27.230743.3616@sulaco.Lonestar.ORG> merlin@sulaco.Lonestar.ORG (David Hayes) writes:
>In article <GRITTON.91Oct26152810@altar.ee.byu.edu> gritton@ee.byu.edu writes:
>One problem holding up commercial internet services is this: One of the best
>resources available on the net is the FTP archives. Commercial members who
>have not been "blessed" by the goverment can't get access to these sites.
>They can join Alternet, or PSInet, or CERFnet, but those commercial IP
>providers are not permitted to pass traffic from non-blessed sites to 
>the government-funded portions of the Internet.

Really?  I am wondering what makes you think that?  I know of people on
AlterNet that can ftp to anything they please.  Does this contradict what
you are saying?  Also, I am on CERFnet, can you name something that you
think someone else can get to that I cannot?  Is this a contradiction?
-- 
If I can get mail to you via a legally registered fully qualified
domain name, you could be on Saturn for all I care.

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

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 13:20:24 GMT
From:      atkinson@CMF.NRL.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   RFD: comp.protocols.fddi


  This is a formal Request for Discussion for a new newsgroup
with proposed details as below.  

  Please post all followup discussion to news.groups in accordance
with the USENET Guidelines.  The initial discussion period will last 3
weeks and if a consensus in favor of the group appears to exist, a
formal Call for Votes will be made at that time.

  --------------------------------------------------
NAME:          comp.protocols.fddi
MODERATION:    none
DISTRIBUTION:  world

CHARTER:
   Forum for discussions of installation, configuration, and use of
the FDDI network protocols and hardware implementing FDDI.  Also a
forum for discussions of the FDDI-II extensions and the FDDI Follow-On
Lan (FFOL) being worked on within ANSI currently.

RATIONALE:
  At present, FDDI traffic exists and appears in various places
including the TCP-IP newsgroup.  This would permit FDDI-specific
discussions to have their own forum with a name conformant with
existing practice and easy for newcomers to locate.

  This newsgroup could be one-way or two-way gatewayed with an
existing Internet mailing list that is FDDI-specific if that were the
consensus of the net and of that mailing list.  There is no 
apparent need for moderation so the group is proposed as an
unmoderated group.

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

Randall Atkinson
atkinson@cmf.nrl.navy.mil

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 13:41:48 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: A good word for the new GSI/NIC

In article <1991Oct29.120907.1963@arizona.edu> leonard@arizona.edu (Aaron
Leonard) writes:
>I'd like to put in a *good* word for the new GSI/NIC.
 
>But as far as I can tell, calling them up definitely *does*
>work.  Last week, I called them at 1-800-365-3642, because I

So what's an alternative number?  I can't call 1-800 numbers from the
UK, I need a "real" phone number if I want to get our record updated.

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

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 16:35:46 GMT
From:      @algol.uucp
To:        comp.protocols.tcp-ip
Subject:   smtp on a targon31

Hello,
i want to set up smtp on our new targon31 (SNI). I can't mail to any
other machine in our Net. Could anybody mail me a short instruction whats
to do ?

	Thanks in advance

			adolf
-- 
Adolf Kraushaar, BSA ,email: ..!unido!algol!adolf

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 17:19:30 GMT
From:      my@tern.nsc.com (Michael Yip)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <217@cres.UUCP>, husain@cres.UUCP (Iqbal Husain) writes:
|> In article <p6or510@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> >FDDI concentrators have one particular disadvantage:
|> >    Concentrators eliminate the potential speed advantage of Dual-MAC
|> >	stations.   (It is not unreasonable, illegal, non-standard, or
|> >	fattening to hope get more than the about 85Mbit/sec that is the
|> >	maximum for a single-MAC station.)
|> >
|> >Vernon Schryver,  vjs@sgi.com
|> 
|> The disadvantage of not being able to use both rings for > 85Mbit/sec 
|> is small compared to the additional cost of the second mac. Note that 
|> this is not simply a dual attach station - it is also a dual 
|> attach dual MAC station. Moreover, there are other problems that are 
|> associated with using the secondary as another ring - IP addressing 
|> comes to mind - what happens to the individual IP addresses when the 
|> ring is wrapped; the two macs may need to route IP between each other; etc.
|> These problems may have been solved or there are work arounds - I have 
|> yet to see them. Also, correct me if I am wrong, one loses the 
|> redundancy of the secondary ring, if that ring ring is used for 
|> traffic.
|> 
|> Iqbal Husain
|> husain@crescendo.com
|> Above opinions are mine and not necessarily that of my employer..  

The cost of the second MAC is actually not very much. Of course, it depends
on the implementation, I implemented a Dual MAC Dual Attach concentrator,
and it probably costed only another $150 more comparing to a Single MAC
Dual Attach concentrator design.  But I think that most vendors will charge
you another arm and another for the second MAC.  ;-)

About putting IP on both ring, ... well, some stations (eg the concentrator itself)
should be routing IP between the two rings and if the ring is wrapped, then
it also has to route even it doesn't have to.  But one reason of doing a
concentrator based network is that it can lower the probability of wrapping the 
ring.  If you only have a dual ring with dual-attach stations, then the ring
is wrapped or even segmented whenever someone turn off the station (w/o optical
bypass).  If you are attaching single attach stations to the concentrator, the
concentrator will bypass the station if something goes wrong with that station.

Well, I don't quite understand why one would loss redundancy if both rings are
being used.  If something goes wrong and the rings are wrapped, both rings will
be in used anyway.  (right?)

-- Mike

PS: I like FDDI concentrators and I also like to get the most out of
    my network anyway.

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 17:22:07 GMT
From:      my@tern.nsc.com (Michael Yip)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <217@cres.UUCP>, husain@cres.UUCP (Iqbal Husain) writes:
|> In article <p6or510@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> >FDDI concentrators have one particular disadvantage:
|> >    Concentrators eliminate the potential speed advantage of Dual-MAC
|> >	stations.   (It is not unreasonable, illegal, non-standard, or
|> >	fattening to hope get more than the about 85Mbit/sec that is the
|> >	maximum for a single-MAC station.)
 
|> ... Moreover, there are other problems that are 
|> associated with using the secondary as another ring - IP addressing 
|> comes to mind - what happens to the individual IP addresses when the 
|> ring is wrapped; the two macs may need to route IP between each other; etc.
|> These problems may have been solved or there are work arounds - I have 
|> yet to see them. ...

I think that there is supposed to be a RFC by Dave Katz (???) about
using IP on both rings of the FDDI network.  I don't know if it made
it to the RFC stage yet.

-- Mike

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 17:37:34 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <217@cres.UUCP>, husain@cres.UUCP (Iqbal Husain) writes:
> In article <p6or510@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >FDDI concentrators have one particular disadvantage:
> >    Concentrators eliminate the potential speed advantage of Dual-MAC
> >	stations.   (It is not unreasonable, illegal, non-standard, or
> >	fattening to hope get more than the about 85Mbit/sec that is the
> >	maximum for a single-MAC station.)
> >
> >Vernon Schryver,  vjs@sgi.com
> 
> I agree with most of Vernon's comments, except the question of cost. 
> 
> As he mentions, concentrators allow single attach stations to be 
> connected to the network. SAS adapters are considerably less 
> expensive than "dual-attach" stations (DAS). 

This is false.

If you look at the parts costs of DAS and SAS stations and remember to
include the parts cost of the CPU, power supply, MAC's and PHY's in the
concentrator, you will find that you have far more electronics and more
electro-optical parts in a ring using concentrators.  Please, count the
hardware in the ring before responding.  This misconception has not come up
for about 3 years in the ANSI FDDI communitee.  The correct answer is
unchanged by copper.

You trade the cost of the extra stuff in the concentrator against saving
one PHY and the optical bypass in the station, if you have a bypass.

> Concentrators provide electronic bypass capability for each attached 
> station. The cost of optical bypass switches is not negligible 
> & I suspect very few use it.

Someone who works for a SAS card and concentrator vendor would see the
market that way.  My perspective, at a DAS vendor who necessarily also
resells bypasses, is different.  I see some, not an overwhelming number,
but far more than "very few," using bypasses.

As I wrote the before and again above, bypasses are the balancing cost
for the extra cost of concentrators.

> The disadvantage of not being able to use both rings for > 85Mbit/sec 
> is small compared to the additional cost of the second mac. Note that 
> this is not simply a dual attach station - it is also a dual 
> attach dual MAC station. Moreover, there are other problems that are 
> associated with using the secondary as another ring - IP addressing 
> comes to mind - what happens to the individual IP addresses when the 
> ring is wrapped; the two macs may need to route IP between each other; etc.
> These problems may have been solved or there are work arounds - I have 
> yet to see them. Also, correct me if I am wrong, one loses the 
> redundancy of the secondary ring, if that ring ring is used for 
> traffic.

Yes, a ring DAS-DM stations is more expensive than a ring of SAS's and
concentrators, which are in turn more expensive than a ring of DAS stations.

The IP address problem has at least 2 solutions.  Silicon Graphics used the
1st at the first two InterOP's where FDDI was shown.  I currently favor the
2nd, EARP solution.

No, you loose no reduncancy if you use the 2nd ring for data.  This
question is another old and rotten red herring in the communitee.  You only
loose some bandwidth while in WRAP.  Please note that if your ring spends a
measurable time in WRAP, then the birthday paradox ensures your ring will
be sausage (partitioned).

> The industry trend is going towards using concentrators - witness 
> InterOp, where most of the booths were connected to concentrators.

The industry may or may not be moving to concentrators.  However, anyone
who participated in Interop90 and most who were at Interop91 know why most
InterOP FDDI demo booths were connected via concentrators.  The use of
concentrators this year was a policy decision, based on the fact that it is
quicker to build and shake down an FDDI ring with concentrators.  The
actual FDDI ring topology (not the demo ring) could support the the silly
conclusion that the industry is moving away from concentrators.  An
ethernet hub marketor could draw silly conclusions about the death of
yellow hose and cheapernet/thinnet base on the use of ethernet hubs at
Interop.

Ethernet TP hubs and concentrators are and will be very popular.  To say
more is either dishonest or silly.


Vernon Schryver,   vjs@sgi.com

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 18:02:16 GMT
From:      steven@pita.seas.ucla.edu (Steven Stovall)
To:        comp.protocols.tcp-ip
Subject:   Re: RFD: comp.protocols.fddi

atkinson@CMF.NRL.NAVY.MIL writes:


>  This is a formal Request for Discussion for a new newsgroup
>with proposed details as below.  
 
>  --------------------------------------------------
>NAME:          comp.protocols.fddi
>MODERATION:    none
>DISTRIBUTION:  world

FDDI is basically the only reason I read dcom.lans, so yeah
I think it should be a separate group.
________________________________________________________________________________

steven stovall               "we should be like victims, burnt at the stake,
steven@pita.cns.ucla.edu      signalling through the flames."
(213) 825 7405                           - antonin artaud

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 19:47:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

> From steven@pita.cns.ucla.edu  Thu Oct 31 09:53:31 1991
> 
> In comp.protocols.tcp-ip you write:
> 
> >FDDI concentrators have one particular disadvantage:
> >    Concentrators eliminate the potential speed advantage of Dual-MAC
> >	stations.   (It is not unreasonable, illegal, non-standard, or
> >	fattening to hope get more than the about 85Mbit/sec that is the
> >	maximum for a single-MAC station.)
> 
> I didn't understand this. I thought that the secondary ring was for
> redundancy and was never active unless the primary was wrapped. Is
> there a reference for the issues involved in using the secondary for
> performance?


It was a reference to the old knee-jerk reactions in X3T9.5 about putting
data on the secondary ring.  For years, a minority has talked of putting
data on the secondary ring for various goals from raw performance (e.g. me)
to robustness (e.g. the military).  For just as long, an even smaller
minority has wrung its hands at the prospect.

If you have a dual ring with 100Mb/s (well, 95Mb?) on each ring and
something happens, when ring recovery gets you back above 0Mb/s, you may
not have 190Mb/s of data.  I cannot see why this should frighten anyone.
The same thing happens on a single ring running almost at capacity when
some additional stations decide to move a big file or image.

The only problems with putting TCP/IP data on the secondary ring are:
    1) actually having a secondary ring (i.e. dual attach, dual MAC stations)
    2) finishing the EARP RFC
    3) proving that the cost is justified by more performance or reliability


(I hope you don't mind my copying my answer to the mailing list.)


Vernon Schryver,   vjs@sgi.com

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 20:25:44 GMT
From:      lhuynh@siam.ICS.UCI.EDU (Thomas Huynh)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   echo and tty

Hi,

	I have two questions.  First, where can I get source codes
	to these two programs?  And second, I noticed in the
	/etc/services file, there is a tcp/ip application called
	"tty."  Anybody know what tty is used for?

--
Thomas Huynh  lhuynh@bonnie.ics.uci.edu
Information and Computer Science
University of California, Irvine

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 20:48:21 GMT
From:      geertj@philica.ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   unido performance (was: Re: PING to NIC.DDN.MIL)

In article <190@edison.North.DE> diro@edison.phone.North.DE (Dirk Rode) writes:
>Shalom,
>
>kwang@eng.vitalink.com (Kwang Sung) writes:
>
>>	Does anyone have better idea to get equal response time from 
>>NIC.DDN.MIL for everybody in U.S. ? 
>>P.S. Here is PING Info from Fremont Area, CA.
 
>>PING nic.ddn.mil(192.112.36.5): 64 data bytes.
>>------- nic.ddn.mil PING Statistics ------------
>>16 packets transmitted, 6 packets received  62% packet loss
>
> hmmm ... get to another country :-)))
>From us (University of Oldenburg / Germany) Ping statistics says
>something about 102 packets sends, 13% packet loss.
>
> But the time for fremont area CA is very bad because nic.ddn.mil is
>located in Menlo Park, CA. If possible, you should route over hawaii,
>you enter there the fast NASA network and get a fast connection to
>nic.ddn.mil. This is no joke, in Germany you can better route via 
>Switzerland to Munich then over unido - the German EuNet Node.

I have no problems at all with the unido people. The network is fast enough - 
we're using ISDN and have a 64kbyte pipe to the internet.

I suspect you're using DATEX-P to get to unido? DATEX-P sucks, it's expensive,
slow, and unrelyable. What could one expect from the bundespost, that
is unable to handle even normal international phone calls (or do they think
70% failure rate is 'normal'?). I expect your problems to come from that.
(for the international readers, DATEX-P is a German X.25 network).

Of course, by the time I write this it is well known that the NIC problems
arise from a very bad case of milnet gateway overload - I wouldn't
evaluate unido's performance on NIC's connectivity.

The unido people are helpful and open. If there is a problem, they don't
deny it but tell what's going on. If they can fix it, they will.
If I encountered difficulties, they helped to get it fixed. Of course,
if an international cable is cut, ther isn't much more that can be
done but wait.
In short, I'm very satisfied with the service unido gives.

Geert Jan


--8<--nip-nip---------------------------------------------------------------
"We trained hard - but it seemed that every time we were beginning to form up
into teams, we would be reorganized. It was to learn later in life that we tend
to meet any new situation by reorganizing, and a wonderful method it can be
for creating the illusion of progress while producing confusion, inefficiency,
and demoralisation." - possibly from Petronius, 100 BC

Geert Jan de Groot, Philips ICA, Weisshausstrasse 1, 5100 Aachen, Germany
Email: geertj@ica.philips.nl or ..!hp4nl!philica!geertj
Phone: +49 241 6003 714  FAX: +49 241 6003 709

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 21:35:52 GMT
From:      jcarton@amex-trs.com (Jeff Carton)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   arp cache aging question

I've got a question on arp cache aging and how it's
implemented on the RS6000.

After reading rfc826 and related chapters from Comer,
it's my assumption that arp entries should either be
deleted after (a) a set period of time or (b) after
the destination failed to respond to a request.

From testing done on a Sun, I've found that the arp 
entry will be deleted after a period of time (about
15 mins) but on the IBM system, the entry seems to 
never be deleted, even after repeated requests to a 
non-responding address.

My question is two fold:

1) Which arp cache deletion method is correct (aging
vs. no response) ?

and

2) Is there a problem in the IBM arp implementation ?

Thanks !

-- 
Jeff Carton
American Express Travel Related Services
Internet jcarton@amex-trs.com  
UUCP	 uupsi!amexphx!jcarton

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 22:00:15 GMT
From:      geertj@philica.ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet not working?

In article <1991Oct22.201316.16212@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>Can someone with more knowledge of what's happened here shed some
>light on this whole affair.  I recall seeing a posting by the NSF
>in May concerning "DCA funding for Internet registration will
>soon end.  That coupled with the expiration of NFS's grant to
>BBN for the NNSC ...".  They were talking about network information
>services for the interim-NREN.  Is that in any way related to the
>switch of the NIC from SRI to GSI?  Does anyone know just who GSI
>really is?  I assume they underbid SRI for this contract from DCA?
>Someone asked weeks ago, after the first posting from SRI about
>the changeover, for someone from GSI to stand up and introduce
>themselves, but GSI seems like an unknown still.  Thanks.

The NIC has moved from SRI to GSI. GSI is only connected to the internet
via a 56kb connection, that has severs overload problems.
They are woring on it; I have heard of nov 5 as a date that a much
faster link will be in place.
Until then, then overload is that big that nobody gets through. Nobody.

Basically, GSI just has its start-up problems. It is very tragic that this
happens with such an important site. It looks to me that most of the problems
will hopefully be over in a week or so.

On the admin side, I heard that they now have a backlog of 1-2 weeks.
They're working on it.

I found a message which you might find interesting:

----

Date: Thu, 31 Oct 91 09:14:35 EST
From: phigate!NADC.NADC.NAVY.MIL!crompton (D. Crompton)
Subject: Network Problems

Info on Psossible network Problems.


The following is a memo received from the Chief of NIC services.  It shows
their awareness of the problems being encountered and that they are taking
positive steps to resolve them.  

******************************************************************************
As you know, since the transition of NIC services from SRI to GSI on October 1
of this year, a number of problems have been identified.  Most members of both
the Internet and MILNET user communities have been impacted by these problems
in one way or another.  The purpose of this memo is to inform you of the status
of our attempts to remedy the problems and to find solutions that will be
satisfactory to all those whose network operations have been curtailed because
of the difficulties that have arisen.  In our continuing analysis of the
current state of network service problems, we have identified two major
areas of concern.  We will attempt to address these areas separately in this
memo and also to respond to some peripheral issues that we are attempting to
resolve.  We want to assure the entire user community that we at the NIC are
working diligently--in some cases round the clock--to improve network response
time and improve overall service delivery.


Problem 1:  Network Connectivity

Synopsis of Problem:

      Currently, the NIC is connected to the MILNET by a single 56K line, and
      all traffic from both DDN and Internet users must compete for that
      single line.  Since all Internet traffic must currently pass through the
      MILNET to reach the NIC, network congestion has increased significantly
      for MILNET users.  In addition, both DDN and Internet users are
      experiencing long delays in establishing connections, as well as
      unstable connectivity even after a session has been initiated.  

      Moreover, many problems that do not immediately appear to be related to
      connectivity are, in actuality, a direct result of this degraded
      connectivity.  For example, the impact of this congestion has caused the
      Root Domain Server and other NIC servers to behave atypically, not
      because of faulty configuration, but because of connection instability.


Solution Status:

      We are currently negotiating to establish a direct connection to the
      Internet to alleviate much of the current congestion and improve 
      performance for the entire user community.  With the addition of
      this connection, you should all see a marked speed up in response time
      for both initial connection establishment and other service requests.

 

Problem 2:  WHOIS Search Response Time

Synopsis of Problem:

      As you are all aware, response time for WHOIS database searches has been
      poor. This difficulty appears to lie in the Ingres server that we 
      have installed.  The server appears to be overloaded and unable to
      achieve an acceptable response speed.

Solution Status:

      We are currently working directly with technicians at Ingres to resolve 
      the Ingres server difficulties.  So far, they have been most
      cooperative.  However, in the event that Ingres cannot provide a
      solution within a reasonable length of time, our own software
      development staff is also working to devise a way to bypass the Ingres
      server and establish an alternative response path.  We sincerely regret
      the inconvenience to all WHOIS users, and we hope to have a satisfactory
      fix in place in the very near future.


Peripheral Concerns

      Since the transition of NIC services on October 1, we at the NIC have
      been made aware of several heretofore undisclosed agreements and/or
      arrangements that SRI had established with members of the Internet user
      community.  We intend to honor those agreements when it is at all
      possible to do so within the boundaries of our contract.  For example,
      the SRI NIC had made arrangement for certain services to be provided to
      MCI.COM, and the staff at the new NIC was not aware of this until after
      the transition.  We expect other such situations to surface as we
      continue to operate, and we hope to resolve these matters as they arise
      in a manner that is satisfactory to all parties.


Summary

      We thank you in the NIC user community for your patience and fortitude
      in the face of the difficulties you have recently experienced.  To those
      of you who have been inconvenienced, we sincerely apologize.  We hope to
      alleviate the difficulties as speedily as possible and to restore all
      NIC services to a level of speed and usefulness that exceeds that which
      you enjoyed in the past.  In the meantime, we are working hard to
      improve connectivity, WHOIS response time, registration services, and 
      all other network services for which the NIC is primarily responsible.  
      We ask for your continued patience and cooperation in working with us to
      achieve that end.  Do let us know if you are having problems other than 
      the ones which we have mentioned here, so that we may begin to provide 
      solutions to those as well.



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

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 22:21:25 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI Concentrators

In article <1991Oct31.171930.19314@berlioz.nsc.com>, my@tern.nsc.com (Michael Yip) writes:
>  ...
> About putting IP on both ring, ... well, some stations (eg the concentrator
 			     itself)
> should be routing IP between the two rings and if the ring is wrapped, then
> it also has to route even it doesn't have to. ...


Such routing between the rings is needed if you use the "one IP network/ring"
approach to putting IP traffic on both rings.  This solution is trivial to
implement, but is clunky.  It does no automatic load sharing between the
rings.  It continues to work just fine should the dual ring be wrapped.  To
my knowledge, mine is the only implementation of that rather obvious idea
seen outside a lab.  For years Silicon Graphics showed it at many trade shows.

The 2nd solution is some kind of "Extended ARP".  The idea is to extend ARP
in a fashion that existing single-MAC stations would not notice, while
communicating (MAC address,ring,IP address) among dual-MAC stations.
Dual-MAC transmitters would do good things to balance their load between
the rings.  Should the dual-ring be wrapped, everything would continue to
operate gracefully.  No routing between the primary and secondary rings
would be necessary or desirable.

I like the draft EARP RFC, except for disagreement with a few details.  I
disliked other solutions such as bridging between the rings.

Dave Katz is the author of RFC-1103 and 1188 describing TCP/IP/FDDI
encasulation.  The authors of my copies of the EARP proposals include
Caralyn Brown, Carol Iturralde, and Doug Hunt of Prime, and Doug Bagnall
and Mary Jane Strohl of Apollo/HP.

Adding a second MAC to a station is not cheap.  A dual-MAC interface might
cost only a little less than two dual-attach, single-MAC interfaces,
because the expensive stuff needed to process data and headers at
12MByte/sec must be duplicated.  ASICs and so forth cost more than
commodity FDDI parts.

In the olden days when an individual workstation could not saturate an
ethernet, an individual workstation with two ethernet interfaces could move
more data than with a single ethernet interface.  This implies that even
the majority of FDDI machines, which are using much less than 50% of the
raw FDDI bandwidth, might benefit from having two MACs moving data.


Vernon Schryver,   vjs@sgi.com

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 91 23:06:14 GMT
From:      chinson@chin.cs.ucla.edu (Chinson Yi)
To:        comp.protocols.tcp-ip
Subject:   Anyone using Timeplex's TIME/LAN 100 Routers?

We are looking into getting routers for Ether local area networks.
I have heard very little about Timeplex TIME/LAN 100 Routers.
If you have any experience with TIME/LAN 100 Routers, I would like
to hear from you on its performance, reliability, and other related 
issues.

Thank you in advance.
-- 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
       Chinson Yi (chinson@cs.ucla.edu) - (213)206-3584
    UCLA, Computer Science Dept.  Room 3285-B Boelter Hall
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

END OF DOCUMENT