The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1992)
DOCUMENT: TCP-IP Distribution List for July 1992 (396 messages, 222035 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/07.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 Jul 92 06:52:00 GMT
From:      jrh@mustang.dell.com (Randy Howard)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: BOOTP server for SVR4 UNIX

In article <1992Jun27.203546.11846@wimsey.bc.ca>, skl@wimsey.bc.ca (Samuel Lam) writes:
|> Hi,
|> 
|> Does anyone know of a free BOOTP server which works on SVR4
|> (System V Release 4 UNIX)?
|> 
|> Thanks in advance for any pointers.
|> 
|> ...Sam
|> -- 
|> <skl@wimsey.bc.ca>

Dell SVR4 ships with bootpd, along with the man pages for it, etc.

-- 

Randy Howard            _o	    @'s: jrh@dell.com
Dell Computer Corp.     \<,	    !'s: ...!uunet!dellunix!jrh
______________________()/ ()______________________________________________
Whenever you find that you are on the side of the majority, 
it is time to reform.  -- Mark Twain

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 07:11:49 GMT
From:      msh@research.otc.com.au (Michael Homsey)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: SLIP/PPP setup questions

In article <1992Jun24.185244.10532@mcc.com> knutson@mcc.com (Jim Knutson) writes:
>
>2) Is there a simple gated config file somewhere for just adding these
>   type connections to a host?
I have gated (v2) running and have the connection die.
Ping doesn't work (you see the traffic going from watching the leds on
the modem, but it times out), but rlogin works ok. ftp dies after a certain
time. It appears to have something to do with the routing,
so I am curious as well.......

msh


-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 08:08:19 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   HP Probe - What is it?


can anyone enlighten me as to the purpose of the HP Probe
packet/protocol?

thanks

jon 

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 10:46:01 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: inetd

In article <id.JC2R._J3@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>Is there a freely available inetd implementation that will work over a
>minimal TCP implementation (a several year old Excelan design)?

There is an inetd that operates with the WIN/3B TCP/IP version 1.4 for the
3B1 (aka ATT7300 aka UNIXPC).

Suggest looking in comp.sources.3b1 or, more likely, in the att7300 archives
at ftp.uu.net and/or archive.cis.ohio-state.edu (aka osu-cis).

I recall that inetd (for the 3B1) was essentially a port from the BSD sources
at uunet.  If it'll work on the 3B1, it "should" work on anything!  :-)

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

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jul 1992 13:32:56 GMT
From:      isctanhw@nuscc.nus.sg (Tan Hsiao Wei)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: BOOTP server for SVR4 UNIX

jrh@mustang.dell.com (Randy Howard) writes:
: 
: Dell SVR4 ships with bootpd, along with the man pages for it, etc.

I have tried to compile the CMU bootpd (ver 2.2alpha) on SVR4 UNIX/386
but failed.  Has anyone succeeded?  Or does anyone know any FTP sites
where I can get other bootpd sources (such as the one included in Dell)?
Any pointers will be appreciated.

Please respond by mail as I do not monitor this newsgroup regularly.
Thanks in advance.

--
Hsiao-Wei Tan			System Programmer
isctanhw@nuscc.nus.sg		National University of Singapore

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 13:35:45 GMT
From:      knox@aplexus.jhuapl.edu (Eric Knox)
To:        comp.protocols.tcp-ip
Subject:   Re: How does TCP linger work?

Included below is part of a document that was passed down to me when I began
my sockets introduction to TCP/IP. According to this, the linger options is
ignored (I don't currently know if that is true for all systems) and  as
such, I never tried to set a timeout, but kept it at 0 (or immediate).

I believe the explanation below fully describes SO_LINGER, but if you have
any further questions, I might be able to answer them.

Eric G. Knox
knox@aplexus.jhuapl.edu


--- BEGIN INCLUDED DOCUMENT ---

1.7.2   Closing a Connection: SO_LINGER

Specify the SO_LINGER option to determine whether TCP should perform a  "grace-
ful" close:

        setsockopt (sock, SOL_SOCKET, SO_LINGER, &linger, sizeof (linger));

A graceful close occurs when a connection is shutdown, TCP  will  try  to  make
sure  that all the unacknowledged data in transmission channel are acknowledged
and the peer is shutdown properly by going through an elaborate  set  of  state
transitions.  The  variable  linger is contains values indicating the amount of
time to SO_LINGER as specified in  the  data  structure   linger  in  the  file
vw/h/socket.h.   The  structure  linger  contains  two  parameters: l_onoff and
l_linger.  The parameter l_onoff  can be set to 1  to  turn  on  the  SO_LINGER
option  and  set to 0 to turn off the SO_LINGER option.  The parameter l_linger
determines the amount of time for the shutdown. If the parameter l_onoff is set
to  1  and l_linger is set to 0, the default value of TCP_LINGERTIME (specified
in tcp_timer.h) is used for incoming connections accepted on the socket.

When SO_LINGER is turned on and l_linger is set to  0,  TCP  simply  drops  the
connec  tion  by sending out a RST if a connection is already established. This
frees up the space allocated to the TCP protocol control block and wakes up all
the sleepers on the socket.

Currently, the exact value of  l_linger  is actually ignored (other than 0)  so
that  TCP  performs  the  state  transitions  if  l_linger is not 0 but doesn't
explicitly use its value. For the client side socket, the value of l_linger  is
not changed if it is set to 0.  Issue another setsockopt( ) after the accept( )
call to ensure that the value of  l_linger  is set to 0  on  a  newly  accepted
socket connection.

--- END INCLUDED DOCUMENT ---

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 15:26:19 GMT
From:      bsimpson@ANGBAND.STANFORD.EDU ("William Allen Simpson")
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

"Daniel J. Bernstein" <brnstnd@kramden.acf.nyu.edu> complains of problems
with the IETF standardization process.

You are complaining when you only had to wait 4-6 months?  Be glad you
aren't working on the Point-to-Point Protocols, a *multi-protocol*
effort.  We had to wait nearly two years between publications of the
basic protocol, even though there were serious bugs in the specification
that had been corrected in later drafts within months.

So, I really don't think you have anything to complain about time-wise.


We are still waiting for the PPP Authentication Protocols to pass
through review.  Anything that goes through SAAG takes forever.  Yes,
they keep asking for assurance that this is the be-all and end-all of
secure protocols, even when we say that it's not intended to be, right
in the document.  And they have a strong father-knows-best attitude.

But they are doing their darndest in a tricky field with conflicting
goals of current practicality versus future prediction.  And I've always
found them willing to explain their goals and concepts (at great length).
These are true believers!  This is their life's work!  That results in
the usual conflicts between religious adherants.

All I can advise is public patience, and privately "working them over
with a rubber hose", as our esteemed working group chair put it recently.


The passing of copyright to the IAB was in the preliminary drafts of
the standardization document, and people like me asked them to take it
out.  If you publish a specification (in any form), I believe that all
it takes is a reference to your prior work, and anyone can come up with
a revision.  There has been a long IETF history of just such revisions
(and consternation of the original authors).

The copyright question arose in the context of restricting who could
re-print a specification, and whether some company might want control
of, or fees for, use of the document or something described in the
document.  I am of the "religious" persuasion that the Internet should
*not* publish or standardize on anything with such controls or fees.

Most RFCs are the result of the effort of groups of people.  The
putative author is just the editor for the group, and in my experience
is merely the contact who has agreed to handle the grunt work.  I've
contributed significant amounts of text to RFCs that bear someone else's
name.  Don't let your ego get in the way of getting things done.


The review process has too many levels.  I'm a guy who actually stands
up and calls for *abolishing* the IAB.  The IESG is trying to be too
many things to too many people, and in my observation, spends far too
much time talking about process than actually making decisions.  It has
no real power except delay and "recommendation".  Some recommendations
may be made based on the author's eye-color, so far as I can tell (in
reality, based on a very ingrained old-boy network).  Most of the time,
the process seems to spin its wheels.

I agree that both negative and positive decisions should be published,
as well as the scheduling of the time for making the decision.  This
has started with the "last call", but is not yet strictly followed.

I *want* them to make decisions about the Internet.  There is chaos
otherwise.

In your case, be thankful that at least action has been taken.  Now you
know, and can go on to other things.

Bill_Simpson@um.cc.umich.edu
    bsimpson@ray.lloyd.com

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1992 22:29:53 -0400
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: user-space NFS

kirkby@bandar.dg.oz (Chris Kirkby) writes:
: Does anyone know of any implementations of NFS in user space rather than
: kernel ?.  If so is there any PD code available I could ftp.

let's see.  Vince Cate's "alex" system (from alex.sp.cs.cmu.edu) sits
in user space; I believe that the "amd" automounter (don't know where
it's from off hand, but check archie or uunet) lives in user space too.

User level NFS servers were all the rage at the latest Usenix File Systems
workshop in Ann Arbor, a message to office@usenix.org will get you info
on ordering a copy of the proceedings.

--Ed

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 16:24:49 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios emulator


In article <920701090937@cream.ftp.com>, jbvb@vax.ftp.com (James B. VanBokkelen) writes:
|>In article <BqnK4p.IqJ@rivm.nl> michel@neptunus.rivm.nl (Michel van Best) writes:
|>    
|>    Does anybody know where to find a public domain netbios... for tcpip?
|>
|>As far as I know, there aren't any.  Everyone to date who has gone through
|>the rather nasty process of figuring out what a NETBIOS is in the real world
|>(as opposed to the IBM Green Book) charges for it:  Novell (Excelan),
|>Ungermann-Bass, FTP Software, TWG and others have DOS versions, and all the
|>available OS/2 TCP/IPs have one as well.

We also support it under VMS, as part of the standard WIN/TCP product. As
noted, however, WIN/TCP isn't public domain.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 16:56:24 GMT
From:      jrh@mustang.dell.com (Randy Howard)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: BOOTP server for SVR4 UNIX

In article <1992Jul1.133256.20724@nuscc.nus.sg>, isctanhw@nuscc.nus.sg (Tan Hsiao Wei) writes:
|> jrh@mustang.dell.com (Randy Howard) writes:
|> : 
|> : Dell SVR4 ships with bootpd, along with the man pages for it, etc.
|> 
|> I have tried to compile the CMU bootpd (ver 2.2alpha) on SVR4 UNIX/386
|> but failed.  Has anyone succeeded?  Or does anyone know any FTP sites
|> where I can get other bootpd sources (such as the one included in Dell)?
|> Any pointers will be appreciated.
|> 
|> Please respond by mail as I do not monitor this newsgroup regularly.
|> Thanks in advance.
|> 
|> --
|> Hsiao-Wei Tan			System Programmer
|> isctanhw@nuscc.nus.sg		National University of Singapore

I sent mail to the above, but for anyone else that is interested, a tar file
is up for anonymous ftp on dell2.dell.com:/pub/mustang/bootpd.tar.  This file
contains the bootp config file, a man page, and the bootpd binary.  This should
be sufficient for anyone with a SVR4/386 iABI compliant version of UNIX.

-- 

Randy Howard            _o	    @'s: jrh@dell.com
Dell Computer Corp.     \<,	    !'s: ...!uunet!dellunix!jrh
______________________()/ ()______________________________________________
Whenever you find that you are on the side of the majority, 
it is time to reform.  -- Mark Twain

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 17:11:30 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   ascii interpretation with tcpdump

Does anyone have any easy way of using tcpdump to print packets in hex
with an additional byte by byte ascii interpretation next to it? The
"-x" option does this without the ascii interpreation.

Actually, I would really prefer an option to do just that but only on
the data portion of tcp packets.

Has anyone built a filter to do something like this?

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


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jul 1992 17:35:20 GMT
From:      rsivaram@vela.acs.oakland.edu (SIVARAMAN R)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NFS source code needed...

Hi netters,
	I am trying to build an nfs to access unix files from dos.
Are there any source code available in public domain?
Any pointers will be greatly appreciated.
thanks
-siva

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 18:09:45 GMT
From:      cearley_k@news.colorado.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ARP entry aging?

Doug,

> > My question is:
> >     If the host being sent to has crashed or has been powered off
> >     and there is an entry in the ARP table for that host
> >     the sending host will never realize it because the table entry
> >     never ages to deletion (if the rate of sending is less than
> >     the 20 minute age period).
> >     The RFC for this (and, I believe, the Comer book) indicates that the 
> >     timer entry should NOT be reset on sends.
> >     We have had to add code to allow us to force an ARP table entry
> >     deletion when we have had a physical address change
> >     (we cannot reboot our entire system to clear all tables).

This raises a peripheral issue that may bear on your scenario as well.
Is there any consensus or opinion on the need for a host to generate a
gratuituous ARP broadcast when it is first powered on? This would address
the problem of having to delete entries when a physical address changes. 

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1992 18:38:55 GMT
From:      mccanne@horse.ee.lbl.gov (Steven McCanne)
To:        comp.protocols.tcp-ip
Subject:   Re: ascii interpretation with tcpdump

Ken Mandelberg asked about an ascii dumper option for tcpdump.
From time to time, we get requests (and patches) to incoporate this
feature into tcpdump.  We have been reluctant to make such an option
standard, as it makes snooping at network data (as opposed to packet
headers) too convenient.

Modifying tcpdump to dump ascii is trivial (as are other tricks for
generating ascii dumps).  However, we don't think the changes should
be publicly available.  If you want to go out of your way to have
such a thing, then you can do that.  But let's not encourage its
proliferation by making such patches or scripts publicly available.

Steve


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jul 92 19:34:16 GMT
From:      coolidge@speaker.wpd.sgi.com (Don Coolidge)
To:        comp.protocols.tcp-ip
Subject:   Re: HP Probe - What is it?

In article <l53nimINNga8@skat.usc.edu>, tli@skat.usc.edu (Tony Li) writes:
|> In article <2728@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
|>     
|>     can anyone enlighten me as to the purpose of the HP Probe
|>     packet/protocol?
|>     
|> HP Probe is basically a Swiss Army knife.  It contains elements of
|> what we normally consider ARP, Router discovery, and DNS (and proably
|> more that I'm not thinking of).  The ARP functionality is by far the
|> most commonly used. 

Actually, there's even more to it than that. It's the HP-proprietary
answer to the question of how to do all that stuff, and its design was
optimized for HP's MPE operating system, with a vertically-integrated
view of networking protocols, rather than the layered ISO model (which
includes BSD TCP/IP, of course). HP's Unix boxes run Probe in order to
be able to talk with their MPE systems (which now also have the ability
to use ARP and DNS, but, hey, old code never dies...:^) and their 
terminal concentrators.

There are two main parts: Virtual Name to Address (VNA), which is
the ARP lookalike, and Name, which maps an HP nodename (something
which looks very much like a fully qualified domain name, but isn't -
among other things, it's limited to three sections) to a virtual
address (IP addr, usually), a medium address (Ethernet, TokenRing,
etc.), and also provides information about which protocols and services
are supported on the target machine.

Probe is limited in operation to a local network, since its packets are
media multicasts, which don't propagate through routers. Hence, in
order to get Name info about and establish connections with machines on 
remote nets, a Probe Proxy server must be present on your local net
to answer requests for remote nodes (Name only - VNA, like ARP, remains
local only). Generally, the Proxy server's database is static (though 
when I was at HP and working on Probe, I had plans to make the HP-UX 
version dynamic like many routing protocols, but I was never given the
time to do it). Recently, cisco has been working on Proxy Server 
capability in their routers; to date, only HP boxes have been able to 
do that.

Probe packets use an extended form of encapsulation, similar to but not
the same as SNAP, and may be sent in either 802.2/[3...etc.] format with
a DSAP of FC (I think) hex, or an extended Ethernet format using a type 
of 8005 hex.

There's lots more I could say, but those are the main aspects. Jon, if
you'd like to know more, contact me by email and I'd be happy to answer
any and all questions. Some of the answers might be interesting, but I
wouldn't count on it...:^)

Don Coolidge
coolidge@speaker.wpd.sgi.com 

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 19:56:03 GMT
From:      lothar@tmcsys.UUCP (Lothar Hirschbiegel)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: BOOTP server for SVR4 UNIX

In article <1992Jul1.065200.2814@raid.dell.com> jrh@mustang.dell.com (Randy Howard) writes:
|In article <1992Jun27.203546.11846@wimsey.bc.ca>, skl@wimsey.bc.ca (Samuel Lam) writes:
||> 
||> Does anyone know of a free BOOTP server which works on SVR4
||> (System V Release 4 UNIX)?
||> 
||> Thanks in advance for any pointers.
|
|Dell SVR4 ships with bootpd, along with the man pages for it, etc.

So? Did you notice skl@wimsey.bc.ca asked for a _free_ BOOTP server
which works on SVR4 ?? 
Are you suggesting he should use an illegal bootpd copy from a Dell SVR4 system
or what ??  What's your point?

-- 
------------------------------------------------------------------------
L. Hirschbiegel                                   email: unido!aega84!lh   

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 20:22:02 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ARP entry aging?

In article <1992Jul1.110945.1@news.colorado.edu> cearley_k@news.colorado.edu writes:
>Doug,
>
>> > My question is:
>> >     If the host being sent to has crashed or has been powered off
>> >     and there is an entry in the ARP table for that host
>> >     the sending host will never realize it because the table entry
>> >     never ages to deletion (if the rate of sending is less than
>> >     the 20 minute age period).
>> >     The RFC for this (and, I believe, the Comer book) indicates that the 
>> >     timer entry should NOT be reset on sends.
>> >     We have had to add code to allow us to force an ARP table entry
>> >     deletion when we have had a physical address change
>> >     (we cannot reboot our entire system to clear all tables).
>
>This raises a peripheral issue that may bear on your scenario as well.
>Is there any consensus or opinion on the need for a host to generate a
>gratuituous ARP broadcast when it is first powered on? This would address
>the problem of having to delete entries when a physical address changes. 

I believe that there is general consensus that broadcasting an ARP
request to yourself is a preferred action.  This is especially useful
for detecting duplicate IP addresses.  The host still needs mechanisms
to update stale information in their ARP caches.  There is no guarantee
that a broadcast from a powering-up host will be seen.  I think it is
also considered to be a good idea for the host to occasionally send an
ARP request directly to the MAC address of entries in the ARP cache to
verify the info.  This is more efficient than just timing out the entry,
deleting it and forcing a new broadcast request.

Art

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 22:24:37 GMT
From:      goldstein@carafe.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: ATM (was: IP over partial mesh Frame Relay)


ATM is discussed in comp.dcom.cell-relay.

While it was developed by phone companies, it may be very useful
for datacomm too...
---
Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 92 23:21:15 GMT
From:      kirkby@bandar.dg.oz (Chris Kirkby)
To:        comp.protocols.tcp-ip
Subject:   user-space NFS

Does anyone know of any implementations of NFS in user space rather than
kernel ?.  If so is there any PD code available I could ftp.
Thanks in advance
Chris

-- 
Chris Kirkby			| Internet:  kirkby@bandar.oz.dg.com
Data General			| ACSnet:    kirkby@dgaust.dg.oz
100 Dorcas Street		| CEO:	     Chris_Kirkby@DGA.ceo.oz.dg.com
South Melbourne, Australia      | Phone:     (61) 3 698-6988

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 01:30:34 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Portmapper

restock@srv.PacBell.COM (Bob Stockwell) writes:

> How does one go about managing the assignment of TCP and/or UDP ports.
> I would like to provide a number of "services" on one machine and
> assign a unique port number to each.

You could try the TCP port multiplexor described in RFC 1078.  I don't
know of anyone who uses it, but it looks usable and similar to what
you're asking for.

It defines a service that sits on TCP port 1.  Anyone who connects to
it can write a text name of a service followed by a crlf, and get a 1-line
response, either positive or negative.  If positive, the connection is
then attached to that service.

It doesn't provide mapping for UDP ports.

> In other
> words how do I do a remote getservbyname?

TCPMUX doesn't do this, in the sense that when you use TCPMUX to connect to
a service, you can't tell what port that service actually lives on, i.e.
how to get there without going through TCPMUX again.  On the other hand,
you could define a private service that accepts a service name and returns
the actual port number; this port number wouldn't be valid beyond the next
server reboot, though.

> I used the title "Portmapper" because I recall a service for Sun by
> that name, but I couldn't find any info in the RFC index.

portmap just lets a larger space of program-number/version-number pairs be
mapped onto a smaller space of port numbers.  The program numbers still
have to be registered with Sun (or somebody...).  There's a range reserved
for "private" program numbers, but that just gets you back into the same
problems you'd have with grabbing fixed TCP/UDP ports between 512 and 1023.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 04:25:37 GMT
From:      karl@MorningStar.Com (Karl Fox)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: SLIP/PPP setup questions

In article <5915@otc.otca.oz> msh@research.otc.com.au (Michael Homsey) writes:

   I have gated (v2) running and have the connection die.
   Ping doesn't work (you see the traffic going from watching the leds on
   the modem, but it times out), but rlogin works ok. ftp dies after a certain
   time. It appears to have something to do with the routing,
   so I am curious as well.......

I don't think your problem is related to routing; it sounds more like
link transparency problems.  Try `ping -s other-host 8'; it will
include fewer control characters to potentially get damaged on your
connection.  You might also try running with an asyncmap of
0xffffffff; if it fixes the problem, then you can spend an evening
trying different maps to see which character(s) get eaten (or changed)
by the link.  Most commercial PPP's can display all characters sent or
received; this can make the problem very simple, especially if you
have simultaneous access to both ends of the link.
--
Karl Fox, Morning Star Technologies                            +1 800 558 7827
1760 Zollinger Road, Columbus, Ohio 43221                      +1 614 451 1883

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 06:22:58 GMT
From:      iversen@dsfys1.fi.uib.no (Per Steinar Iversen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios emulator


comp.unix.ultrix

In article <BqnK4p.IqJ@rivm.nl>, michel@neptunus.rivm.nl (Michel van Best) writes:

|>Does anybody know where to find a public domain netbios emulator for tcpip?

One possibility might be the Pathworks clone found on yaouk.anu.edu.au, it was
announced in comp.unix.ultrix in January this year. It works under a number of
common Unix versions. I have not tested this package, so I can not say how
good or bad it is. Here are a few lines from the README file:

!This software was written to allow users of Pathworks to access file
!services from non-DEC machines. In doing so I did not realise that I
!had in fact implemented the netbios protocol. This means that (in theory
!at least) this software could be used with other PC clients, not just the
!Pathworks for DOS client.

-psi

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     iversen@vsfys1.fi.uib.no              !
! Fysisk Institutt       ! BITnet:       iversen@cernvm.bitnet                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       +47 5 212770                           !
! N-5007 Bergen          ! Fax:         +47 5 318334                           !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 06:26:10 GMT
From:      shani@GENIUS.TAU.AC.IL (Oren Shani)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Re: Open SNMP NMS platforms

In article <1992Jun16.191850.1925@iitmax.iit.edu> thsssxs@iitmax.iit.edu (Semir Sirazi) writes:
>
>	So what am I getting at here? I was wondering if anybody has any
>positive or negative experience doing this, and what platform did you use? We
>are currently looking at:
>
> .... A list of not-to-useful-for-him-things
>
>	If you know of any other platforms that are out there where the emphasis
>is on providing NMS for non-specific vendor's hardware, please let me know.
>
>				Keith Zimmerman.

This is just a roumor. PPPlease don't force my arm to give away my information 
sources or identifying details about the concerned company, but I was told by
knowladgeable sources that a certain company in the networking buisness is 
working on a revolutionery new NMS that may be what Keith is looking for...

All I can say for now is that it will be nothing like you ever seen - and
more specificaly to Keith's intrest VERY customizable and extendable to
multy-vendor environment. As much as my source can be trusted (quite so...),
it is something worth waiting for.

Please mail me if you are intrested... would like to see some noise made about
this ;)


-- 
    __    __  Oren Shani (shani@genius.tau.ac.il) 
   /  /  /    Faculty of Engineering, Tel Aviv university
  /  /   --   Israel
 /__/ . __/ . "Hold your temper" -- The caterpillar to Alice

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 07:44:11 GMT
From:      marcusj@apricot.co.uk (Marcus Jenkins)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios emulator

michel@neptunus.rivm.nl (Michel van Best) writes:


>Does anybody know where to find a public domain netbios emulator for tcpip?

If all you want is a DOS 'standard' transport (for a distributed peer-to-
peer app.?) why not use IPX?  I understand IPX.OBJ is now being 'given
away' with Windows 3.1.  Bind it to the Brigham-Young Packet Driver to
IPX stuff, and you (might) have the ability to have TCP/IP and IPX...

I have just looked on the Windows 3.1 distribution disks, and IPXODI.COM
is on there too, so you could have that, ODI and ODIPKT...

This is just a thought off the top of my head, I havn't tried it yet.

 _ _ _
' ) ) )                         Internet: marcusj@apricot.co.uk
 / / / __.  __  _. . . _        UUCP: marcusj@apricot.uucp
/ ' (_(_/|_/ (_(__(_/_/_)_      If all else fails from US, try:  
Marcus Jenkins                  apricot!marcusj@relay.EU.net
Tel: +44 21 472 3002  Fax: +44 21 471 2935
Disclaimer:  Anything I wrote above is, of course, my own view and
             does not in any way represent my employer.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 08:58:39 +0000
From:      garethh@cix.compulink.co.uk (Gareth Howell)
To:        comp.protocols.tcp-ip
Cc:        comp.protocols.ibm@demon.co.uk, garethh@cix.compulink.co.uk
Subject:   IP across X.25 Hunt Groups into IBM

Hi all,
I have a little problem :-)

In it's wisdom my client, Department of Social Security (DSS) has
decided to implement a new service on an IBM mainframe. As the DSS
runs a mixed OSI and IP network, SNA would not fit in, and as OSI VT
support is not available: we have ended up running Telnet/3270 over
IP.

The subnetwork technology is a mixture of Ethernet LANs and X.25 PDN.
Thus we have a 3172 to get the Ethernet traffic into the m/f and a
3745 to get the X.25 traffic. The question is: how do we provide
resilence?

In our ICL environment we have a bunch of X.25 lines coming in from
the PDN. Each has its own DTE address, but they are in a hunt group
and there is a virtual DTE address as well. Incoming calls are made
to the virtual DTE address and the PDN chooses the appropriate access
link according to traffic and/or availability. As far as the caller
is concerned, there is a one-to-one mapping between Network address
and SNPA.

It seems that in the IBM case the IBM IP code (running under MVS)
insists that each access link has its own IP address; rather than
connecting all the incoming links to a single SAP. This means the
calling host needs to know which IP address to call to avoid a failed
call. So, if we are to retain our resilience by means of the hunt
group (how else could we do it?) we run the risk that the destination
IP address might not be the one associated with the actual access
link.

Two approaches spring to mind to solve this:

1. Define a new subnet, entirely contained within the M/F, with
an IP address for the M/F itself, plus one for each of the access
links. Each access link would then need a "router" so that incoming
datagrams can be routed to the M/F's SAP via the internal subnet.
Source controllers would address the new M/F IP address and let the
routing code take care of the details.

2. Nominate one of the IP addresses as the one that is called, and
then proceed as above.

Both require that the IBM run embedded routing code (I don't know if
it does). Neither sounds very nice, and would probably put quite a
load on the m/f.

A third approach is to use an X.25/Ethernet router product to connect
multiple X.25 links to the Ethernet LAN, and then go in via the 3172;
but we still have a single point of failure (the 3172) in this case.

Does anybody have experience in this area that they can share?

Gareth Howell DSS ITSA +44 (253) 797292
garethh@cix.compulink.co.uk
COMMSYS Limited. 29 Blackmore, Letchworth, Herts. SG6 2SX. 0462 677090

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 11:18:27 GMT
From:      larry@trauma.rn.com (Larry Snyder)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   ip addressing

We've received our IP address -- and am wondering if we could number
our gateway machine anything (under the domain assigned class) -- 
or do we have to use a specific number (ie: ending in 1)

192.190.78.0 is what we have been assigned -- do we have to use
a specific number going into the router (ie: 192.190.78.1) or can 
it be anything (ie: 192.190.78.100) under the class C address..

Then the router handles all the routing and forwards everything to 
the network gate?  We are connected into a Netblazer via 19200 leased
line which is connected to psi via 56kb DDS..

thanks --

-- 
Larry Snyder                                    internet: larry@gator.rn.com

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 12:31:51 GMT
From:      nreadwin@micrognosis.co.uk (Neil Readwin)
To:        comp.protocols.tcp-ip
Subject:   Re: Maturity (people's, not TCP's)

ronald@gate.demon.co.uk (Ronald Khoo) writes:
|> Specifically, we tend to depend upon the published rfcs and drafts.  If
|> you're telling us that we mustn't believe the RFC that documents the
|> standards procedure, then how are we supposed to figure out what RFCs
|> we are supposed to take seriously ?

Do you believe that 793 or 822 define the way things work in the real world?
If not, why should you expect 1310 to do so? Think of Dan's experience as
an interoperability test :-) Neil.
-- 
 Phone: +44 71 528 8282  E-mail: nreadwin@micrognosis.co.uk
 Anything is a cause for sorrow that my mind or body has made

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 12:48:31 GMT
From:      Josef Moellers <mollers.pad@sni.de>
To:        comp.protocols.tcp-ip
Subject:   Changing sequence of packets in arp?

Hi,

I'm currently fixing what I consider a bug in the arp module in SVR4
(BTW this problem is also present in RiscOS).

My current fix will occasionally change the sequence in which packets
are sent, i.e. if packets 1 2 3 are delivered in this sequence to the
arp module, it will send them as 3 2 1.
This does not pose a problem if these packets are fragments of one IP
packet, as IP will collect all three of them to re-assemble the entire
packet, but what if they are e.g. three separate udp packets?
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 13:58:33 GMT
From:      knox@aplexus.jhuapl.edu (Eric Knox)
To:        comp.protocols.tcp-ip,comp.unix.internals,comp.unix.programmer
Subject:   Working with/around netstat()? Can I do that?


I am running SunOS 4.1.1 on a Sparc Station 2, doing some socket
intensive tasks (by intensive I mean up and down alot). I have
to watch the status of some of my sockets, and so I use netstat(),
(actually I am using "netstat -f inet", since I am using TCP/IP)
looking for my matching port number. The problem I have (and my
system administrator knows this problem exists) is that netstat()
will hang our console* (which is almost always in use) giving an
"mbuf map full" error.

* - netstat() hangs the console if it's called more than one
	time in a row, which I tend to do. My current fix is to
	limit the use of netstat(), but I am looking for a way
	around that.

What I am interested in doing is being able to continuously
(or at regular intervals) see the status of a particular port
number (knowing the port number and/or a file descriptor) or
range of port numbers.

Is there any way to write such a monitoring program (or is one
already written)? Or am I just plain old crazy?

Please replies to the first 2 parts of that question, not the
last as that is probably an undeniable fact that everyone around
here already knows.

Thanks,
Eric G. Knox
knox@aplexus.jhuapl.edu

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Jul 1992 14:13:52 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <1992Jun30.102440.117@indyvax.iupui.edu> imhw400@indyvax.iupui.edu writes:
|In article <1992Jun29.105902.2180@atlas.abccomp.oz.au>, paul@atlas.abccomp.oz.au (Paul Brooks) writes:
|[deletia]
|> It doesn't, really - I've been advocating a much simpler interface than
|> a Berkeley or SysV sockets-compatible interface for a while. Unfortunately
|> people seem to want a DOS PC libary that will allow them to compile a
|> source file intended for Berkeley sockets completely unchanged and have it
|> work exactly as it would on a Unix host. This bunkum since the BSD sockets
|> interface has grown in a haphazard way as various facilities were added to
|> the internet protocol suite, and now some of the functions have absolutely
|> no real purpose. The TCP protocol provides a reliable byte stream, just
|> like a file, and the stdio interface for files makes a reasonably good fit
|> to use with TCP.
|
|I'd have to agree that the Berkeley socket library is somewhat unorganized and
|contains some fossils.  But please (bleats the potential customer) remember
|that customers may *already* have large piles of code that were written to the
|socket library, and would be tremendously expensive to re-engineer.  It is
|arguably more efficient to engineer one piece of code (the library) ab initio
|than to retrofit hundreds or thousands of applications, even if the requested
|interface *is* grody-to-the-max.

No argument from here. But is it reasonable to expect to be able to simply
take the source code that was developed for (insert favourite multitasking
multiprocess OS) and put it on a MSDOS box, recompile with a vendors "sockets"
library without touching an editor at any stage, and have it work the same?
I think not. And in that case, _how_ different can the "sockets" library be
and still be acceptable to the "majority" of potential customers? What do you
leave out?
	Even different vendors' BSD-derived Un*x sockets libraries are not
exactly alike.

|> 	Issues like this started to be hammered out a few months ago, with
|> people trying to determine what is the minimum API required to get reasonable
|> TCP functionality, in the hope that a minimum API could be decided upon
|> for DOS in much the same way that vendors seem to have done for Windows, to
|
|Simplicity is admirable, but simplicity that is incompatible with finished work
|is often not worth the cost.  If you would offer *both* APIs, new code would
|probably use the new one and old code could be easily fitted to the old one. 
|The problem with offering *only* the simpler approach is that it has a
|significant hidden cost for many customers.

True. But at least initially the simple interface will be all that is offered,
simply because it is finished first, and can do the job. For the applications
we wish to offer we have to almost develop the actual code from scratch to 
obtain efficiency and small code size anyway, as well as working within and
attempting to multitask an OS that is not really worthy of the term. Plus we'd
rather have applications that people can _use_ rather than the usual cryptic
UN*X-clone apps :-)

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 14:45:25 GMT
From:      hubcap@hubcap.clemson.edu (System Janitor)
To:        comp.protocols.tcp-ip
Subject:   Re: ascii interpretation with tcpdump


tcpdump -w gack host spooge.barf.com

strings gack | more

You'll end up with the data parts truncated, but you can modifiy the amount of 
the data part that gets snarfed with the (I forget, look it up in the four
pound man page :-) option. But it seems like the more data you save the more
packets you drop.

-Mike

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 16:31:20 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ARP entry aging?

In article <247@melpar.UUCP>, toppin@melpar.UUCP (Doug Toppin) writes:
|> The environment we work in is:
|>     - approx. 50 computers from various vendors (SGI, Sun, Motorola)
|>     - most running Unix
|>     - some running a real-time system called PSOS
|>     - all communicate via TCP/IP
|> My question is:
|>     In all of our systems the ARP appears to reset the ARP table entry
|>     timer on each send to a host.
|>     If the host being sent to has crashed or has been powered off
|>     and there is an entry in the ARP table for that host
|>     the sending host will never realize it because the table entry
|>     never ages to deletion (if the rate of sending is less than
|>     the 20 minute age period).
|>     The RFC for this (and, I believe, the Comer book) indicates that the 
|>     timer entry should NOT be reset on sends.
|>     We have had to add code to allow us to force an ARP table entry
|>     deletion when we have had a physical address change
|>     (we cannot reboot our entire system to clear all tables).
|>     Do you know if this is a common occurrence or an error in the TCP
|>     implementations?
|>     If it is not common should the vendors consider it a problem with
|>     their protocol that should be fixed?
|>     So far, each vendor has said that they purchased the protocol
|>     and it works as spec'ed and they do not consider this a problem.
|> 
|> Please mail responses and I will post useful replies.
|> any information that you can provide is appreciated
|> thanks
|> Doug Toppin
|> uunet!melpar!toppin
|> 703-560-5000, x4731
I tried EMAIL and it bounced so I will post.

The original ARP RFC (826) SUGGESTS doing ARP timeout and discusses
the possibility of problems if an implementation doesn't.  This
language is quite common in old rfc (and even CCITT Recommendations).
It also suggest that is a host is attempting to establish a cicuit to
another host and fails, then the ARP entry for that host should be
deleted.  Unfortunately, this is not much help for UDP protocols
such as NFS, because they don't place transport level connections.
How about code that attempts a Telnet session to the other hosts
periodically?  If the TCP layer fails it may remove the entry for you.
I know this is a kludge but unless you can get a patch to remove the
ARP entry update on transmission.

You also ask a question about vendors and what they should do.  The IP
protocol suite is user driven and vendors that don't support their
products should get the publicity they deserve.  I have been on both
ends of this stick and appreciated both ways.  One was a vendor that
claimed to support ICMP Source Quench.  Their support was by way of
ignoring it and not calling the packet an error.  Their reasoning was
that the RFC said that they could slow down, not that they must.  When
we offered to discuss this with the Internet community they quickly
agreed to fix the problem.

On the other side, Dr. Case found a problem with the way retries were
done on a product that I was responsible for.  I qgreed with him that
it was a problem that needed fixing but I needed I needed management
approval to modify a released product.  He provided the friendly
pressure and I received premission.  Going public is not always the
best way but sometimes the threat is needed. (BTW, my employer at that
time was NOT AT&T Tridom.)

Doug, ask them for the spec. that says that their implementation
should load your network up with meaningless traffic.  Tell them you
want a copy.  Push.  Send them the quote from Comer's book.  Suggest
that they might want to consider customer satisfaction when making
decisions instead of blind stupidity.  If you truely have this problem
then so do others and the vendor should appreciate your input instead of
ignoring it.  Sometimes a letter to upper management will do wonders.
"I don't care what the technical issues are!  You take care of the customer
or I will find somebody that will!"  

Finally, something commercial.  (Remember that the EMAIL bounced.)
You ask in another post about BOOTP/TFTP Eprom code for a 68xxx.
I have some friends that can talk to you about this at a company
called Reach Network Systems, Inc. of Roswell GA.  Unfortunatly, Reach
doesn't have a network connection yet but they can be contacted by
telephone.  The Presidents name is John Martin, and their phone is 
(404) 640-7035.  If you're still interested, give them a call.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 16:33:58 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   SNA Tunnelling in IP wanted

Is there software/hardware available that supports this - I.e. would
allow islands of SNA to communicate across a WAN that only supports IP
routing?

"Please mail and I'll summarise".

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 1992 16:36:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing sequence of packets in arp?

In article <josef.710081311@uranium> Josef Moellers <mollers.pad@sni.de> writes:
>My current fix will occasionally change the sequence in which packets
>are sent, i.e. if packets 1 2 3 are delivered in this sequence to the
>arp module, it will send them as 3 2 1.
>This does not pose a problem if these packets are fragments of one IP
>packet, as IP will collect all three of them to re-assemble the entire
>packet, but what if they are e.g. three separate udp packets?

Most networking protocols don't depend on a particular quality of service
from the underlying medium, so that they can run over a variety of media.
This includes media that may lose, duplicate, or reorder packets.  Since
the protocols are designed to cope with the medium reordering packets,
there's no reason why they shouldn't be able to handle the driver doing
this as well.

In the specific case of ARP, all the packets it sends are independent, so
it shouldn't matter what order they're sent.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 16:56:17 GMT
From:      johnc@msc.edu (John D. Cavanaugh)
To:        comp.protocols.tcp-ip
Subject:   Internet Connectivity in Asia

This is a summary of the responses I received to a posting that requested
information about Internet connection to five cities in Asia.  The
cities are:

    Singapore
    Bangkok
    Kuala Lumpur
    Jakarta
    Taipei

I found connections to the Internet, through UUCP, and through BITNET.
Many thanks to those who responded.  The list follows:

In Taiwan:

Internet:

   Administrative Contact:
      Chen, Wen-Sung  (WSC1)  ZCHEN@TWNMOE10.EDU.TW
     Ministry of Education
     Computer Center
     106 Hoping E. Road
     12th Floor, Section 2
     Taipei TAIWAN
      886-2-737-7011
   Technical Contact, Zone Contact:
      Liu, Zi-Di  (ZL2)  COLOR@TWNMOE10.EDU.TW
      886-2-737-7011

UUCP:

Acer Laboratories
Richard J. Kwan
+882 2 501 0055 x8141
8FL, 135 Chien Kuo N. Rd., Sec.2, Taipei 10479, Taiwan R.O.C.
formerly Sertek Laboratories; an R&D unit of Acer Group

BITNET:

Computing Center of Academic Sini
National Chiao-Tung University Co
National Central University
FENG CHIA UNIVERSITY
Academia Sinica - Institute of At
Institute for Information Industr
Industrial Technology Research In
Ministry of Education Taiwan
National Taiwan Institute of Tech
Soochow University
Synchrotron Radication Research C
TAMKANG UNIVERSITY--INFORMATION C
Tatung Institute of Technology
National Taiwan University Comput


In Singapore:

Internet:

National University of Singapore (SG-DOM)
   10 Kent Ridge Crescent
   SINGAPORE 0511

   Administrative Contact:
      Tong, Thio Hoe  (THT3)  ccethio%nusvm.bitnet@CUNYVM.CUNY.EDU
      (65) 772-2073
   Technical Contact:
      Liem, Chandra  (CL134)  CCECL%NUSVM.BITNET@CUNYVM.CUNY.EDU
      +65 7722527
   Zone Contact:
      Chen, Tommi  (TC148)  CCETC%NUSVM.BITNET@CUNYVM.CUNY.EDU
      (65) 772-2572

UUCP

Private Singapore UUCP and Usenet Site
Harish Pillay (harish@itivax.bitnet)
+65 278 4191
115 Bukit Purmei Road #05-234, Singapore 0409

Omron Management Centre of Asia Pacific Pte Ltd
Mohamed Ibrahim
+1 065 353 2611
510 Thomson Road #13-03, SLF Building, Singapore 1129

BITNET:

Information Technology Institute
Nanyang Technological Institute
National University of Singapore


In Kuala Lumpur:

Internet:

Malaysian Institute of Microelectronic Systems (MIMOS) (MY-DOM)
   7th Floor, Exchange Square
   Off Jalan Semantan, Damansara Heights
   50490 Kuala Lumpur
   MALAYSIA

   Administrative Contact:
      Shariffadeen, Tengku Mohd Azzman  (TMS12)  TMAS@RANGKOM.MY
      [60] 3-2552700
   Technical Contact, Zone Contact:
      Awang-Lah, Mohamed B.  (MBA)  mal@RANGKOM.MY
      [60] 3-255-2700

UUCP:

Malaysian Institute of Microelectronic Systems (MIMOS)
Mohamed b. Awang-Lah
+60 3 2987200
1662 Jalan Kerja Air, 50480 Kuala Lumpur, MALAYSIA.
Telex Number  MIMOS MA28145

BITNET:

Universiti Teknologi Malaysia


In Bangkok:

Internet:

Asian Institute of Technology (TH-DOM)
   Bangkok 10501
   THAILAND

   Administrative Contact:
      Phien, Huyng Ngoc  (HNP)  hnp%ait.th@UUNET.UU.NET
      +662 516-0110
   Technical Contact, Zone Contact:
      Charoenchai, Pensri  (PC191)  pensri%ait.th@UUNET.UU.NET
      +662 516-0110

UUCP:

Division of Computer Science, Asian Institute of Technology
Tomonori Kimura
+1 662 5290100 x 2709
PO Box 2754, Bangkok, 10501, Thailand


In Jakarta:

UUCP:

University of Indonesia, Computer Science Center
Partono Rudiarto, Didik
+62 21 335766, +62 21 330303, +62 21 3106014 
Jl. Salemba 4, P.O. Box 3442, Jakarta, Indonesia

University of Indonesia, Computer Science Center
Partono Rudiarto, Didik
+62 21 335766, +62 21 330303, +62 21 3106014 
Jl. Salemba 4, P.O. Box 3442, Jakarta, Indonesia

University of Indonesia, Computer Science Center
Partono Rudiarto, Didik
+62 21 335766, +62 21 330303, +62 21 3106014 
Jl. Salemba 4, P.O. Box 3442, Jakarta, Indonesia

The Indonesian Open Learning University, Computer Center
Agus Pratmoko
+62 21 7490941 (11 lines)
Jl. Cabe Raya, Pondok Cabe, Ciputat, Jakarta, Indonesia

-- 
John Cavanaugh                              EMail: johnc@msc.edu
Minnesota Supercomputer Center, Inc.        Phone: +1 612 626-0277
1200 Washington Ave. S                      FAX:   +1 612 624-6550
Minneapolis, MN  55415

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1992 00:13:30 -0400
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

peter@ferranti.com (Peter da Silva) writes:
: 
: Ideally, the real TCP interface should be through a virtual file system,
: so that {tcpopen("ftp.uu.net","ftp")} would be implemented by opening the
: file "/dev/tcp/ftp.uu.net/ftp".

There is a prototype user level NFS file system where you would open the
file
	/alex/net/uu/ftp/
to get the FTP root directory at ftp.uu.net.  See alex.sp.cs.cmu.edu for
a paper on it.  Rather than read and write a file descriptor that has the
FTP protocol sitting ther for you to decode, you get relatively regular
ordinary files and directories.

--Ed

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 18:49:09 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ARP entry aging?

In article <1992Jul1.202202.20309@acc.com> art@acc.com (Art Berggreen) writes:
>In article <1992Jul1.110945.1@news.colorado.edu> cearley_k@news.colorado.edu writes:
>>This raises a peripheral issue that may bear on your scenario as well.
>>Is there any consensus or opinion on the need for a host to generate a
>>gratuituous ARP broadcast when it is first powered on? This would address
>>the problem of having to delete entries when a physical address changes. 
>
>I believe that there is general consensus that broadcasting an ARP
>request to yourself is a preferred action.

A while back i was doing an ARP implementation and i considered doing
this, but the problem i had was in choosing the *source* IP address
for the ARP request.  If i used my own address as the source as well
as the destination, i ran the risk of having the request ignored by
the duplicant ("I'm not going to respond to myself.").  In addition,
if it turned out i was in fact trying to use a duplicate IP address,
my probing response would *ensure* that i'd screw up everyone that was
already talking to the node i was duplicating, since they'd all
dutifully aim their ARP caches at me: precisely what i didn't want to
happen.

Since no other source address seemed particularly reasonable,
particularly considering all the odd ARP implementations out there, i
finally dropped the idea.  What do other vendors use for the source?

At the time, i mentally constructed a "protocol" (actually just an
agreed upon behavior for ARP implementations) that would allow
duplicate detection and also allow for the distinction between servers
(nodes that other nodes expect to be at a particular IP address) and
clients (nodes whose existence is not of concern to any other nodes).
Has anyone else done something like that, and if not, would anyone be
interested in hearing such a proposal?
						don provan
						donp@novell.com

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 19:09:25 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing sequence of packets in arp?

In article <12vbaiINN5dd@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <josef.710081311@uranium> Josef Moellers <mollers.pad@sni.de> writes:
>>My current fix will occasionally change the sequence in which packets
>>are sent, i.e. if packets 1 2 3 are delivered in this sequence to the
>>arp module, it will send them as 3 2 1.
>
>Most networking protocols don't depend on a particular quality of service
>from the underlying medium, so that they can run over a variety of media.
>This includes media that may lose, duplicate, or reorder packets.  Since
>the protocols are designed to cope with the medium reordering packets,
>there's no reason why they shouldn't be able to handle the driver doing
>this as well.

Yes, they should be able to handle it, but will they handle it
efficiently?  It's hard enough to reassemble an IP packet quickly if you
assume the fragments tend to arrive in order.  Misodered fragments will
surely slow down any carefully crafted reassembly routine, whether in
IP, TCP, or, i expect, any other protocol that guarantees ordering.

This might be particularly important here, since if one were to guess at
why packets were being reordered, one might imagine that IP packet
fragments streaming out of an IP module would nearly always be reordered
whenever the ARP cache didn't have the target address in it.

One might even go so far as to suggest to the original poster that he
splurge and use both a head and a tail to form a queue rather than using
a simple stack.  The cost of a queue is minuscule, even when compared to
the effort of deciding whether or not a stack is a good idea.

						don provan
						donp@novell.com

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 19:40:05 GMT
From:      ken@racerx.bridge.COM (Ken Hardy)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Source Code

In article <1114@racerx.bridge.COM> ken@bridge.COM (Ken Hardy) writes:
>I'm looking for any and all potential sources of source code for TCP/IP
>kernels, whether they be public or commercial.  All that I'm currently
>aware of is PC/IP (?) for DOS.  Can anyone point me to other
>resources?  Many thanks.
>
>If you care to reply via e-mail, I'll post a summary.


Here is a summary of what I learned.  My sincere thanks to all
who responded.

I have not independently verified this information.

Ken

--
 

"net-2" BSD sources.  Available from okeeffe.berkely.edu via anonymous
FTP.  Also at any number of other archive sites including Uunet.

  "Because of the use it's seen this is very solid networking code and
  the copyright is quite unrestrictive.  It's written to run in a Unix
  kernel however and may require a fair bit of work to port to other
  environments."

One responent claims to have ported them to DOS and OS/2 with fairly
good results.

---

"ka9q" by Phil Karn.COM).  Available at ucsd.edu in
/hamradio/packet/tcpip/ka9q/* for ham radio and academic users.
Commercial users should contact Phil first (karn@Aualcomm.COM).

---

NCSA Telnet

---

FTP Software, Inc., will make its source code available for a price.
"info@ftp.com" for details.

---

Epilogue Technology has a portable TCP/IP implementation written in C
and intended to be easily ported to any operating system environment.
David Bridgham of Epilogue invited me to call or send e-mail if I had
questions; since he knows me only from my posted inquiry, I'll assume
that the same offer extends to you: "dab@asylum.sf.ca.us" or
+1 805 650 7107 for sales, +1 617 942 0915 for engineering.

---

Tiny TCP - a real minimal implementation - ARP, TCP, FTP, and an
ethernet driver in 977 lines of code. Look for "tinytcp" in archie or
whatever. It's meant to be a replacement for tftp for boot proms, and
not much more.

---

Waterloo TCP - this is the version used in the latest Kermit.
[I though WATTCP was based on pc/ip.  I could easily be wrong.]

---

There is an Ada version written by UniSys, and available via ftp
through STARS (source.asset.com).

---

-- 

Ken Hardy
ken@bridge.com  (racerx!ken)

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 20:20:13 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing sequence of packets in arp?

In article <josef.710081311@uranium>, mollers.pad@sni.de (Josef Moellers) writes:
|> Hi,
|> 
|> I'm currently fixing what I consider a bug in the arp module in SVR4
|> (BTW this problem is also present in RiscOS).
|> 
|> My current fix will occasionally change the sequence in which packets
|> are sent, i.e. if packets 1 2 3 are delivered in this sequence to the
|> arp module, it will send them as 3 2 1.
|> This does not pose a problem if these packets are fragments of one IP
|> packet, as IP will collect all three of them to re-assemble the entire
|> packet, but what if they are e.g. three separate udp packets?
|> -- 
|> | Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|> |  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
|> | !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |

I am not familiar with SVR4 but I do have an understanding of IP and 
ARP.  I am assuming that the arp module is receiving these packets from
the IP layer and is holding them while waiting for the address to be
resolved (the address is not in the ARP cache).  Question:  How deep
is this queue?  In your example you use three deep but how about 20?
The reason I ask is that when it comes to reordering, the receiving node
will have limitations.  If the node has to hold 19 packets while waiting
for the 20th to arrive, it must have a lot of memory.

Most implementations that I have seen only hold on to the first packet
that caused the arp request to be issued.  Then the following packets
are dropped (not as desirable) or flow controlled until the cache
entry is completed.  With routers, since their is no way to tell the
sending node to stop, they usually have to drop these packets.

Now for addressing directly your question.  IP always has the possibility
of packets being received out of order.  This is because the intermediate
routers may make different routing decisions on each packet, allowing
the later originated packet to possibly be sent on a faster path.  The
IP layer should do the reordering for the upper layers.  This is done
using the Identifier Field in the IP header.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 21:17:52 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <1992Jun30.102440.117@indyvax.iupui.edu> imhw400@indyvax.iupui.edu writes:
> I'd have to agree that the Berkeley socket library is somewhat unorganized and
> contains some fossils.  But please (bleats the potential customer) remember
> that customers may *already* have large piles of code that were written to the
> socket library, and would be tremendously expensive to re-engineer.

I certainly can't argue with that. I would suggest that either a cleaner
interface be implemented on top of this (I believe Geoff Collyer is working
on that) or that a socket library emulation be provided on top of the
tcpopen interface. But the direction should be towards deprecating sockets.

Ideally, the real TCP interface should be through a virtual file system,
so that {tcpopen("ftp.uu.net","ftp")} would be implemented by opening the
file "/dev/tcp/ftp.uu.net/ftp".
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jul 1992 21:42:15 GMT
From:      chrisp@efi.com (Chris Phoenix)
To:        comp.protocols.tcp-ip
Subject:   Ethernet vendor IDs; LPD implementation

There are two separate questions here.

First, we are going to be manufacturing Ethernet hardware, and we need
a vendor ID assigned to us.  Does anyone know where to go for this?
I've heard it's somewhere in IEEE but I haven't been called back from
the number I tried.

Second, I am writing an implementation of LPD (server side) to run on
an IBM AT clone.  I currently have no reference for typical behavior
of the program, especially in error conditions, RFC 1179 is no help.
Does anyone have any reference that tells what an LPD "should" do in
strange cases?  Or how to handle security issues?  It's to be working
mainly with Berkeley clients.  (I know FTP software sells an LPD
server package, but we can't use it as sold and they are not
interested in adapting it or spending large amounts of time telling me
their secrets.)  Source code for a "standard" LPD implementation would
also be a good thing.  I just want the algorithms, so most legal
restrictions (eg. copyright) are OK.

Please email me with any answers, because our news feed is about 3
weeks slow.  Thanks...

-- 
"I did not walk into the wall!  OK, I did walk into the wall, but it wasn't
my fault!!"
			Chris Phoenix -- chrisp@efi.com

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 92 21:58:07 GMT
From:      art@Cayman.COM (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing sequence of packets in arp?


In article <1992Jul2.190925.8821@novell.com> donp@novell.com (don provan) writes:

   Yes, they should be able to handle it, but will they handle it
   efficiently?  It's hard enough to reassemble an IP packet quickly if you

   One might even go so far as to suggest to the original poster that he
   splurge and use both a head and a tail to form a queue rather than using



I agree whole-heartedly, I can (from experience) even tell you that
some (poorly written) applications don't handle out of order packets
(when they should) and caused us to have to change this behaviour in
our product in order to work with them. :-(

--


...............................................................................
 Art Mellor       : Cayman Systems Inc,  26 Landsdowne St,  Cambridge, MA 02139
 art@cayman.com   : Phone 617-494-1999  Fax 617-494-5167  AppleLink CAYMAN.TECH


-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 00:16:27 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: SNA Tunnelling in IP wanted

In article <1992Jul2.163358.19965@unipalm.co.uk>, ian@unipalm.co.uk
 (Ian Phillipps) wrote:
>Is there software/hardware available that supports this - I.e. would
>allow islands of SNA to communicate across a WAN that only supports IP
>routing?

Some of the routers from "cisco Systems" could do that.

E-mail <info@cisco.com> for more details.

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 00:33:50 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: user-space NFS

In article <949@dgaust.dg.oz>, kirkby@bandar.dg.oz (Chris Kirkby) wrote:
>Does anyone know of any implementations of NFS in user space rather than
>kernel?

Have a look at ftp.uu.net:usenet/comp.sources.unix/volume15/unfsd/ ,
it seems to be what you are looking for.

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 01:43:31 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <1992Jul02.141352.18560@atlas.abccomp.oz.au>
paul@atlas.abccomp.oz.au (Paul Brooks) writes: 
>	Even different vendors' BSD-derived Un*x sockets libraries are not
>exactly alike.

This can be hard to get completely right.  I know one implementation
of socket libraries that took several tries to get all the details of
the select call to match BSD's.  There are just too many unstated
"features" in the man pages for people to roll their own correctly the
first time....

Getting it right, however, does make it possible to have one source
for bunches of different machines.  When you are talking about a
client that has gone through a long, evaluation process to assure that
it is correct, issues like complete source compatibility become very
important.

Warner
-- 
Warner Losh		imp@Solbourne.COM
"I think we'd get fewer weird bug reports if we stopped selling our
 software off planet."  sm at shorty's

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 03:13:53 GMT
From:      ccecl@nuscc.nus.sg (Chandra Liem)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios emulator

In article <920701090937@cream.ftp.com> jbvb@ftp.com writes:
>In article <BqnK4p.IqJ@rivm.nl> michel@neptunus.rivm.nl (Michel van Best) writes:
>    Does anybody know where to find a public domain netbios... for tcpip?
>
>As far as I know, there aren't any.  Everyone to date who has gone through
>the rather nasty process of figuring out what a NETBIOS is in the real world
>(as opposed to the IBM Green Book) charges for it:  Novell (Excelan),
>Ungermann-Bass, FTP Software, TWG and others have DOS versions, and all the
>available OS/2 TCP/IPs have one as well.
>
>James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
>FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Is there a NetBios stack which works with IBM TCP/IP for OS/2?  It is
not included with IBM's TCP/IP software and the annoucement letter does
not mentioned anything about NetBios.  But I cannot believe there isn't
any NetBios stacks which works over IBM's TCP/IP.
-- 
Chandra Liem, Computer Centre, National University of Singapore
Bitnet: ccecl@nusvm, Internet: ccecl@nuscc.nus.sg, Phone: +65 772-2527 

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 10:35:43 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing sequence of packets in arp?

In article <josef.710081311@uranium> Josef Moellers <mollers.pad@sni.de> writes:
>My current fix will occasionally change the sequence in which packets
>are sent, i.e. if packets 1 2 3 are delivered in this sequence to the
>arp module, it will send them as 3 2 1.
>This does not pose a problem if these packets are fragments of one IP
>packet, as IP will collect all three of them to re-assemble the entire
>packet, but what if they are e.g. three separate udp packets?

Should be no problem:
1.  UDP does no guarantee in-sequence delivery anyway. Applications MUST
    therefore not rely on in-sequence delivery.
2.  Packets may also be resequenced by an IP net (eg. via different routes).
    Applications must be able to handle this situation (or they'll break).

TCP should not be a problem too.

Regards,
-Roger
(I speak for myself)

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 17:20:54 GMT
From:      drw@nevanlinna.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Portmapper

In article <bqqmuy.ak0@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
   portmap just lets a larger space of program-number/version-number pairs be
   mapped onto a smaller space of port numbers.  The program numbers still
   have to be registered with Sun (or somebody...).  There's a range reserved
   for "private" program numbers, but that just gets you back into the same
   problems you'd have with grabbing fixed TCP/UDP ports between 512 and 1023.

The advantage of portmap (as I remember it) is that the larger space
is "company number/program number/version number", each of which is 32
bits.  Sun keeps the registry of company numbers.  So you can write to
Sun and get a company number, and then have your very own 2^32 bit
space of program numbers.  Of course, there are finiteness problems,
but they're not a practical problem at that point.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Look, I've read the book.  We win in the end.
-- Bishop Desmond Tutu, re: faith and the apparent hopelessness of the
fight against apartheit

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 20:06:17 GMT
From:      karl@empirical.com (Karl Auerbach)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios emulator


>Is there a NetBios stack which works with IBM TCP/IP for OS/2?  It is
>not included with IBM's TCP/IP software and the annoucement letter does
>not mentioned anything about NetBios.  But I cannot believe there isn't
>any NetBios stacks which works over IBM's TCP/IP.

NetBios is an *interface* specification.

There are any number of protocol designs to run under that interface.
One of these is RFC1001/RFC1002.  It has its own strengths and weaknesses, 
it does exist in various products, but it is just one of any number of 
possible protocols.

And the different protocols don't interoperate.

So, just because you have a "netbios" on OS/2, for example, don't 
automatically expect it to speak to one on DOS, or even on another OS/2 
machine.

Also, the netbios service interface (API) is expremely PC (and somewhat PC-
DOS) oriented.  It doesn't move very well to, say Un*x without some (
possibly major) reworking.

BTW -- many of the semantics of netbios are really painfully at odds with a 
routed internet.  If you have the choice, you may want to avoid netbios 
altogether.

			--karl--

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 20:40:33 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Portmapper

>The advantage of portmap (as I remember it) is that the larger space
>is "company number/program number/version number", each of which is 32
>bits.

	The disadvantage of portmap is its absolute lack of any kind of
security. Presently you can't hijack NFS or YP from the portmapper, since
they wisely don't use it, but some versions of NFS mount use portmapper...

mjr.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 20:42:08 GMT
From:      b.watson@uws.edu.au
To:        comp.protocols.tcp-ip
Subject:   Is RFC1042 current?

Hi,
   Is RFC1042 the most current memo on "Transmission of IP Datagrams
over IEEE 802 Networks"?
 
  My particular intrest is Pages 8-10 where the details of the Routing
Control field in multiring 802.5 networks are described.  Page 9 describe
the broadcast bits which have the following meanings:
 
000 - Non-broadcast
100 - All-routes broadcast
110 - Single-route broadcast
 
In an effort to debug the problems that I am having with the IBMTOKEN
packet driver and our CISCO routers, I wrote a small program the dump
the RIF cache of my loaded packet driver.  The RC for the CISCO has
broadcast bits of 010 which is not defined in RFC1042.
 
What does this mean?
 
What should I read to learn more about this?
 
Should IBMTOKEN be able to cope with this?
 
Any comments or suggestions appreciated.
 
Thanks,
  Brian Watson
  Programmer, Computing Centre
  University of Western Sydney, Macarthur
  Internet: b.watson@uws.edu.au

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 21:56:13 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: Portmapper

mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:

>>The advantage of portmap (as I remember it) is that the larger space
>>is "company number/program number/version number", each of which is 32
>>bits.

There is no ``company number'', just program/version.

>	The disadvantage of portmap is its absolute lack of any kind of
>security. Presently you can't hijack NFS or NIS from the portmapper, since
>they wisely don't use it, but some versions of NFS mount use portmapper...

There is a lack of security, especially for important services.
NFS always uses 2049, and has no problems in that field.
NIS (YP) does has problems with the portmapper, though newer
version give reserved ports a special meaning. In those version
only the superuser can register/deregister services registers
at reserved ports. This greatly improves NIS security.

Your mistake about NIS is probably due to the fact that NIS caches
the last binding to an ypserver. Starting another ypserv process
doesn't immediately takes effect in those cases.

There are no versions of NIS that don't use the portmapper, that I know of.
NFS is registered, but no client uses it. Mountd is also registered.
(re/de)registering mountd is a mere act of sabotage, you don't
gain much by that (and the reserved ports mechanism prevents even
that on modern systems). Reserved ports are of little use between host,
but on a single host, they can be trusted.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jul 1992 23:22:59 GMT
From:      joeg@gagme (joe grosch)
To:        comp.protocols.tcp-ip
Subject:   Re: Help to get rfc documents

elin@digi.lonestar.org (Eddy Lin) writes:
: 
: I am sorry if this is not the right group to post this question.
: I was able to get rfc documents from info-server@sh.cs.net. But
: I have not got any response since two weeks ago. Can somebody tell 
: me where and how can I can get rfc documents from other server since
: I don't have ftp access. Thanks in advance.
: 

Send email to service@nic.ddn.mil. In the subject line place the rfc you 
wish to receive. This must be in the form RFC XXX where XXX is the number
You should have nothing in the body of the message. 

--
Josef Grosch         | It's been a quiet week in Lake Wobegon, my home town...
joeg@gagme.chi.il.us |       New Yorker by birth, Minnesoten by choice 

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jul 1992 01:14:23 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Portmapper

casper@fwi.uva.nl (Casper H.S. Dik) writes:

>There are no versions of NIS that don't use the portmapper, that I know of.
>NFS is registered, but no client uses it. Mountd is also registered.
>(re/de)registering mountd is a mere act of sabotage, you don't
>gain much by that (and the reserved ports mechanism prevents even
>that on modern systems). Reserved ports are of little use between host,
>but on a single host, they can be trusted.

	I haven't been forced to look at YP or its sources for a long
time so forgive my blissful ignorance. ;) It's nice to see that a few
hacks have been thrown into it to try to make it a little less of a
total loss than the earlier versions, but I'm not convinced that Yp
is not beyond salvage. You also have to be careful because it's quite
possible that some implementations of YP services don't have all the
latest hacks thrown in.

	I was going to ask if the yppasswdd somehow relied on the
reserved port to know that it was "ok" to change the user's password,
but it looks like it actually is dumber than that - it seems to
pass the user's old password over the net in cleartext, along with
the new password. How frightfully brilliant. So, all someone
needs to do is to query the portmapper to find out what port yppasswdd
is running on and then have tcpdump look for udp packets heading
that way? And people wonder why I don't use NIS...

	Sincere query: with UDP, and the assumption that a "bad guy"
can have complete control over another node on the local wire, what
will most UNIX IP implementations do if they get a UDP packet with a
source address=localhost destination address=localhost thrown at them
by a spoofer?

mjr.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jul 92 02:28:47 GMT
From:      wb8foz@skybridge.SCL.CWRU.Edu (David Lesher)
To:        comp.protocols.tcp-ip
Subject:   TTL - is it the problem?

A friend's site runs an old 750, with Ultrucks 2.0.

Recently, the sendmail here stopped connecting to him. It just sits in
the queue. But his connects to me, passes messages, and disconnects
just fine.

I wrote to the postmaster at the listed nameserver for his subdomain,
and got a surprising answer. The postmaster said that that version of
Ultrix did not have a long-enough Time To Live to get to my site since
they had rearranged their network.

Yet I can ping the machine just fine. 

Does this make sense? Is there any solution to this besides them
upgrading their machine?
--
A host is a host from coast to coast..wb8foz@skybridge.scl.cwru.edu
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jul 1992 09:14:13 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   ifconfig and routing?

Hi All, we are having an amazingly hard time trying to get our VAX 11/750
running BSD 4.3 (a very old version) behaving properly now that its finally
on the internet.  Here is the situation:

Mullet (the VAX) is connected via a SLIP line to the rest of the world
(gateway illium), as well as by a SLIP line to a local machine (marlin),
and by ethernet to another local machine (themac).  At least, thats what is
suppose to be the case.  But its not working very well at all despite many
days of trying all sorts of random permutations of ifconfigs and routes. 

mullet = 130.95.100.2 - The VAX
marlin = 130.95.100.3 - A local PC, running BSD, via SLIP
themac = 130.95.100.4 - A local Mac, using MacTCP, via ethernet.
illium = 130.95.128.20 - The gateway to the rest of the world, via SLIP

As near as I can see it we need to have it like this:

# ethernet
ifconfig de0 mullet netmask 255.255.255.0 \
         broadcast 130.95.100.255 -trailers

# local loopback
ifconfig lo0 127.0.0.1 netmask 255.255.255.0

# local SLIP to marlin
slattach ttya4
ifconfig sl0 mullet marlin netmask 255.255.255.0 metric 4

# main SLIP line to the rest of the world, gatewayed thru .128.20
slattach ttya5
ifconfig sl1 mullet illium netmask 255.255.255.0 metric 4

# local loopback route
route add mullet localhost 0
# default routing to the main SLIP line
route add default 130.95.128.2 4

Ok, well, things basically don't work too well.  It does actually put us on
the internet though, the routing of packets from anywhere else to or from
mullet via the gateway illium works fine which is good!  The packets can
also go between mullet and marlin.  Now the problems start:

Packets can't get from marlin out to the real world, or vice versa.  So
mullet isn't forwarding the packets, how do we tell it to do this?

Absolutely nothing has ever come out of the ethernet (we watched the
ethernet line with a cro, and we can see the mac send packets, but we have
never received or managed to send any packets).  Its possible this is a
hardwaare problem, but I don't think so.  Is there any easy way to just
throw a packet out onto the ethernet to test the physical ethernet
connection?

/etc> netstat -r
Routing tables
Destination          Gateway              Flags    Refcnt Use       
Interface
localhost            localhost            UH       0      3013       lo0
mullet               localhost            UH       1      18838      lo0
marlin               mullet               UH       0      623        sl0
default              illium               UG       3      66922      sl1
130.95.100           mullet               U        3      7844       de0

/etc> netstat -i
Name  Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
de0   1500  130.95.100  mullet       0       0     0       0     0
sl0   1006  130.95.128  mullet       774     0     658     0     0
sl1   1006  130.95.100  mullet       78331   0     67691   0     0
lo0   1536  127         localhost    48593   0     48593   0     0
lo1*  1536  none        none         0       0     0       0     0

(well, thats one variant we tried anyway).

Now, some more questions.  Does each interface need a seperate IP on
mullet?  Do we need to have three IP's for mullet, one for each slip line
and one for the ethernet?  If so, how do we make it route between the
interfaces?  Do the interfaces need to be on seperate networks (ie,
130.95.100, 130.95.101, and 130.95.102)?

Oh, and just a final question, is there any reason that the ifconfig de0
would have to be done early in the setup?  If we reboot the machine without
configuring de0, and then as root enter the "ifconfig de0 mullet..." line
it totally locks up the machine, the only recourse is to reset it. 
Rebooting into single user mode, doing the ifconfig and then continuing
works fine.  Strange!

Anyway, I'm totally confused, the more manual entries I read the worse it
gets, and we've tried dozens of different possibilities. Any help would be
GREATLY appreciated!  Please Email me, I can't believe anyone else is
interested...
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       peter@cujo.curtin.edu.au
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: +61 9 367 8141

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jul 1992 11:06:18 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: Portmapper

mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:

>	I haven't been forced to look at YP or its sources for a long
>time so forgive my blissful ignorance. ;) It's nice to see that a few
>hacks have been thrown into it to try to make it a little less of a
>total loss than the earlier versions, but I'm not convinced that Yp
>is not beyond salvage. You also have to be careful because it's quite
>possible that some implementations of YP services don't have all the
>latest hacks thrown in.

Agreed.

>	I was going to ask if the yppasswdd somehow relied on the
>reserved port to know that it was "ok" to change the user's password,
>but it looks like it actually is dumber than that - it seems to
>pass the user's old password over the net in cleartext, along with
>the new password. How frightfully brilliant. So, all someone
>needs to do is to query the portmapper to find out what port yppasswdd
>is running on and then have tcpdump look for udp packets heading
>that way? And people wonder why I don't use NIS...

Uhm. I don't think that relying on a reserved port on hosts
other than your own is such a good idea. I think that requiring
the user's password is the right thing. The user's old password is
send in cleartext, the new password is transmitted in its crypt(3)
form. The net effect is that you can find out the old passwords,
but only at the moment that they are changed.
Of course, some worries remain: ypchfn and ypchsh also require
(and transmit) the password in the clear. If possible,
change shell and finger entry on the ypmaster. However,
people don't change shells and finger entries that often.
I'm much more worried about telnet, rlogin , rexec,
and pop clients (from PCs/Macs to Unix) that send passwords
in the clear.

We live, and will continue to live for some time, with a
legacy of network protocol definitions that were written 
in a time when nobody really understood network security.
Since compatibility in networking is extremely important,
progress in that field has been slow. (I'm talking about what
comes with the box, not what I can buy extra)

>	Sincere query: with UDP, and the assumption that a "bad guy"
>can have complete control over another node on the local wire, what
>will most UNIX IP implementations do if they get a UDP packet with a
>source address=localhost destination address=localhost thrown at them
>by a spoofer?

Process it as a normal packet? I really don't know. There isn't much
you can do with a packet originating from localhost.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jul 1992 11:21:33 GMT
From:      lr@cs.brown.edu (Luigi Rizzo)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   New version of PCserver available


A new (and faster) version of PCserver is available by anonymous
FTP from gwd2i.cnuce.cnr.it (131.114.1.31), in ~ftp/pub/pcserver.

PCserver is a software that allows the acces to MS-DOS hosted
Transputers via TCP/IP (and that's why I am posting to these
groups too).
PCserver's approach is much similar to the Inmos B300, but
without requiring any special hardware. With respect to the
version I distributed last year, the new one is much faster. In
our setting, we measured 75-80KBytes/s during the boot phase, and
~50 Kbytees/s during normal I/O. All this using a Dec2100 (a slow
RISC) as the host system.

If you try PCserver, please take the time to send your comments,
bug reports or suggestions to luigi@iet.unipi.it

	Luigi Rizzo
==================================================================
Luigi Rizzo                Brown University & Univ. di Pisa
e-mail: lr@cs.brown.edu, luigi@iet.unipi.it
==================================================================



-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Sun, 05 Jul 1992 03:09:06 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <id.RN4R.5R9@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
|In article <1992Jun30.102440.117@indyvax.iupui.edu> imhw400@indyvax.iupui.edu writes:
|> I'd have to agree that the Berkeley socket library is somewhat unorganized and
|> contains some fossils.  But please (bleats the potential customer) remember
|> that customers may *already* have large piles of code that were written to the
|> socket library, and would be tremendously expensive to re-engineer.
|
|I certainly can't argue with that. I would suggest that either a cleaner
|interface be implemented on top of this (I believe Geoff Collyer is working
|on that) or that a socket library emulation be provided on top of the
|tcpopen interface. But the direction should be towards deprecating sockets.
|
|Ideally, the real TCP interface should be through a virtual file system,
|so that {tcpopen("ftp.uu.net","ftp")} would be implemented by opening the
|file "/dev/tcp/ftp.uu.net/ftp".

But is this much better than the current sockets scheme in terms of OS/
architecture independence? What would be done on machines where (for
example) filenames are limited to 8 characters? Or OSs that don't have any
concept of "filenames" at all? Put another way, is it reasonable to expect
an interface to a protocol to be mirrored on a different OS, or should
it be allowable for different architecture machines to have different
interfaces to the protocol, with the goal being for the interfaces to be
as similar _as possible_ to aid porting between them. The quoted example
is a good first step,but DNS names can be up to 255 characters long,which makes 
creating virtual files like the above a bit difficult on machines where
character strings are limited to a length of 255.

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jul 1992 04:14:05 GMT
From:      daudo@bcars201.bnr.ca (Dau Do)
To:        comp.protocols.tcp-ip
Subject:   stting tcp_nodelay on Unix


Does anyone know how to set the tcp no delay on the Sparc ?

I try to use the setsockopt but it keeps give me the errno (invalid argument !)



-- 
Dau Do               [~~~~~~~~~~~~~~~~~~~~~~~]   Data Packet Switching Network
daudo@bnr.ca         [                       ]   Bell Northern Research
Ph: +1 613 763 3982  [                       ]   P.O. Box 3511, Station C
FAX:+1 613 763 2626  [_______________________]   Ottawa, Ontario, K1Y 4H7
   *** "I haven't lost my mind -- it's backed up on tape somewhere." ***

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 92 05:55:09 GMT
From:      shani@GENIUS.TAU.AC.IL (Oren Shani)
To:        comp.protocols.tcp-ip
Subject:   An open NMS system

Okay, Okay, I've got the zillion responses I expected :) Obviously, I can't
reply each of them directly, so consider this a reply for all of you.

For obvious reasons, I can't say much. All I can say for now is that we are
talking about something which completly differ, by concept, from anything
youv'e seen until now. You might say that if you ever asked yourself (like
I did), weather modern science that lended a man on the moon, realy can't come
up with better aids for network management then what youv'e seen so far, this
system will proove that it can (Does this sound like public relations stuff?).

Ehm, anyway, first exposion of a prototype is expected at Interop fall, so just
a little more paitance...


P.S. This stuff has absolutly nothing to do with the Faculty of Engineering of
     the Tel Aviv university. Am just using my account here to post this.




-- 
    __    __  Oren Shani (shani@genius.tau.ac.il) 
   /  /  /    Faculty of Engineering, Tel Aviv university
  /  /   --   Israel
 /__/ . __/ . "Hold your temper" -- The caterpillar to Alice

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jul 1992 17:44:10 GMT
From:      jrichard@cs.ulowell.edu (John 'MacGyver' Richardson)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   RAW sockets to monitor network traffic level?

I am attempting to make a unix packet level network monitor program
(similar to xload) and I'm wondering what the best approach is to make
it fairly portable.  I realize that some operating systems allows
access to the network devices though special calls (such as
packetfilter in ultrix) but I was thinking about using RAW sockets to
implement this.  Now I have a couple questions.  
	o Will this work?  
	o If not is there some other way of doing it that I haven't
          heard of?

John 'MacGyver' Richardson |"sun dogs fire on the horizon        \ \   \
jrichard@cs.ulowell.edu    | meteor rain stars across the night   * *   \   /\
jrichard@duck.ulowell.edu  | ...the spark still flies                /\  * /  \
                           | reflected in another pair of eyes." /\ /  \/\/
                                                           ------  \   / / 



-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jul 1992 06:43:04 GMT
From:      ccecl@nuscc.nus.sg (Chandra Liem)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios emulator

In article <karl.23.710193977@empirical.com> karl@empirical.com (Karl Auerbach) writes:
>NetBios is an *interface* specification.
>
>There are any number of protocol designs to run under that interface.
>One of these is RFC1001/RFC1002.  It has its own strengths and weaknesses, 
>it does exist in various products, but it is just one of any number of 
>possible protocols.
>
>And the different protocols don't interoperate.

I am looking specifically for RFC1001/RFC1002 NetBios to work with IBM
TCP/IP transports.  More specifically, the "B-nodes" implementation of
RFC NetBios.  But I cannot seem to be able to locate the correct IBM
part number.

>So, just because you have a "netbios" on OS/2, for example, don't 
>automatically expect it to speak to one on DOS, or even on another OS/2 
>machine.

So far all the implementations of NetBios over TCP/IP which I know of
(Microsoft LanManager, HP LM/X, 3Com TCP, DEC Pathwork, FTP Software
etc..) are based on RFC1001/RFC1002 B-nodes.  So far so good.  One
vendor I know of did not implement "retarget" so they have problem
talking to HP LM/X at the moment but I think they would fix it soon.

>BTW -- many of the semantics of netbios are really painfully at odds with a 
>routed internet.  If you have the choice, you may want to avoid netbios 
>altogether.
>
>			--karl--

From my experience, the real pain of TCP NetBios is RAM cramped.  TCP +
NetBios would take up about 100kB or more.  If you are using LanManager,
the enhanced redirector takes another 100kB.  On a 286 AT, it would
leave you just enough memory to compile hello.c :-).   On 386 with a
memory manager, the situation is bearable.
-- 
Chandra Liem, Computer Centre, National University of Singapore
Bitnet: ccecl@nusvm, Internet: ccecl@nuscc.nus.sg, Phone: +65 772-2527 

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Jul 1992 10:50:50 GMT
From:      linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
To:        comp.protocols.tcp-ip
Subject:   Any experiences with TCP/IP on an AS-400?

If you have any experience with the TCP/IP-module on the AS-400
would you please contact me, so I can share in it?
Thanks


-- 
Erik van Linstee   |   linstee@duteca.et.tudelft.nl   |   I'll be back ... 

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jul 1992 18:52:40 GMT
From:      ihsan@ferranti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <130k5oINNohm@nigel.msen.com>, emv@msen.com (Edward Vielmetti) writes:
> peter@ferranti.com (Peter da Silva) writes:
> > 
> > Ideally, the real TCP interface should be through a virtual file system,
> > so that {tcpopen("ftp.uu.net","ftp")} would be implemented by opening the
> > file "/dev/tcp/ftp.uu.net/ftp".
> 
> There is a prototype user level NFS file system where you would open the
> file
> 	/alex/net/uu/ftp/
> to get the FTP root directory at ftp.uu.net.  See alex.sp.cs.cmu.edu for
> a paper on it.  Rather than read and write a file descriptor that has the
> FTP protocol sitting ther for you to decode, you get relatively regular
> ordinary files and directories.
> 
> --Ed

Will it (or is there something that will) support something like
/net/host_name/udp/echo or /net/192.1.1.1/tcp/1036 ?

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 92 19:37:41 GMT
From:      pauld@cs.washington.edu (Paul Barton-Davis)
To:        comp.protocols.tcp-ip,comp.unix.ultrix,comp.windows.x
Subject:   TCP/IP RESET's, ACK's, xdm & X terminal problems


This post describes a problem that we (the Computer Science Lab at the
U. of Washington) have been having with TCP/IP communications between 
a set of X terminals and two hosts running xdm. I have posted
previously about this problem several months ago, but got no response.
I thought I would try again - it seems like an interesting problem and
one that its hard to imagine is unique to us.

Scenario:

	30 Tektronix X terminals connected over thin Ethernet
	2  DECstations 5000's also on the thin Ethernet
	
	Terminals are "managed" by xdm, running on the DECstations,
	and are divided roughly equally between the two hosts.

Problem:

1) User level description:

	"I was working. Suddenly all my X windows went away,
	 and the terminal reset itself."

2) DECstation sysadmin description:
	
	"No sign of any malicious operations; the xdm log
	 file includes the message "Connection reset by peer"
	 for each occasion when this happens."

3) tcpdump analysis:

Xdm sends a "ping" packet every N seconds where N is configurable, and
set to 5 by default. This packet is a XGetInputFocus request. The
terminal should respond by sending an XInputFocus reply. Subsequently,
the xdm host sends a TCP ACK to complete the 3 packet transaction.

However, once in a while, the xdm host fails to send the ACK promptly
(where promptly means on the order of a few hundreths of a second or
less). Instead, the terminal resends its reply, after some interval of
time based on the mean trip time, and only then does the xdm host send
the ACK.

Each time this happens, the terminal adjusts its idea of the mean trip
time, and typically, as one would expect, the MTT rises and falls,
centered around a rather short mean. Problems arise, however, when the
xdm host continues this behaviour for a long time (30 minutes to 1
hour). Each time the terminal is forced to do a resend, it doubles its
resend interval. After enough resends, the interval reaches 1 minute
(!!!). At this point, the terminal doesn't bother to resend, but
insteads sends a TCP RESET, which is received by the host, and the X
session is shut down, along with the accompanying "Connection reset by
peer" message written to xdm's log file.

4) Comments

There are no obvious problems with the xdm host; its load average and
so forth are quite reasonable, and in fact, this behaviour has been
logged and reported at 2am with only 1 user & 2 "active" processes on
the system.

The behaviour of the terminal is quite in accordance with the TCP
resend algorithm. What is pathological here is not the steps taken by
the terminal, but the failure of the xdm host (the DECstation) to send
an ACK in time.

I have seen very high peak traffic on this ethernet, but normally only
for brief periods that do not seem to correlate well with the RESET
events.

I find it odd that all my tcpdump traces show the DECstation *always*
responding to the resend, without fail. If the problem was load
(either cpu or net interface), I would have expected a more
statistical spread of #'s of resends before an ACK.

5) Further developments

As part of our efforts to solove this problem, we bridged the network,
and put all the terminals hosted by one DECstation, along with that
host, on each side of the bridge. This reduces the traffic. We have
also imposed a much stricter game playing rule (:-) on the users of
the terminals. Both these steps have more or less eliminated the
problem (the games are typically multi-user X based stuff like xtrek).

5) Questions

Does anyone have any idea what could be going on ? Has anyone else run
into this problem (I know that Tektronix have done so, but they seem
unable or unwilling to solve it) ? Although we seem to have
operationally dealt with it, my curiosity is piqued, and I would like
to find out what is (was) going on ...

-- paul barton-davis
   UW CS Lab

-- 
The lady prays and prays and prays and prays and prays - its everlasting!
There's nothing wrong with praying - it's what she's asking.
She could have prayed to change her woes,          
But the preacher said "pray to cope with those"    

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jul 1992 21:34:35 GMT
From:      gfw@cbnewsd.cb.att.com (gregory.wetzel)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '92 Conference

                            Announcing

                            SIGCOMM '92
           Communications Architectures and Protocols

                        Baltimore, Maryland
                        August 17-20, 1992
 
                           sponsored by
                   The ACM Special Interest Group
                      on Data Communications

The conference provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.

A summary of the conference program is given below.  If you would like
more information, please send a (null) mail message to the SIGCOMM '92
information server at: sigcomm92-prog@ihburn.att.com.  An automatic
reply will send you a copy of the full advance program with registration
forms.


                     CONFERENCE PROGRAM SUMMARY

MONDAY 17 AUGUST

9:00 am to 5:00 pm, Tutorial I
	"ATM/B-ISDN," Bharat Doshi, Subramanyam Dravida, and
	John Swenson AT&T Bell Labs

9:00 am to 5:00 pm, Tutorial II
	"Optical Networks," Zygmunt Haas, AT&T Bell Labs

7:00 pm to 9:00 pm, Monday Evening Reception

................................................................................

TUESDAY 18 AUGUST

9:00 am to 10:00 am, Session 1: Keynote Session

10:30 am to 12:00 pm, Session 2: Protocol Design

1:30 pm to 3:00 pm, Session 3: Routing

3:30 pm to 5:00 pm, Session 4: Quality of Service

7:30 pm to 11:00 pm, Reception & Buffet Dinner at the National Aquarium
                     Tickets Required

................................................................................

Wednesday 19 August

8:30 am to 10:00 am, Session 5: Congestion Control

10:30 am to 12:00 pm, Session 6: Performance Analysis

1:30 pm to 3:00 pm, Session 7: Multicast Communications

3:30 pm to 5:00 pm, Session 8: Media Access

5:00 pm to 6:00 pm, SIGCOMM Business Meeting

................................................................................

Thursday 20 August

8:30 am to 10:00 am, Session 9: End-to-End Issues

10:30 am to 12:00 pm, Session 10: Network Measurement

12:00 pm to 12:15 pm, Closing Session

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Jul 92 09:16:18 GMT
From:      ctec@DIALix.oz.au (ConsulTech)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.sys.att
Subject:   Reverse TELNET with terminal servers?




Does anyone know how to define ports on a terminal server as constant when 
connected to a unix host?
i.e when a user connects to unix host via the terminal server, netstat shows
the user connected with the ip address of the terminal server plus what appears
to be a port address. eg 3com.444556
If the user cans his link and restarts the connection netstat shows 3com.99877 etc
I thought a reverse telnet might be the way where the unix box calls the ip address of the terminal server port that the user is connected to.
Does anyone know how to get info on the "nty" device that tcp uses. ( maybe thiscould help?

Any info I get I will repost as a summary. Please send to me direct.

regards

Anthony Percy

Consultech in sunny Western Austrailia, the sunset coast!!

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1992 09:26:13 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.unix.ultrix,comp.windows.x
Subject:   Re: TCP/IP RESET's, ACK's, xdm & X terminal problems

In article <1992Jul6.193741.12684@beaver.cs.washington.edu> pauld@cs.washington.edu (Paul Barton-Davis) writes:
>Xdm sends a "ping" packet every N seconds where N is configurable, and
>set to 5 by default. This packet is a XGetInputFocus request. The
>terminal should respond by sending an XInputFocus reply. Subsequently,
>the xdm host sends a TCP ACK to complete the 3 packet transaction.
>
>However, once in a while, the xdm host fails to send the ACK promptly
>(where promptly means on the order of a few hundreths of a second or
>less). Instead, the terminal resends its reply, after some interval of
>time based on the mean trip time, and only then does the xdm host send
>the ACK.

My guess is that the network interface on the XDM host can't handle receipt
of a packet too quickly after it sends a packet.  So, if the X terminal
replies too quickly, the XDM host won't see the reply and won't acknowledge
it.  When the X terminal times out, it resends the reply; this time the XDM
host's interface is ready to receive, so it sends the acknowledgement.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 92 11:48:42 GMT
From:      shani@GENIUS.TAU.AC.IL (Oren Shani)
To:        comp.protocols.tcp-ip
Subject:   SNMP for DOS

Hello

I would like to thank all those who answered my posting about MIT SNMP package.

I wonder if there is a similar package for DOS/Windows. I am not much femiliar
with the DOS world (wow! I must be the only person in the world who isn't :) ,
so I prefer things that where tested and known to be useful.

I would like to have pointers to commercial packets, if there are any, too.

Thanks in advance,




-- 
    __    __  Oren Shani (shani@genius.tau.ac.il) 
   /  /  /    Faculty of Engineering, Tel Aviv university
  /  /   --   Israel
 /__/ . __/ . "Hold your temper" -- The caterpillar to Alice

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 92 14:36:34 GMT
From:      kanagn@athina.cc.uch.gr (Kostas Anagnostakis)
To:        comp.protocols.tcp-ip
Subject:   On-line documents about sockets needed

Hi there netters...

Does anybody know where I can find documents describing socket programming
in C language (Unix environments) ? 
 
Any ftp sites or contact persons?

Thanks in advance

-Kostas

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jul 1992 15:19:20 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.protocols.tcp-ip
Subject:   Routers and ISDN


Does anyone know of routers that support ISDN connections, either
router-to-router or router-to-device (SLIP or PPP)?

Thanks in advance for any information you can provide.

Paul Hardiman
University of Wisconsin - Milwaukee
hardiman@csd4.csd.uwm.edu

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jul 1992 15:33:23 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: On-line documents about sockets needed

>Does anybody know where I can find documents describing socket programming
>in C language (Unix environments) ? 

	There's a PostScript pre-formatted version of the BSD IPC primer
for FTP on decuac.dec.com in pub/docs/bsd-docs/advanced-ipc-tutorial.ps.Z
                             pub/docs/bsd-docs/ipc-primer.ps.Z

mjr.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jul 1992 17:40:47 GMT
From:      chrisp@efi.com (Chris Phoenix)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)

In article <1992Jun29.105902.2180@atlas.abccomp.oz.au> paul@atlas.abccomp.oz.au (Paul Brooks) writes:
>	It seems heresy to some that TCP/IP and BSD or SysV sockets are not
>glued together, and that there might be advantages to doing things differently,
>especially on machines with a much different OS & architecture.

Hear hear!  I'm writing a TCP/IP app on a PC, and I chose the "native"
kernel calls over sockets (FTP Software Dev Kit) just because I didn't
trust the Unixness of their sockets.  Turns out I made a good
choice--looking through their code I see that if you PEEK on a recv()
it blocks for data!  This may be fine for unix, but for a
single-threaded PC doing what I need (UI plus data from several
sources), it is unusable.  I'd be happy to use a simpler interface
than the native one, but unix sockets just don't work for me.
-- 
"I did not walk into the wall!  OK, I did walk into the wall, but it wasn't
my fault!!"
			Chris Phoenix -- chrisp@efi.com

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 92 18:30:22 GMT
From:      pauld@cs.washington.edu (Paul Barton-Davis)
To:        comp.protocols.tcp-ip,comp.unix.ultrix,comp.windows.x
Subject:   Re: TCP/IP RESET's, ACK's, xdm & X terminal problems

In article <13bnvlINN8ui@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Jul6.193741.12684@beaver.cs.washington.edu> pauld@cs.washington.edu (Paul Barton-Davis) writes:
> [ ... describes a problem ... ]
>
>My guess is that the network interface on the XDM host can't handle receipt
>of a packet too quickly after it sends a packet.  So, if the X terminal
>replies too quickly, the XDM host won't see the reply and won't acknowledge
>it.  When the X terminal times out, it resends the reply; this time the XDM
>host's interface is ready to receive, so it sends the acknowledgement.

I should have made it more clear that I had already deduced this much.
Anyway, Dan Lanciani (ddl@das.harvard.edu) solved the problem for me.
There is/was a bug in the BSD TCP code. By inspection, it was fixed
(and then some) in the NET/2 distribution, but was present in Ultrix
as far as Ultrix 4.1 and by implication, exists in Tektronix' X
Terminal network code.  We have reason to believe that it exists in
NCD's code interface as well, which seems logical given the likely
origin of both companies' TCP code.

The bug ? Although the rtt timer is reset, the rxtshift value is not.
Result ? Although the timer goes back to zero, next time there is a
resend, the rtt gets large rather quickly.

-- paul


-- 
The lady prays and prays and prays and prays and prays - its everlasting!
There's nothing wrong with praying - it's what she's asking.
She could have prayed to change her woes,          
But the preacher said "pray to cope with those"    

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 92 19:16:35 GMT
From:      MLYNCH@cmsa.gmr.com
To:        comp.protocols.tcp-ip
Subject:   Summary:  TWG vs. TGV VMS TCP/IP


   I was asked by numerous people to post a summary of responses to the
differences of TGV's and TWG's TCP/IP product for a VMS system.  Thanks
to all for your input!

Original posting:

   Could someone provide me with some information on how TWG's and TGV's tcpip
products compare?  I know TGV is substantially cheaper that TWG's.  Does this
mean there are features that aren't in TGV's product that are in TWG's?  We
have been using TWG's tcpip for a couple of years, but are considering TGV's
because it is cheaper and we are upgrading systems.  We also have written some
socket based programs with TWG's tcpip.  Has anyone ever converted a TWG socket
program to run on TGV's tcpip?  How do the telnet, ftp, etc. interfaces and
options compare?  Also, I have written LPD filters to enable users to specify
different forms and setups to queues on the vax.  Does TGV's product have the
same capability?


Responses:

=========================================================================
From: Chris Bishop <cbishop@itd.adelaide.edu.au>

I've just converted to MultiNet (TGV) a program that was originally written for
Unix, then converted by some other people first to VMS UCX, then to WINS (TWG).

This site uses MultiNet and has never had WINS, so what little I know of WINS
comes from doing that conversion.

There were NO programming problems.

About the only difference that came to light is the location of the C include
files.

MultiNet's include files are all in multinet_root:[multinet.include...]
while it seems that WINS's are mostly in sys$library and some in
twg$common:[netdist.include.*].

A problem was that netdb.h is in the TOP level multinet_root:[multinet.include]
but in the SUBdirectory twg$common:[netdist.include.sys].  Here I gather
MultiNet is more consistent with standard Unix practice.

I wrote a command procedure intended to be able to compile & link that
particular program with either MultiNet or WINS, hiding those differences, and
would be happy to send it to you if that's the sort of thing that's worrying
you.

=========================================================================
From:     service@TGV.COM

I've got a comparison that I worked up some time ago comparing MultiNet V3.0
with WIN/TCP V5.1.  Alas, it is now somewhat out of date since we are now
shipping MultiNet V3.1, and Wollongong is shipping WIN/TCP V5.2!  Updating the
comparison is on my short list of things to do, but if you are interested in
the old list, you are welcome to it.  Drop me a note if you'd like me to send
it to you.

Our user interfaces are a good bit different from those in WIN/TCP.  We use a
TOPS-20 style parser (with VMS-style command-line editing).  Some people like
it a lot, others somewhat less than pure VMS CLD-style parsing (personally, I
rather like the command recognition and completion support).  There are a
number of functionality differences between our products.  My recommendation
would be for you to do a 30-day no-cost eval of MultiNet to see what the
capabilities and differences with WIN/TCP are yourself.  You might also want to
make a posting to info-multinet@tgv.com, the MultiNet customer discussion list
to get some opinions on MultiNet.

If you have any technical questions, drop a note to service@tgv.com, our  tech
support address.

=========================================================================
From: ian@unipalm.co.uk (Ian Phillipps)

>   Could someone provide me with some information on how TWG's and TGV's tcpip
>products compare?
I could, but I won't, since I'm paid to support TGV for my employers,
who sell it. If you don't get a suitable reply, try vmsnet.networks.tcp-ip.*
This is almost a FAQ there!

You could mail sales@tgv.com - they'd tell you :-)

>products compare?  I know TGV is substantially cheaper that TWG's.  Does this
>mean there are features that aren't in TGV's product that are in TWG's?   We

Not that I know of. I'm honestly surprised at what you say about pricing.

>have been using TWG's tcpip for a couple of years, but are considering TGV's
>because it is cheaper and we are upgrading systems.  We also have written some
>socket based programs with TWG's tcpip.  Has anyone ever converted a TWG
 socket
>program to run on TGV's tcpip?

Easier than that: there's a binary-compatible interface which should
cope with most programs: you may need to set a logical variable or two,
or put in a Wollongong-compatible config file somewhere if the
programmers have been naughty, but most should work. The compatibility
mode is off by default.

>options compare?  Also, I have written LPD filters to enable users to specify
>different forms and setups to queues on the vax.  Does TGV's product have
>same capability?  Thanks in advance for any information!!
Yes - don't know if it's identical, tho.

=========================================================================
From: "Postmonster (Corvus Manager)" <CORVUS@AC.GRIN.EDU>

TGV's MultiNet is every bit as feature-rich as TWG's WIN TCP/IP
implementation.  In fact, purely subjective impressions from various
Info-VAX/comp.os.vms readers suggest MultiNet is, overall, a slightly
*better* product.  The two are certainly comparable.  I can state from
personal experience that TGV's technical support is excellent.

MultiNet has a WIN compatibility mode, so you may not have to do much work
at all in order to convert your software.

=========================================================================
From:     mcmahon@TGV.COM (John 'Fast-Eddie/FuzzFace' McMahon)

Please feel free if you have any questions that you want to direct to TGV to
drop a mail message to SALES@TGV.COM or SERVICE@TGV.COM.  I'll ask the sales
people to ship a copy of our comparison between WIN/TCP and MultiNet.

In article <168119E5F.MLYNCH@cmsa.gmr.com> you write...
=
=We also have written some
=socket based programs with TWG's tcpip.  Has anyone ever converted a TWG
socket
=program to run on TGV's tcpip?

I'll answer this one.  It is fairly trivial to convert a TWG program to TGV,
typically you have to use different include files, but everything else
is very similar.  Both products use the 4.3 BSD UNIX calling standard.

We also support a Wollongong emulation mode, so any product that you do
not have sources to (e.g. a third party database or somesuch) can run over
MultiNet.

=========================================================================
From:     CASSIDY@PROCESS.COM (ROB CASSIDY - SALES)

I have some good news for you. Process Software's TCPware has all of the
functionality that  WIN and Multinet has, will out perform both products
and lists at a price lower than both. This includes a QIO programing
interface,socket library,LPS and more! Please call me or reply for more
information.

Rob Cassidy
1 800 722 7770

=========================================================================
From: G B Reilly <reilly@sec.COM>

TGV is far superior in all respects.

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

From:    DOROSZ@PL9000.PLH.AF.MIL

We did the exact thing you are thinking of.  We had Wolly software on
out 8650 and 9000 vax machines and converted to TGV Multinet since we
wanted to implement NFS client and server functions on the machines and
at the time wolly did not provide this (they do now)

Wolly software is more unix like than TGV, I like wolly better for this reason
since I also use a Sun and the telnet and ftp commands on the Wolly software
are very close to a Sun.

TGV is more of a VMS command style.  Some of the commands are quite
tedious to type for example adding a route

set route/add=(destination 146.238., gateway=146.153.100.102) in TGV

vs route add 146.238. 146.153.100.102 1     for wolly

TGV documentation stinks. It is very cryptic, there are few examples
and no explaination of how things are supposed to work.

Wolly documentation is much more complete and better written.

TGV smtp seems to work better than Wolly's, TGV does not use a
mail que so if you want to delete a message before it is sent, you can't.
Although Wolly has a new pony express mailer which is supposed to be a
improvement over the old mailer which I'm currently using on the microvaxes
here that still run wolly.

Wolly's gated and named are slightly easier to configure than TGV, again
because the documentation is better.

I haven't done any socket programming in either TGV or Wolly so I can't
speak to that.

In summary, I would say the the two products are very close, if you have
a lot of UNIX users I would stick with Wolly since I find that UNIX users
prefer it over TGV, If your users are mainly VMS, TGV is probably the better
choice.


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

From: bruce@gordian.com (Bruce Hafford)

Don't have any specifics, but we tried TGV a while back and were
very impressed with the job they did.  Everything just worked fine,
which I never felt with the Wollengong stuff.... For us the TGV was
too expensive, otherwise we would have gone with it.  They
seem to care more about doing TCP/IP a) correctly and b) in
a method consistent with Unix and other platforms...

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

From: servio!servio.SLC.COM!chrisp@uunet.UU.NET (Chris Pinkham)

I'm not quite up to date on the latest releases, but the place where
I worked until just over a year ago switched from TWG to TGV. TGV had
greater functionality (NFS clients for example), but was just a lot
more solid in the areas that were present in both products.

TGV interfaces are much better for VMS users than TWG's. TWG has modelled
its interface after Unix, which is fine by me, but not ok with all the
VMS folk who enjoy set/this/and/that.

On of the last things I nearly did before I left (:-) was to get
forms and queues working through LPD. You may have some work to do,
but I know it can be done. It will take some C hacking to some code
that TGV provides, but it's not too serious.

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

From: Aaron Leonard <LEONARD@Arizona.edu>

I believe that there are virtually no features in TWG that are
not in TGV; however, there are many features in TGV lacking in TWG.

TGV MultiNet contains a TWG emulation library, so I believe that you should
be able to run your applications under TGV with only a relink.

The command interface to the TGV utilities is typically much more
VMS-y than the TWG, so that's a matter of preference.  Actually, I
find the TGV interface to be the most user-friendly of any software
I use, as it incorporates a TOPS-20-style "COMND JSYS" feature,
whereby you can type a "?" and be prompted with all the possible
options.  Also, there is excellent hardcopy documentation, extensive
online help, good programming examples, and a Bookreader online
manual set.

Yes, I believe that there is this functionality (we just use the LPD features
in MultiNet without modification.)

One thing that you must consider in this comparison is the quality of
service and support.  We used to use TWG (up till 3 years ago), and found
that their response to bug reports was nonexistent.  When we switched
to TGV MultiNet, we found that they typically respond to a
bug report within a few hours, and have a bugfix or workaround in
our hands within 2 days.  In fact, I have never encountered any
software vendor whose responsiveness and quality of support is
so high as TGV's.  Our entire campus relies on the TGV software for
such things as nameservice, routing, mail, and much much more, and
have found that they are simply THE BEST TCP/IP in the business.

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

From: mwr%eng.tridom.com@mathcs.emory.edu (Mark Reardon)

Its been a few years but when I was attending DECUS meetings people
in the Network Special Interest Group (NETSIG) seemed to prefer the
TGV by a landslide.  The biggest question was would they be around
in a few years to support their product.  It looks like they are
staying.  I talked to several customers we had in common (I worked
for a router manufacturer then) and some even did away with DECNET
IV for Vax to Vax communications because the TGV used less CPU.  They
also let my company have a 30 day free evaluation for interoperability
testing.

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

From: larry hughes <hughes@logos.ucs.indiana.edu>

> socket program to run on TGV's tcpip?

They're about 99.5% source compatible, usually requiring only a few
minor #ifdef's.

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

From: Kevin Oberman <OBERMAN@PTAVV.llnl.gov>

I have found that code for TWG needs only very minor changes to move to TGV.
And I believe that TGV has a TWG mode to avoid even this, but I have never
tried it. The last code I converted required trivial changes to about 10 lines
of code. These involved socket calls (read and writes) that must be diffeerent
on VMS because of the IO design of VMS and the lack of true byte stream
capability. Both TGV and TWG provide replacements with different names. But
they work about the same.

I don't know of any capability TWG can claim that TGV doesn't have. Things like
NTP have always been supported. TWG seems to be finally catching up.

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

From: reece@eco.twg.com (Reece R. Pollack)

I've helped some customers go the other way, and the socket libraries are
fairly similar. Of course, it wouldn't be a standard interface if they were
that much different. The LPD filters and other non-standard enhancements  may
not be a simple matter, however.

If you have technical issues, feel free to post your comments to our news
group 'vmsnet.networks.tcp-ip.wintcp', or send me email directly. If price
is your main concern, I'd suggest you contact our sales group.

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

From: Alex Latzko <latzko@marsenius.rutgers.edu>

After much wracking decision making we moved from TWG to TGV and have never
looked back.  TGV has been amazingly responsive to problems ( which have
mostly been administrative not performance related. )

The software runs amazingly well and in local testing outperformed LAT for
terminal traffic.

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

From:    BOOTH@LUB001.LAMAR.EDU (JB)

Although I don't purport to be an expert. I have use Multinet for 3 years now
and have found it to be the best TCP/IP software I have worked with. Most
of this is due to the EXCELLENT support staff.

It is a relatively small company, and when you call, or mail to support, you
are talking to the priginal coders most of the time. The problem resolution
is really great. (Not had to use it much though). The only problems I have
had were my own fault.

The software is compatible with everything I run out here and with any other
system I have interfaced to. Multinet follows RFC standards explicitly. It is
a good case of getting MUCH more than you pay for.

vmsnet.something.multinet is a good news group to look at to get a feel for
the product and the people using it. Most of the best TCP/IP people feel it is
worth the switch, IMHO.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 92 19:50:31 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: SNA Tunnelling in IP wanted - the summary

I wrote:

>Is there software/hardware available that supports this - I.e. would
>allow islands of SNA to communicate across a WAN that only supports IP
>routing?
 
>"Please mail and I'll summarise".

Here's the summary.  Quite a few people replied - thank you all - and
most said that a cisco router would do the trick.  Some other solutions
were mentioned.

---
From: Michael Newbery <Michael.Newbery@vuw.ac.nz>
Organization: Computing Serv. Ctr, Victoria Uni., Wellington, New Zealand

cisco routers do this. STUN (Serial Tunneling) available standard as of
s/w release 8.3 allows you to have a serial line speaking SDLC (or some
user defined variant if you really want to) which is then tunneled via
TCP/IP to another cisco which reverses the process. There is support for
proxy polling to cut down on the obscene amount of traffic SNA polling
will produce.

We are just implementing this to allow us to talk to the New Zealand
Bibliographic Network, running on a big Amdahl. We will replace our
current direct line to them by a STUN link running over Frame Relay.

---

From: nothaft@nas.nasa.gov (Alfred E. Nothaft)

Last year I Beta tested Cisco routers that performed SNA tunneling
over an IP net, while working for another company deep into Big Blue.
The routers did well for FEP to Cluster Controller traffic but had
trouble with FEP to FEP traffic.

I believe the software rev on the Ciscos was ver 8.3.

Alfred E. Nothaft                         |   Internet: nothaft@nas.nasa.gov
Network Development Engineer              |      Phone: (415) 604-4325
NASA/CSC                                  |
Numerical Aerodynamic Simulation          |Disclaimer: These are my views
NASA Ames Research Center                 |not my employer's
----------------------------------------------------------------------------


From: Charley Kline <kline@ux1.cso.uiuc.edu>

Proteon provides a way to tunnel two token rings together across an
arbitrary IP fabric such that they appear to be source-route-bridged
together. We run it on a small scale here and it works pretty well.
Not quite what you asked, but I think token ring is the only high speed
multi-access network supported by SNA, no?

--
Charley Kline, KF9FF, PP-ASEL                                     cvk@uiuc.edu
UIUC Network Architect and Senior Research Programmer           (217) 333-3339
Univ. of Illinois Computing and Communication Services       AMPR: kf9ff@n9lnq

---

From: Rolf "A." Rennemo <rar@multix.no>

You don't tell whitch platform you want it for, so here goes:

1.  Intel UNIX based 327x through IP, using Novell server (3.11) as gateway.
2.  Intel UNIX based 327x through X.25 and/or ISDN.

In both cases you get the IBM comm sw from Inteface Systems (Sintec),
Tel. 0753 811888/811999 Fax 0753 811666, contact Alan Pickering.

They supply complete Novell integration and
use netCS (Germany) X.25/ISDN and GW products or Symicron X.25 (UK).

Try Alan for other contacts in UK or mail me for details.

*******************************************************************************
Rolf A. Rennemo                  Multix A/S, Gjerdrumsvei 12, 0486 Oslo, Norway
rar@multix.no                    Tel. +47 2 950800,   Fax. +47 2 950790
rar@multix.uucp                  NUUG sekretariat: nuug@multix.no

----
From: Wayne Clark <wclark@cisco.com>
Organization: cisco Systems, Menlo Park, California, USA

Ian - 

    Cisco offers SNA tunneling products for both SDLC (serial-attached)
    and LLC2 (token ring-attached) devices.  We also offer solutions that
    go from LLC2-to-SDLC.

    You'll find SDLC-to-SDLC tunneling from:
	Company			Product
	-------			-------
	Cisco Systems		Serial Tunnelling (STUN)
	Proteon			SDLC Relay
	Wellfleet		Sync Passthru
	CrossComm		SDLC Pass Through

    You'll find LLC2-to-LLC2 tunnelling from:
	Company			Product
	-------			-------
	Cisco Systems		Remote Source Route Bridging (RSRB)
	Proteon			???
	Wellfleet		???
	CrossComm		???

    You'll find LLC2-to-SDLC conversion from:
	Company			Product
	-------			-------
	Cisco Systems		SDLLC
	Netlink			SDLC Server (standalone converter)
	Sync Research		SNAC/TR (standalone converter)

    When IBM's Data Link Switching (DLS) for the 6611 router ships in 
    September 1992, it will have LLC2-to-LLC2 and LLC2-to-SDLC but not
    SDLC-to-SDLC.

    I wrote an article that surveyed all of the SDLC tunnelling products 
    on the market in the October 1991 issue of the SNA Perspective.  I'd
    be happy to phax (sic) you a copy if you'd like.

Wayne Clark
Cisco Systems, Inc.
wclark@cisco.com
415/688-4627
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jul 1992 21:23:25 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <130k5oINNohm@nigel.msen.com> emv@msen.com (Edward Vielmetti) writes:
> peter@ferranti.com (Peter da Silva) writes:
> : so that {tcpopen("ftp.uu.net","ftp")} would be implemented by opening the
> : file "/dev/tcp/ftp.uu.net/ftp".
 
> Rather than read and write a file descriptor that has the
> FTP protocol sitting ther for you to decode, you get relatively regular
> ordinary files and directories.

That's got a high nift value too, but doesn't help application writers
who want to access /dev/tcp/psycho.com/brandnewprotocol. These are both
important facilities, but they're not the same thing.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jul 1992 21:29:47 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <1992Jul05.030906.11025@atlas.abccomp.oz.au> paul@atlas.abccomp.oz.au (Paul Brooks) writes:
> |Ideally, the real TCP interface should be through a virtual file system,
> |so that {tcpopen("ftp.uu.net","ftp")} would be implemented by opening the
> |file "/dev/tcp/ftp.uu.net/ftp".
 
> But is this much better than the current sockets scheme in terms of OS/
> architecture independence? What would be done on machines where (for
> example) filenames are limited to 8 characters?

You use tcpopen() or some similar level of interface: the idea is that
"tcpopen()" is the high level portable interface, sockets are a low level
interface for old code, and "/dev/tcp/..." is the UNIX interface for the
normal UNIX tools. On UNIX tcpopen() is implemented in terms of /dev/tcp
(and on the Amiga it's TCP: and so on).
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jul 1992 06:38:26 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Subnetting for Novell routing.


Here we are about to have to create a subnet to do routing from tokenring(TCP/IP) through NetWare 3.11 to ethernet but unfortunatly our IP numbers are kind of 
ordered odd.

Anyway I need help in understanding what can be done.

Numbers in use 
xxx.xx.1-14,76,201.ALL  (not really All)

Its my understanding that subnets can be broken at the subnet mask numbers:

255.255.192.0 , 255.255.224.0 , 255.255.240.0 , 255.255.248.0 , 255.255.252.0

255.255.255.192 , 255.255.255.224 , 255.255.255.240 , 255.255.255.248 ,

255.255.255.252

What would happen if we made the subnet mask on the TR side at 255.255.252.0
and leave the ethernet side at 255.255.0.0.

I have read several RFC's and they lead me to believe that this can be done
but everyone that I've talked to has lead me to believe that this wont work!

Is my understanding correct or am I just totally off base?

Anyone have any better ideas?

We currently have No subnetting on campus!

Please Email responces and I'll forward or post depending on how much interest!

ben@datacomm.ucc.okstate.edu


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 92 15:58:34 EDT
From:      sbk@vax5.cit.cornell.edu
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP for DOS

I'm interested in this, too.  I have been querying the ARCHIE servers for	
SNMP (yes, this results in A LOT of hits); haven't found any discussion of	
SNMP under DOS yet.

--sk



In article <1992Jul7.114842.3022@aristo.tau.ac.il>,
shani@GENIUS.TAU.AC.IL (Oren Shani) writes: 
> Hello
> 
> I would like to thank all those who answered my posting about MIT SNMP package.
> 
> I wonder if there is a similar package for DOS/Windows. I am not much femiliar
> with the DOS world (wow! I must be the only person in the world who isn't :) ,
> so I prefer things that where tested and known to be useful.
> 
> I would like to have pointers to commercial packets, if there are any, too.
> 
> Thanks in advance,
> 
> 
> 
> 
> -- 
>     __    __  Oren Shani (shani@genius.tau.ac.il) 
>    /  /  /    Faculty of Engineering, Tel Aviv university
>   /  /   --   Israel
>  /__/ . __/ . "Hold your temper" -- The caterpillar to Alice

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jul 1992 12:56:40 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Query re. transition to CLNP

The last Communications Week reports that IAB has issued a draft
recommendation calling for CLNP as a replacement/fix for the current IP
addressing scheme, and that they seem to be in a great hurry in making it a
mandatory standard. I haven't seen much discussion here (maybe it's even a
wrong group?); could someone more enlightened give me more information
about this? Describe the likely transition problems? Point towards existing
RFC's? Thanks so much!    E.
-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 92 14:37:51 GMT
From:      cen@engr.ucf.edu (Christopher Nichols)
To:        comp.binaries.ibm.pc.wanted,comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.bsd
Subject:   Need an LPD server for an XT

We are in the need of an print server to on an XT to allow both PC's and
Unix boxes to print to a Laserjet....  The PC's are using the Clarkson
packet drivers and we have LPR from NCSA.  The Unix machines range from
SGI machines to Motorola VME systems.  I already downloaded the LPD
server that is based on the KA9Q software, but have had all kinds of
problems with it and have never been able to get it up and running.  Any
help with this will be greatly aprreciated

Thanks
Chris Nichols
cen@engr.ucf.edu

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jul 1992 15:50:13 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Query re. transition to CLNP

> The last Communications Week reports that IAB has issued a draft
> recommendation calling for CLNP as a replacement/fix for the current IP
> addressing scheme, and that they seem to be in a great hurry in making it a
> mandatory standard. I haven't seen much discussion here (maybe it's even a
> wrong group?); could someone more enlightened give me more information
> about this?

Right, this is not the correct list.    The recommendation has produced a
storm of controvery on the IETF mailing list (info on mailing lists at the  
end of the note).  Various IETF members (myself included) have expressed
strong concerns about the technical rational for the decision, whether proper
IAB/IESG processes were observed, and the implications (in terms of
future work) of the IAB's goal of joining with ISO to manage future
revisions of CLNP.
 
The recommendation can be anonymously FTPed from a number of sites which
support internet drafts.  These include ftp.nisc.sri.com and nnsc.nsf.net --
there are other sites in Europe and Asia.  The file is: 
     
    internet-drafts/draft-iab-ipversion7-00.txt
    
Debate is actually raging on more than one list:

    * the IETF list (ietf-request@isi.edu) is where folks are commenting
        on the IAB announcement (both technical and non-technical comments) 
         
    * the BIG INTERNET list (big-internet-request@munnari.oz.au) is where
        detailed technical discussions of the IAB proposal and other
        proposals such as Nimrod, PIP, EIP and IPAE are being held.
         
Craig Partridge
craig@bbn.com

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jul 1992 16:35:05 GMT
From:      ylee@syl.dl.nec.com (Ying-Da Lee)
To:        comp.protocols.tcp-ip
Subject:   Re: Query re. transition to CLNP

ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes:

>The last Communications Week reports that IAB has issued a draft
>recommendation calling for CLNP as a replacement/fix for the current IP
>addressing scheme, and that they seem to be in a great hurry in making it a
>mandatory standard. I haven't seen much discussion here (maybe it's even a
>wrong group?)

Hop over to group info.ietf and watch the fireworks there
as the result of that IAB draft.  I haven't seen anything
that lively before.

The discussion is still going on though the temperature
has dropped quite a bit.  Judging from the reactions so
far, I'd say that the IAB's hope to get this issue settled
fast (stated by at least one IAB member as a reason for
this action) is not turning out the way they expected.
So 'CLNP as IPv7' is not a done deal, and my speculation
is that even if/when it is adopted, it will be a very different
CLNP from the one that the world has known and loved/hated.

	Ying-Da Lee	(214)518-3490	(214)518-3552 (FAX)
	Principal Member, Technical Staff
	NEC Systems Laboratory, C&C Software Technology Center /
	NEC USA, Corporate Network Administration Division
	ylee@syl.dl.nec.com	uunet!necbsd!ylee

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 92 17:12:08 GMT
From:      paul@tivoli.UUCP (Paul Greenspan)
To:        comp.protocols.tcp-ip
Subject:   Help With sockets -> TLI.

Hi,

I'm in the middle of converting a rather complex application from sockets
to TLI.  While Richard Stevens book has provided an excellent start,
I'm looking for something that goes into more depth.  It would also
be helpful to obtain a large sample program.

I would really appreciate any suggestions.  It may help me keep my job. :)

Paul

-- 
Paul Greenspan              paul@tivoli.com 
Tivoli Systems              6034 West Courtyard, Suite 210
Austin, Texas  78730        (512) 794-9070  /  FAX (512) 794-0623

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jul 1992 22:28:40 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Re: Query re. transition to CLNP

Thanks a lot for the pointers, and apologies for cluttering a wrong group
(I hope this won't spark any fireworks here!!!    Eric

-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 92 22:58:25 GMT
From:      brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein")
To:        comp.protocols.tcp-ip
Subject:   Summary of TAP discussion

No justification of the IESG's response to my 18 April 1992 request---
I asked that at least a working group be set up to finish TAP, and the
IESG said no because of ``duplication of effort.'' No honest admission
that Ident is not compatible with current use of TAP. No action. That's
the quick summary.

I have set up a mailing list, tap-std@kramden.acf.nyu.edu (subscriptions
to tap-std-request), to finish TAP, since StJohns has refused to allow
TAP discussion on the Ident list and Crocker has thrown me off the SAAG
list. What would it take to set up tap-std as an IETF working group?

Anyway, I promised a summary of the discussion of ``informal notice of
two IESG decisions.'' As one might expect, many people expressed many
opinions on all sides of the issues---my side, Kent's side, the ``I
don't know but I want an explanation'' side, even some sides I had never
thought existed. I'll set up an archive of the discussions for anonymous
ftp. What's most interesting is what *wasn't* said.

* None of the principals denied anything I said. I'm glad that there's
no disagreement on the facts of this case.

* Nobody admitted that Ident, the IESG's current effort at an RFC 931
revision, is simply incompatible with current use of TCP port 113.

* Steve Crocker didn't admit his blatant conflict of interest. Crocker's
company, TIS, has a contract with RSADSI to develop PEM software; ever
since RSADSI was formed I've been doing everything I can (legally) to
interfere with its disgusting monopoly over public-key cryptography.

(Specifics: I have argued in many forums against software patents. I
have talked with several government agencies about the problems of
software patents; I'm cited in the OTA's recent report for this. I have
argued with Jim Bidzos, RSADSI's head, in public, and have criticized
Bidzos's actions and positions in public. I have acted as a center for
complaints about RSADSI as well as for information useful in getting
around RSADSI's monopoly.)

It was only a week ago that I found out about Crocker's connection with
RSADSI. I've tried to reach Phill Gross to ask whether Crocker admitted
his financial interest to the IESG; Gross has avoided my calls. So, to
sum up, we have Crocker in a position to destroy a protocol which I
support---a protocol which, in his eyes, competes with PEM, in which he
has a financial interest.

* Nobody gave any reasons why the IESG hid its decisions from the
community except ``we didn't mean RFC 1310 that way'' and ``we want to
save the author embarrassment.'' It is obvious to me that, if the author
asks, the IESG should be required to publish the reasons for its
decisions; and what does RFC 1310 mean by ``final review by the
community'' if the IESG never gives the community a chance to reverse a
bad decision? But I will drop this issue for now.

* Nobody explained why the IESG based its decisions on senseless
criteria not listed in RFC 1310. In particular, the IESG rejected my 18
April 1992 request on the basis of ``duplication of effort.'' Nobody
explained this action. This is a critical issue and it's been ignored.
Why?

* Nobody said what the IESG *really* wanted. Some people guessed that
``the IESG is trying to discourage a bad protocol.'' But the fact
remains that the IESG supports the Ident WG's effort to standardize a
protocol also derived from RFC 931. So much for the ``bad protocol''
theory.

* Nobody took me up on my offer---which has been open since March---to
place the TAP spec into the public domain. I can only conclude that all
the posturing about copyright issues was pure rhetoric.

* Other than a tiny message from Phill Gross---which didn't answer any
of my charges---there has been no official comment on TAPgate. And the
message from Gross addressed only my 15 July 1991 request, not my 18
April 1992 request. Smells like a cover-up to me. (The only content to
Gross's message was the statement that SAAG didn't think TAP was a good
authentication protocol. What Gross fails to admit is that TAP doesn't
make *any* claims as to security. It does *not* pretend to be a security
protocol.)

* Nobody mentioned the slightest thing about an Ident meeting, or any
other relevant meeting, at the Boston IETF, until Phill Gross's message
yesterday. Mike StJohns hasn't said a word about any such meeting on the
Ident list. Isn't it a bit late to be organizing this?

End of summary.

To everyone who suggested that I publish TAP as an informational RFC:
I've considered that, but every time I've asked an IAB or IESG member
either (1) what it would take to publish TAP this way or (2) whether
Informational status would really be appropriate for TAP, I've received
no response. So much for that. Thanks for the suggestion, though.

And to those who suggested that maybe the IESG simply made a mistake:
Wise up. Between March and June I sent several complaints to Cerf, the
IESG, et al. They had far too many chances to quietly correct their
behavior. Maybe if they had tried to be constructive we wouldn't be
having this public war.

---Dan

P.S. My original offer, at the end of March, to Crocker and StJohns,
since Rob Thurlow asked:

: I understand and appreciate the view that all standards documents should
: be free for the IETF to change. I will declare my authd protocol spec
: public domain if you two swear, on your honor, that you will make sure
: that the views of the user community are accurately reflected by the
: standard; that you will not claim to be documenting the protocol in use
: within the Internet community unless, in fact, you are doing so; and
: that you will give me the chance to remove my name from anything you
: publish. Is that reasonable?

They didn't agree. My offer is still open for Vint Cerf.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jul 1992 23:26:09 GMT
From:      norstan@oar.net (Steve Frazier)
To:        comp.protocols.tcp-ip
Subject:   MX Records and Nameserver Setup

I would like to understand how to set up all the files to provide 
name service from our machine.  I have RTFM (SCO Unix) but there
isn't enough information.  Would someone be willing to take examples
from their existing system and note what files I would need and what
each line does in each file?

Please email me, please sfrazier@eng.norstan.com, as I don't read this
news group on a regular basis, if anyone is interested in what I get I
will be glad to post or email my results.

Thanks in advance.

Steve
sfrazier@eng.norstan.com

  


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 1992 02:00:08 GMT
From:      robertj@mars (Robert Jongbloed)
To:        comp.protocols.tcp-ip
Subject:   KA9Q & PPP, almost working but not quite.  Help!


I have been trying to get a KA9Q NOS to PPP link going. It gets close
but does not complete the connection. Its very frustrating because it
actually gets part of the way through...

The link is between a MS-DOS PC and a Sparcstation running SunOS 4.1.1 
using a V22bis MNP 4 modem. The serial link also passes through a
terminal server and Ethernet LAN to get to the Sun. This I originally
thought would be a problem, but the PPP link does get part way through.
If this was a problem I would imagine that it would not even get that
far. I could be wrong though, I often am.



Here is the NOS startup script, basically a rewrite of the samples
provided in the package:

isat on
attach asy 0x2f8 3 ppp modem 4096 1500 4800
dial modem pleiades.ppp 10 3
ppp modem quick
ppp modem lcp open
ppp modem ipcp open
route add default modem
ip ttl 32
tcp mss 1460
tcp window 2920
domain addserver 134.148.96.105
domain suffix newcastle.edu.au
domain cache clean on
start echo
start discard
start ttylink
start ftp
start finger


The dial script does all the phone dialling, logging in etc and finally
runs the PPP programme (from Carnegie Mellon) using the command

ppp 134.148.96.105:134.148.96.248

The IP number 134.148.96.105 is the Sun that the ppp programme is running on
and 134.148.96.248 is the number for the remote site (the DOS PC).


At this point there is flurry of traffic in both directions (looking at the
Rx/Tx LEDs on the modem) and then just the Rx LED flashes occasionally. That
is the Sun sends something to the PC once every 5 seconds or so.

Checking out the status in the KA9Q NOS programme yields:

net> ppp modem
Network Protocol Phase  (open for 0:00:00:42)
       692 In,          22 Flags,     0 ME,      0 FE,      1 CSE,      2 other
                     2 Lcp,     0 Pap,    19 IPcp,     0 Unknown
       118 Out,          7 Flags,     0 ME,      0 Fail
                     8 Lcp,     0 Pap,     5 IPcp
LCP Opened
                 MRU     ACCM            AP      PFC  ACFC Magic
        Local:   1500    0x00000000      None    Yes  Yes  0x65ab01b2
        Remote: +1500   +0x00000000      None   +Yes +Yes +0x7e51d35b
PAP Closed
        Message: 'none'
IPCP Remote host accepted our request; waiting for remote request
        local IP address: 134.148.96.248  remote IP address: 134.148.96.105


Which indicates that the connection is partially successful. The LCP is open
and its parameters negotiated. The IPCP has sucessfully got the IP addresses
from the Sun and there are no failed packets in either direction. If left for
a while the number of packets In increases, so the data is getting through
uncorrupted. The problem would seem to be a setup/configuration of something
somewhere.


OK, theres the problem, any ideas anyone??

Thanks in advance.
--
 -----------------------------------------------------------------------------
 Robert Jongbloed              | University, where the real world is something
 robertj@mars.newcastle.edu.au | to be understood but not be a part of. 
 -----------------------------------------------------------------------------

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 1992 02:33:36 GMT
From:      bjork@telebit.com (Steven Bjork)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   RIP 2 and multi-tree nets was Re: Subnetting for Novell routing.

In article <1992Jul8.232740.1395@novell.com> donp@novell.com (don provan) writes:
>In article <1992Jul8.123207.57124@cc.usu.edu> jrd@cc.usu.edu writes:
>>In article <1992Jul8.164456.6043@novell.com>, mcollins@novell.com (Marty Collins) writes:
>>> You can use different subnet masks on a Netware Server but you have to
>>> be carefull about the addressess.
>>>
>>	According to local experiments and the gospel according to Don Provan,
>>who ought to know, NW 3.11's TCPIP.NLM supports only a single subnet mask
>>for all boards.
>
>Woah!  I happen to know this Don Provan fellow, and he never would have
>said that intentionally.  What he might have said is that 3.11's TCPIP
>NLM supports only a single subnet mask *for subnets of the same network*.
>If the boards are connected two different IP networks, two different
>class A networks, perhaps, or a class A and a class B network, then
>different masks can be bound to each board without any difficulty.
>
>What isn't supported is two subnets of the same IP network being given
>different masks.  And if asked about what i meant by "not supported", in
>secret i might whisper that it means it works, but it probably not quite
>the way you'd expect, and Novell certainly didn't want to try to document
>it or accept tech support calls about configurations that use it.


This is correct, the limitation is *not* Novell, it is in the underlying
routing protocol, that being defined in RFC 1058 (RIP 1).

There is a draft to extend RIP to include network mask information.
This draft is available for anonymous FTP from nri.reston.va.us,
title draft-ietf-malkin-rip-03.txt. This is being called RIP 2.

The implementation of RIP 2 would help stay the dire "imminent address
exhaustion" of the Internet :). 

If RIP 2 was combined with the ability to have discontiguous subnets,
then network admins would smile more often. Oh, a discontiguous subnet
is where your network is at location a, b, and c, and the path to
each portion of your network (net 10, for example) involves someone
else's backbone. Stated another way, a class of net no longer would
need to be based as a single tree. 

--Steven

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 1992 05:59:14 GMT
From:      mpja@jyu.fi (Markku Jaatinen)
To:        comp.protocols.tcp-ip
Subject:   Packet driver for Intel EXP16 ?


Hello !

I'm looking for a packet driver for Intel's EtherExpress 16 card.
Is there a special driver for it or could i use something else
instead ?

Thanks !

Markku Jaatinen
University of Jyvaskyla
Finland
Internet E-mail: mpja@tukki.jyu.fi

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 1992 08:34:08 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks esq.)
To:        comp.binaries.ibm.pc.wanted,comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.bsd
Subject:   Re: Need an LPD server for an XT

In article <1992Jul8.143751.1633@cs.ucf.edu>, cen@engr.ucf.edu (Christopher Nichols) writes:
> We are in the need of an print server to on an XT to allow both PC's and
> Unix boxes to print to a Laserjet....  The PC's are using the Clarkson
> packet drivers and we have LPR from NCSA.
 [..]
> I already downloaded the LPD
> server that is based on the KA9Q software, but have had all kinds of
> problems with it and have never been able to get it up and running.  Any
> help with this will be greatly aprreciated

	I have managed to get the KA9Q-based LPD to work, but only using
LPR applications from a DECstation and FTP Incs LPR client. The LPR
clients with CUTCP (latest ver (2.3?) and 2.2D), NCSA and Waterloo TCP
packages don't want to talk turkey. I've tried tracing the packets with
an analyzer, but I can't detect any significant differences, and I'm not
too familiar with the internals of the LPR protocol anyway.
All of these were tested using a postscript file printing to a HP
LaserJet II w/ postscript cartridge - the exact same file in all cases.
	Has anyone got the KA9Q LPD to print using the LPR that comes
from any freeware package?



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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 92 10:54:11 GMT
From:      wmchung@eng.ie.cuhk.hk (chung wai man)
To:        comp.protocols.tcp-ip
Subject:   TCPIP source code

I have come across an article subjected "TCPIP Source Code" posted by 
Mr. Ken Hardy. But unfortunately I cannot read it since it is expired in 
my system. 

I am interested if I can get the TCPIP source code. If it is really this, 
can you tell me about that article if you have read it or the author
, Mr Hardy, I would be grateful if you can inform me.

I hope a direct reply. My addr: 
wmchung@ieug33.ie.cuhk.hk

Best Regards,
W.M. Chung

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 92 12:44:46 GMT
From:      brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein")
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

It's a conflict of interest, Crocker. Your company has business dealings
with a company which I have vowed to destroy. Do you deny that SAAG is
concerned with TAP's possible competition with cryptographic protocols?

  ``I am concerned that if we were to progress the RFC it would be
  interpreted as being suitable for authentication, in lieu of the
  other, higher assurance mechanisms now under development.'' (Steve
  Kent, last December.)

Do you deny that PEM is a ``higher-assurance mechanism''? Do you deny
that TIS has a financial interest in the future of PEM?

You can't have it both ways. SAAG has held TAP back for a year with the
excuse that TAP could delay widespread use of cryptographic mechanisms.
Now that we've discovered that you have a *financial* interest in those
cryptographic mechanisms, are you going to lie about SAAG's position?

An honest man with a conflict of interest will admit the conflict and
take steps to remove himself from the position of difficulty. In this
case that is the position of controlling TAP's future. Remove yourself!

All your rhetoric about ``the overall operation is strongly driven by
consensus'' can't justify your actions. You singlehandedly replaced me
with StJohns as chairman of the effort. Then StJohns, without checking
with the Ident group, cut the TAP document out of Ident's agenda. And
then you threw me off the SAAG mailing list.

That's not how consensus works! An honest man doesn't attempt to achieve
``consensus'' by cutting his opponents out of the process. Nor does he
abuse a position of power just so that he doesn't have to listen to
something he disagrees with. People working towards consensus normally
state their concerns and build on top of each other's suggestions,
incrementally. Your actions have been anything but incremental.

You say ``The ident spec is close to complete and should soon be ready
for advancement to Proposed Standard.'' Weird: According to Phill Gross,
you said exactly the same thing two months ago. Neither time have you
presented specifics to back up this claim. So how about I present
specifics: There are twice as many complaints about the current Ident
draft now as there were two months ago (even ignoring my objections).
Two weeks ago I sent Ident a list of 73 unresolved problems; by now 6 of
them---under 10%---have been settled. The auditing restriction issue,
which has been identified by both sides as crucial, has made zero
progress.

Most importantly, nobody has any implementation experience with Ident.
IDENT IS NOT COMPATIBLE WITH CURRENT USE OF TCP PORT 113. Do you deny
this, Crocker? I will never support any attempt to cripple TAP by
``standardizing'' a quite different protocol which uses the same port.
(StJohns refuses to change the port number. Why?)

And Mike StJohns *still* hasn't said anything about an Ident meeting at
the Boston IETF. How can the working group be expected to finish its
document when the working group chair neglects even his most basic duty:
organizing meetings? (``Pssst, Steve, how about the five of us get
together and hold a dummy meeting to finish crippling the protocol.
Don't worry, I won't mention it to the working group, so nobody who
objects will show up.'')

---Dan

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 92 14:00:53 GMT
From:      rae@rsvl.unisys.com (Rick Erickson x2132)
To:        comp.protocols.tcp-ip
Subject:   UDP Checksums ??

I noticed a problem in our network and I'm wondering if anybody knows how its
supposed to work. The problem is this: host A is sending a UDP datagram to all
hosts on the local network, using a directed broadcast, i.e. 192.61.5.255.
Host A's IP layer translates that to a limited broadcast, i.e. 255.255.255.255.
Host B receives this datagram but the checksum check fails because the 
destination address used in the checksum check is different than the
destination address used in the checksum generation by host A. Could it be that
directed broadcasts should not generate/check checksums?

Rick Erickson
UNiSYS Corp.


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 92 14:48:03 GMT
From:      crocker@TIS.COM (Stephen D Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

Dan Bernstein made several claims in his last message including some
accusations about my conflict of interest.  I normally don't respond
to most of his charges, but it's worth adding a brief response to
the record.

Dan wrote:

	* Steve Crocker didn't admit his blatant conflict of interest.
	Crocker's company, TIS, has a contract with RSADSI to develop
	PEM software; ever since RSADSI was formed I've been doing
	everything I can (legally) to interfere with its disgusting
	monopoly over public-key cryptography.

	It was only a week ago that I found out about Crocker's
	connection with RSADSI. I've tried to reach Phill Gross to ask
	whether Crocker admitted his financial interest to the IESG;
	Gross has avoided my calls. So, to sum up, we have Crocker in
	a position to destroy a protocol which I support---a protocol
	which, in his eyes, competes with PEM, in which he has a
	financial interest.


The actual situation is the following.

Trusted information Systems, Inc (TIS) has a DARPA-funded contract for
R&D in network security.  Part of this work includes producing a
reference implementation for privacy enhanced mail (PEM).  The
reference implementation ("TIS/PEM") is nearing completion and will be
widely distributed to the Internet community.  The implementation
includes software supplied by RSADSI.  TIS has a license from RSADSI
to include that software in the distribution.  Per longstanding
agreement between DARPA and RSADSI, RSADSI is supplying that software
free of charge.  No other arrangement between TIS and RSADSI is
involved in bringing out the reference version of PEM.

In addition to the above, TIS has two other relationships with RSADSI.

- For possible commercial products based on RSADSI technology, TIS is
  a licensee of RSADSI.  (No specific products have been announced
  yet.)

- TIS expects to be one of the Policy Certification Authorities for
  the certificate issuing hierarchy for PEM.  The authorization is
  controlled by the Internet Society, but in addition to the basic
  authority from the ISoc, TIS expects to have a license from RSADSI
  to sell certificates.  (RSADSI has rights to certain classes of
  certificates that contain RSA keys.)


I am a vice president of TIS and directly in charge of these projects
(among others).  I also serve as Area Director for Security in the
IETF and oversee the standardization of security-related protocols.
As most readers of these mailing lists know, within the IETF we have a
sizable roster of security activities.  PEM is just one of several key
developments under way.


Dan Bernstein's sentence, "So, to sum up, we have Crocker in a
position to destroy a protocol which I support---a protocol which, in
his eyes, competes with PEM, in which he has a financial interest."
packs multiple falsehoods into one sentence.  The facts are:

o Area Directors don't have the power to "destroy a protocol."  As AD,
  I can do various things that affect the process and content, but the
  overall operation is strongly driven by consensus.

o Far from attempting to destroy the protocol, I have consistently
  supported having an identification protocol.  Not everyone in the
  community agreed this was appropriate, and I used the relatively
  modest room I have as AD to advocate we proceed with standardizing
  the protocol.

o PEM is not competitive with RFC 931, Ident, TAP or any variant of
  these protocols.  PEM provides one set of capabilities; Ident, et al
  provide another.



The attack on me, others and the process is mostly beside the point.
The heart of Dan Bernstein's complaint is he unhappy with his effort
to standardize his revision to RFC 931.  Although the IETF agreed to
accept the idea of standardizing such a revision, a number of changes
needed to be made, including accurate characterization of what the
protocol is -- and is not -- useful for.  Mr. Bernstein did not agree
with changes, and he has refused to cooperate with this aspect of the
standards process.  His refusals to cooperate have included strongly
worded messages sprayed to large mailing lists, development of
competitive specs, various lobbying efforts, and appeals to the IETF
chair (Phill Gross) and the IAB chair (Lyman Chapin).  These efforts
have not provided Mr. Bernstein the satisfaction he has sought, and it
is evident he is continuing his campaign.

All of the substantive issues concerning the content of the protocol
and the process of standardization have been dealt with extensively
over the last many months and are adequately documented on the ident
mailing lists.  The ident spec is close to complete and should soon be
ready for advancement to Proposed Standard.  Readers interested in the
emerging standard are encouraged to join the ident mailing list
(ident-request@nri.reston.va.us).



Steve Crocker
Vice president, TIS
IETF Area Director for Security

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 92 14:50:10 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Managing an Extended Ethernet


Our campus contains over 500 Ethernet hosts of every
conceivable description, age, and operating condition.  We,
presently, have one FDDI backbone whose topology was based on
the layout of the telephone system and is a pair of counter-
rotating rings.  Administrative domains are, often, spread
out over multiple buildings and we must support Ethernet
communication between any two points on the campus regardless
of the protocol being used.  Presently, all local Ethernets
connect to the backbone through bridges.
     Ever so often, the topic of subnetting our class B
Internet number comes up and there are extremely
knowledgeable people who have perfectly valid arguments both
for and against subnetting.  The latest restart of this
discussion was due to the fact that we also have a campus-
wide Token-Ring network and we would like to allow any user
who wants to to run TCP-IP over the Token-Ring.
     Most of us feel that, for our situation, subnetting
would introduce as many problems as it solved.  There is also
a viewpoint that subnetting would make network management
easier.  As if there weren't enough things to consider, we,
like most other educational institutions are in an almost
constant budget crunch.  We must provide the campus and
university community the most flexible network we can.
     I would like to hear from those who have handled a
similar situation and how satisfied they are with the
results.  While we will have to decide for ourselves, whether
subnetting would really make things better in the long run, I
would like to hear war stories, preferably from network
administrators who have very little control over what end-
users wish to connect to the Ethernet.  We, very much, want
to preserve the diversity of protocol which is presently
possible over our entire campus.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 1992 15:54:05 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet

Greetings, you net.people:

Now I KNOW this has been asked numerous times and I KNOW I've seen responses
posted in the past, but I'm suffering from a massive brain-cramp and I need
an answer to a question: What is the latest version of NCSA Telnet for both
DOS and Macintosh machines? Also - where can I find it via anonymous FTP? The
sites I know of where I've seen it in the past either don't have it anymore
or have older versions (2.2, etc.).

E-mail responses are okay - I don't want to tie the newsgroup up.

Thanks, folks,

Walt

-- 
 Walter R. Trachim		  |The measure of a person's life shouldn't be
 UNH Telecom and Network Services |how much they accomplished; rather, it 
 Durham, NH 03824                 |should be whether or not their deeds helped
 Walt_Trachim@unh.edu             |others along the way.         --WRT

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 92 16:44:09 GMT
From:      alfonso@mtecv2.mty.itesm.mx
To:        comp.protocols.appletalk,comp.protocols.misc,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Information about routers, gateways and so on required


  Hello!

  I'm experimenting with a software call PCRouter, that acts as a gateway between Local Talk and Ethernet networks using TCP/IP. This software is public domain and I'd like to know if there's a commercial more complete version of this product or if there's a product that can do the following:

  - Provides KIP protocol, to give internet addresses to Macs, so that the TCPort software I'm using on them can work. (PCRoute does not provide this facility)

  I'm using Fast Paths as gateways. Fast Path manages KIP also. I'm experimenting with PCRoute in order to see if it can be a replacement fot Fast Path (cause I use a lot of them and it is very critical if any of them malfunctions... I use'em in a network comprising over 200 Macs with PC's as servers, this is for the registration process of the university I'm working for.

 So, what I need is a software that provides KIP or a software that does both things I get from a Fast Path: KIP and routing.

  Thamks

  Alfonso Trevino
  alfonso@mtecv2.mty.itesm.mx

P.S.: I'll be on vacation for 2 weeks, so if I don't answer right back, don't worry.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jul 1992 18:06:55 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

>It's a conflict of interest, Crocker. Your company has business dealings
>with a company which I have vowed to destroy.

	Children, children, children....

	PLEASE go play OUTSIDE!
mjr.
-- 
"3. Since telecommunication switching systems contains mega lines of code
   (our present [deleted] system has 6 Mega lines of code) we must assume that
   there will be thousands of bugs."

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 92 19:31:26 GMT
From:      atul@yoko.rutgers.edu (Atul Sharma)
To:        comp.protocols.tcp-ip
Subject:   Buffer Management for a Network Interface Driver.

Hi!

I am writing an S-Bus network interface driver, between IP and a new 
network switch. IP sends the packets as linked list of mbufs. The 
hardware supports DMA controller L64853A. My impression is that this
chip doesnot support "gather write, scatter read". Although it allows
DMA, starting at any virtual address within a 16Mb boundaries.

I have a set of questions given the above scenario:

1. Is it possible to avoid copying of mbuf's and at the same time 
perform DMA ? (It seems doubtful. But still I asked)

2. If the hardware allows any virtual adress as the starting DMA adress,
like in this case, does the operating system (SunOS) disallow it and 
forces DMA to take place only in the address space got by the routine
"mb_mapalloc()"?

3. Does "mb_mapalloc()" ensure the virtual address space allocated is within
16mb range? Are there any other ways to ensure falling under this range,
say through "kmem_alloc()"?

Any response: ridicule, appreciation, helpful hints, shall be very welcome.
Thanks.

-Atul
----------------------------------------
atul@paul.rutgers.edu
{backbone}!rutgers!paul.rutgers.edu!atul

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1992 23:27:06 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

In article <9207091448.AA26493@TIS.COM> crocker@TIS.COM (Stephen D Crocker) writes:
>o PEM is not competitive with RFC 931, Ident, TAP or any variant of
>  these protocols.  PEM provides one set of capabilities; Ident, et al
>  provide another.

I think this is an important point that should be emphasized: these
protocols complement each other.  PEM can be used to detect forgery, but
that's about it.  Once you've determined that a piece of mail was forged,
it doesn't provide any mechanism to track down the forger.  Also, PEM only
helps when it's used; if you receive a piece of mail that isn't encrypted
or signed using PEM, it could either be an attempted forgery or the sender
might have forgotten to encrypt it.  And unless you were expecting the
message to be PEM'ed, you may not even think to question its authenticity.

TAP-like protocols, on the other hand, are useful when you're trying to
trace things.  The SMTP server could put the information it receives from
TAP into a header field, and suspicious users could configure their mail
readers to flag messages where this field contains an unexpected value
(e.g. something other than root at the last relay or the original author).

In the past I've publicly spoken against these identity protocols, because
they're useless against attacks from personal workstations.  However, if
the administrators are careful to understand their limitations, they're
certainly better than nothing.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 92 00:15:11 GMT
From:      smb@ulysses.att.com
To:        comp.protocols.tcp-ip
Subject:   Re: New mailing list: tap-std


	 I am pleased to announce the formation of the TAP-std working group

Working group?  Working groups are typically subgroups of some larger
organization.  Which organization established this working group?

	 The charter of TAP-std is as follows: ``This group is chartered to
	 document the TAP protocol as used on TCP port 113 around the Internet.

Chartered?  Chartered by whom?

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jul 1992 01:38:43 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.sys.mac.comm,comp.sys.mac.apps,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Notes on MacTCP - revision 1.0

[Note followups]

I have just released a new revision of my notes describing MacTCP
configuration, Macintosh applications which rely on MacTCP, and basics of
Internet file transfers.

The file is available from the following sources:
sumex.stanford.edu:       /info-mac/report/mac-tcp-info.txt
spider.math.ilstu.edu:    /pub/mac/mac-tcp.txt

The second site has the most recent version of the document, as well
as a few other files which might be of interest to you. On the other hand,
it is a very small mail machine used by two dozen people, so  please treat
it gently!        :-)

If you don't have access to ftp or don't know how to use it, drop me a
note and I will mail the file directly.

If you want to be added to my mailing list for announcements of future
revisions, and you haven't received a note from me this time (meaning
that you aren't on the list now), let me know by mail.

E.

-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 92 02:38:36 GMT
From:      timb@ksgbbs.harvard.edu (Tim Buehrer - 625-6829)
To:        comp.protocols.tcp-ip
Subject:   Is there a rarp server that runs under SCO XENIX?


We are currently using the PC based rarp server from the university of florida
and are quite happy with it.  However, it does require that we have an extra
box lying around.  Is there a similar rarp server that will dynamically allocate
ip addresses available for unix boxes?  In particular, I am interested in one
that will compile under xenix.  My apologies if this is the wrong group to 
post this message.

Tim Buehrer
timb@ksgbbs.harvard.edu

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 92 06:57:36 GMT
From:      robert@peregrine.peregrine.com (Robert Young)
To:        comp.protocols.tcp-ip
Subject:   Question on ping


 I have a most interesting situation that I hope some of you can explain:

The scenario is as follows:

	A P2/2 55SX PC running OS/2 (with Communication Manager) plus
	LAN/WORKPLACE for OS/2 (Novell).
	Lanworkplace gives us the TCP/IP connectivity.
	We are able to ping all of our systems except for two.
	Our network comprises of both Token-ring and Ethernet with our
	Novell server acting also as a router between the two networks.
	This PC can ping all the systems on the Ethernet and other PC's
	(running TCP/IP) on the token-ring BUT it cannot ping an RS600
	system (which has both a token-ring and an ethernet card).
	What would cause ping to work on all machines but the RS600?
	Mind you the RS600 can ping all other systems (except that PS/2 55SX)
	all other systems can ping the RS600.
	So it must something common to both systems.
	Any ideas?
	Isn't ICMP used to carry the ping signal?
	Could it be that the same frame type used to carry the IP packets is
	not being used?

	Thanks for any pointers.



-------------------------- X**2 + YY**2 = C**2 -------------------------
Robert Young
(Peregrine Systems, Inc)
robert@peregrine.com
uunet!peregrine!robert
-------------------------- X**2 + YY**2 = C**2 -------------------------

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 92 07:02:31 GMT
From:      robert@peregrine.peregrine.com (Robert Young)
To:        comp.protocols.tcp-ip
Subject:   Re: Query re. transition to CLNP

In article <1992Jul08.125640.16795@rs6000.cmp.ilstu.edu> ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes:
>The last Communications Week reports that IAB has issued a draft
>recommendation calling for CLNP as a replacement/fix for the current IP
>addressing scheme, and that they seem to be in a great hurry in making it a
>mandatory standard. I haven't seen much discussion here (maybe it's even a
>wrong group?); could someone more enlightened give me more information
>about this? Describe the likely transition problems? Point towards existing
>RFC's? Thanks so much!    E.
>-- 
>Eric Behr, Illinois State University, Mathematics Department
>Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

Yeah. I also read it on the 7/6/92 edition.
Also, they do not plan to give too much time for decisions.
They seem to be ready to decide in two weeks?
Another proposal considered was "IP Address Encapsulation.
Yet another was the "P protocol"

Would anyone care to elaborate on these proposals?
Any vendors out there care to comment (HP, NOVELL, IBM, etc)?



-------------------------- X**2 + YY**2 = C**2 -------------------------
Robert Young
(Peregrine Systems, Inc)
robert@peregrine.com
uunet!peregrine!robert
-------------------------- X**2 + YY**2 = C**2 -------------------------

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 92 08:19:33 GMT
From:      sinz@informatik.uni-stuttgart.de (Werner Sinz)
To:        comp.protocols.tcp-ip
Subject:   ST-II protocol (RFC-1190) for RS/6000


Hello net,

we intend to use the ST-II protocol (RFC-1190) for transmission of multimedia-
data. We have got the sources of the ST-II protocol from BBN (Bolt Beranek and
Newman Inc.) and SICS (Swedish Institute of Computer Science).
Both products are written for SUN-OS. We have IBM-RS/6000 machines.
Therefore my question :

"Has anybody ported an ST-II implementation (BBN or SICS or ...) to an IBM-
RS/6000 or do ST-II implementations exist written for the RS/6000 resp.?"

Please reply directly to me or post the reply to this group.
Thank you very much

Werner Sinz

-------------------------------------------------------------------------------
Werner Sinz                 | email: Werner.Sinz@informatik.uni-stuttgart.de
Universitaet Stuttgart      |
- IPVR - Verteilte Systeme  | Tel.:  (+49) 0711/7816-477
Breitwiesenstrasse 20-22    | Fax:   (+49) 0711/7816-424
D-7000 Stuttgart 80         | 
Germany                     |
-------------------------------------------------------------------------------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 92 15:21:38 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion


brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein") writes:
>It's a conflict of interest, Crocker. Your company has business dealings
>with a company which I have vowed to destroy.

Perhaps the political parts of this discussion could be moved to an alt.*
group.  I think we all recognize some personality conflicts and a
non-uniform application of the standization process.  Gentlement, you 
have made your points.  No one would think less of the involved parties
if they stopped posting on the subject (maybe I should have worded that
differently.)

But one implementational issue does bother me:
>
>Most importantly, nobody has any implementation experience with Ident.
>IDENT IS NOT COMPATIBLE WITH CURRENT USE OF TCP PORT 113. 
>

Since TAP is used quite widely on the Internet, I would prefer to see
it remain on port 113.  Let's have IDENT on a fresh new port, we still
have a few unused ones left.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jul 1992 15:52:36 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Checksums ??

In article <1992Jul9.140053.29821@rsvl.unisys.com> rae@rsvl.unisys.com (Rick Erickson x2132) writes:
>...host A is sending a UDP datagram to all
>hosts on the local network, using a directed broadcast, i.e. 192.61.5.255.
>Host A's IP layer translates that to a limited broadcast, i.e. 255.255.255.255.
>Host B receives this datagram but the checksum check fails because the 
>destination address used in the checksum check is different than the
>destination address used in the checksum generation by host A. Could it be that
>directed broadcasts should not generate/check checksums?

The IP layer should not be rewriting addresses without also adjusting
checksums to match.  (And yes, this can be arbitrarily hard when higher-
level checksums are involved, which means that the IP layer should not
be rewriting addresses, period.)  Complain to whoever supplied the IP layer.

Not generating UDP checksums for directed broadcasts might be a useful
workaround for this bug.  It is not the correct fix; protocols other than
UDP are potentially affected.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jul 1992 22:42:28 GMT
From:      bwill@athena.mit.edu (Brian F Williams)
To:        comp.protocols.tcp-ip
Subject:   Checksums on data

	I want to be able to send packets using UDP (or possibly TCP)
that have encoded data (Reed/Solomon encoding, which allows bit error
recovery).  Rather than drop the packet if the data checksum is wrong,
I'd like to try to decode the packet and decide for myself if the data
is usable.  Is there any way to disable the checksum for the data
field, or do I have to use IP (and the RAW_SOCKET).
	If you're curious, this is for a simulation.

	Thanks for any advice.


--
internet: bwill@athena.mit.edu
uucp    : mit-eddie!mit-athena!bwill
bitnet  : bwill@athena.mit.edu

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jul 1992 22:45:57 GMT
From:      jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy)
To:        comp.protocols.tcp-ip
Subject:   Packet-drivers from Clarkson.

Hi !,
I need some desperate help regarding packet-drivers I just unzipped
from Clarkson. I first ftped in BINARY mode, and then Kermitted from
my UNIX host to a floppy. What happens is, if the packet-driver for
Ungermann Bass card is run, it just comes back to the prompt without
any message. What do you think the problem will be. Going inside 
DEBUG.COM with UBNICPS2.COM tells me that within 15 instructions
I'm encountering a INT 20H instruction (Quit from COM program!).
Is there something more I have to do or get in touch with someone ?

Would really appreciate help. 

Thank you.
Karthik
/----------------------------------------\--------------------------\
| Karthikeyan Guruswamy                  |   Why does'nt my         |         
| Graduate Student, Computer Science     |                          |
| Center for Advanced Computer Studies   |   NET always WORK ?      | 
| Univ. of SouthWestern Louisiana        |                          |
| Lafayette, LA 70501                    |                          |
| Phone: (318) 237 8074                  |                          |
| Email: jmfres11@ucs.usl.edu            |                          |
|                                        \--------------------------\
| The opinions stated are solely mine and does not reflect the views|
| of anyone in my organization ...                                  |
 \-------------------------------------------------------------------/ 

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jul 92 23:42:32 GMT
From:      mikec@intelhf.hf.intel.com (Mike Coleman)
To:        comp.protocols.tcp-ip
Subject:   Need NDIS driver for DE100

I need to find an NDIS driver for DOS that works with the DE100.

Any suggestions where I might FTP one?

Mike

==========================================================================
Mike G. Coleman, Site Computing Services - LAN Services, Intel Corporation
Voice - (503) 696-2984  Internet: Mike_G_Coleman@ccm.hf.intel.com   or
		         	           mikec@hfglobe.intel.com
   "the views I express are my own, nobody else would ever want them"
==========================================================================

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jul 1992 00:19:23 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Re: Query re. transition to CLNP

robert@peregrine (Robert Young) writes:
>
>Yeah. I also read it on the 7/6/92 edition.
>Also, they do not plan to give too much time for decisions.
>They seem to be ready to decide in two weeks?
>Another proposal considered was "IP Address Encapsulation.
>Yet another was the "P protocol"

As many helpful people told me, this isn't the best group for this. Try
info.ietf, or subscribe to big-internet list distributed by munnari.oz.au.

Followups by mail please!       E.

-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 92 00:57:00 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Address resolution in FDDI TCP/IP

In article <211@visicom.com> rlk@VisiCom.COM (Bob Kitzberger) writes:
>
>ARP/RARP exists to provide mapping of Ethernet address to IP 
>addresses, and vice-versa.
>
>Is there any equivalent 'standard' for TCP/IP on top of FDDI?

Yes, ARP/RARP.  They are not specific to Ethernet LANs.

Art

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 92 01:45:54 GMT
From:      brunner@practic.com (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Summer Reading (was: Re: Query re. transition to CLNP)

In article <1992Jul08.125640.16795@rs6000.cmp.ilstu.edu> ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes:
>The last Communications Week reports that ...

Reading the trade-rags for the next couple of weeks is going to be good for
some fun, perhaps even as good as reading the coverage of the IOP shownets
during and after each of the 88-91 show. I'll send five rreq-non-conformant
packets for the silliest "insider scoop" quote. Remember, these are the fine
folks who tout InterEnterPrizeNetWorks or SnaInterOperability or whatever a
random text generator pops out as a theme-of-the-week.

> I haven't seen much discussion here ... [and asks about rfc's]

See Craig's note, what is surprising is that it has stayed confined to the
ietf/big-I/road mailing lists, where it has tended to clutter up one's mbox.

As for rfcs, you'll want to look at several drafts, there are half-a-dozen
papers, and another several in-flight. A relevent issue is rfc1310, or who
controls changes to standards, which as one might guess, is not a technical
issue...

Please refrain from posting obvious "advantages" or "disadvantages", believe
me, they've been covered on the lists. Let's keep the tcp-ip list readable.

A ten penny guide to the reading list (hey, I'm working!), all errors and
bogus value judgements are mine and copyrighted, at least this is as far
as I've had time to get in the reading since San Diego!

road.txt	Hindon, Crocker, Estrin Steenstrup, Chiappa, Jacobson, Oran,
		et al (aka "IPAE")
EIP		Wang (aka "Extended Internet Protocol")
supernet.txt	Fuller, Li, Yu, Varadhan (aka "Supernetting" or "aggregation")
rfc1237		Collela, Guidelines for OSI NSAP allocation in the internet
rfc1335		Wang and Crowcroft (aka "Two-Tier")
rfc1347		Callon (aka "TUBA" or "simple CLNP")
rfc994		ANSI X3S3.3 86-80 (March 1986) DIS 8473 CLNS
IAB REPORT	June 1992 (aka "ISOC hijinks at Kobe"), see ipv7 below
C#		(I haven't seen this)
CIDR		classless network address

Inobvious related reading:
Don Provan's IPX tunneling spec, and Sue Hare's recent IDRP work

Inobvious work:
Sue Hares/Cindy Jung/Dave Katz's (et al) running IS-IS over the Fall '91 IOP
spine, with OSPF doing ip routing.

The usual cast of issues:
protocol identification, pseudo-headers, layer interactions, error reporting,
address resolution, multi-casting, checksums ...

Extra credit for pseudo-header checksums and non-big-header complications.

With no pretentions to having the answer(s),
-- 
#include <std/disclaimer.h>
Eric Brunner, Tule Network Services
uunet!practic!brunner or practic!brunner@uunet.uu.net
trying to understand multiprocessing is like having bees live inside your head.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 92 07:12:26 GMT
From:      simon@geocub.greco-prog.fr
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   TCP/IP router (ethernet/X.25)


I'm a neophyte in the WAN area and I'm in charge of connecting two TCP/IP
LANs using routers and X.25. I would greatly appreciate any opinions or
suggestions (commercial or otherwise) on good solutions to this problem.

My LAN here in France is relatively large (several hundred machines) while
the other LAN in Texas is much smaller.

I'm planning on using X.25 to establish the link, since the volume should
be relatively light (mostly Telnets).

It seems to me like a router is the only way to go considering the
volume of broadcasts on our ethernet, and the cost of trans atlantic
X.25 (about .25$ per Kbyte).

The requirements that I have identified so far are :

1 - good security in the router software (possibility to filter on source
                                         and destination IP adresses or TCP
                                         ports, etc.)

2 - data compression (this should save us quite a bit of money on
                       X.25 costs)

3 - multiple simultaneous connection to distant LANs ( we're starting out
                                         with Texas, but more are to come)

4 - conformance to RFCs enabling interoperability over X.25 with routers
   from other manufacturers who follow the rules. The sales people over
   here in France are saying that the RFCs aren't precise enough to
   guarantee interoperability, but I hope they are wrong.

Other things that I would like to see in a router are :

5 - expandability (extra slots), which would  enable other WAN
   connections (ISDN?) to be used in the future

6 - dynamic load sharing (do any tcp/ip routers do this?)

7 - won't cost me an arm and a leg:-)

I don't think performance is an issue, since our X.25 connection will be
very low speed (9600 bits/s to start out with).

From what I can tell, a router called P4100+ made by Proteon seems to fit
the bill for security, multiple connections and interoperability, but I've
been told that it won't do compression. There are 4 slots in this router
so expandability is covered.

The P4100+ doesn't seem to do load sharing. And here in France a
P4100+ costs approximately 12500$ (4 slot chassis+ethernet card+X.25 card
+software), which seems pretty expensive to me.

Of course in the US I could probably pick up the same configuration for
somewhere around 7500$.

I would really appreciate any pointers to a product which would meet all
of my requirements.


BTW, I can't seem to locate a news group which fits exactly for this
message. If there is a news group which I should have posted this in
please let me know.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jul 1992 07:32:44 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Checksums ??

In article <1992Jul9.140053.29821@rsvl.unisys.com> rae@rsvl.unisys.com (Rick Erickson x2132) writes:
>The problem is this: host A is sending a UDP datagram to all
>hosts on the local network, using a directed broadcast, i.e. 192.61.5.255.
>Host A's IP layer translates that to a limited broadcast, i.e. 255.255.255.255.

Host A's IP layer has malfunctioned.  The checksum failure is detecting
a legitimate error: the packet was not delivered to the IP address that
it was transmitted to.  There is no justification for the IP layer to
modify a destination address, even if the change is to an address which
appears to be functionally equivalent.
						don provan
						donp@novell.com

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 92 17:34:50 GMT
From:      brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein")
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

Phill, you stated over the phone that the decision on my 15 July 1991
request was Crocker's decision. You didn't even know when the decision
had been made, though you said that you believed it was in March.
Crocker's decision was to reject my request to standardize TAP.

I stand by my accusation: Crocker has a conflict of interest.

I also note that any implication that the Ident effort is a
``continuation'' of my TAP effort is a lie. Crocker rejected the
request and explicitly cut TAP out of the process. And Ident IS NOT
COMPATIBLE WITH CURRENT USE OF TCP PORT 113.

Now you mention the IESG's May decision on my 18 April 1992 request.
I'm glad that you finally said something about it, but you didn't
explain why ``duplication of effort'' was an adequate reason to stifle
proper documentation of the protocol used today on TCP port 113. The
Ident chairman refuses to allow TAP discussion, and the TAP proponents
agree that Ident is by no means the same protocol as TAP.

Why not change the port number of Ident? What's the disadvantage?

Why not allow a working group for TAP---a working group chartered to
actually define the protocol in use on port 113?

(I agree that I can be a very difficult person to deal with---especially
when I have to deal with a liar like Steve Crocker throwing me off the
SAAG list. But don't pretend that ``repeated attempts to reach
compromise with [me] were fruitless.'' Rather than trying to defend
myself here I invite you to read the recent messages from Icarus Sparry
and Anders Andersson on the Ident list. They do a wonderful job of
demonstrating that Mike StJohns has failed in every respect as the
chairman of Ident. Over the past year, Crocker and StJohns have acted
repeatedly to prevent any compromise with me. My original ``informal
notice'' message provides specifics of these actions. I defy you to
prove that I have ever acted to prevent compromise with SAAG or any
other group. The record shows that I have made literally hundreds of
changes to my draft in response to SAAG criticism. The TAP-std group
will continue this productive effort.)

---Dan

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 92 21:10:49 GMT
From:      pgross@ANS.NET (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion


    Remove yourself!

Steve Crocker did not make the final decision.  The IESG did.  

As a group, the IESG agreed that 1) the security area had fairly 
reviewed the Authd protocol and had valid concerns about its
strength as an authentication method, 2) that repeated attempts to 
reach compromise with you were fruitless, 3) that if a similar
protocol for identification/tracking was warranted then a separate
WG would need to be set up (the Ident WG), and 4) it made no sense 
to charter a parallel Authd/TAP WG under these conditions. 

You now call this protocol TAP.  You now claim to have no claims about
authentication in the TAP spec.  However, this does not change the
fact that reaching compromise with you was impossible for the better
part of the last year.  You have been the single hardest person to 
deal with in all my experience in the IETF (and, trust me, there 
have been some doozies).

Dan.... get a life.

Phill Gross


P.S. The time of the Ident WG meeting is shown below.  

7:00-10:00 pm    Tuesday, July 14, 1992 - Evening Sessions

                 SEC    TCP Client Identity Protocol WG (ident)
                        (Mike St.  Johns/DOD)

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jul 1992 21:26:16 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Checksums on data

In article <1992Jul10.224228.12480@athena.mit.edu> bwill@athena.mit.edu (Brian F Williams) writes:
>	I want to be able to send packets using UDP (or possibly TCP)
>that have encoded data (Reed/Solomon encoding, which allows bit error
>recovery).  Rather than drop the packet if the data checksum is wrong,
>I'd like to try to decode the packet and decide for myself if the data
>is usable.  Is there any way to disable the checksum...

The UDP data checksum is optional.  Whether you can disable it from a
user-level program is up to your operating system.  (Some of them have
it already disabled and don't allow you to turn it *on*, in fact...)

The TCP data checksum is mandatory.  Among other reasons, the header
fields it protects are vital to things like flow control.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Jul 92 04:46:42 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Checksums ??

In article <Br6K3q.AA8@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1992Jul9.140053.29821@rsvl.unisys.com> rae@rsvl.unisys.com (Rick Erickson x2132) writes:
>>...host A is sending a UDP datagram to all
>>hosts on the local network, using a directed broadcast, i.e. 192.61.5.255.
>>Host A's IP layer translates that to a limited broadcast, i.e. 255.255.255.255.
>>Host B receives this datagram but the checksum check fails because the 
>>destination address used in the checksum check is different than the
>>destination address used in the checksum generation by host A. Could it be that
>>directed broadcasts should not generate/check checksums?
>
>Not generating UDP checksums for directed broadcasts might be a useful
>workaround for this bug.  It is not the correct fix; protocols other than
>UDP are potentially affected.

No.  It will still fail the checksum on the IP header.



-- 
Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
"A unix signature isn't a return address, it's the ASCII equivalent of
a black velvet clown painting. It's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who."

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Jul 1992 06:34:28 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Checksums ??

In article <1992Jul12.044642.275741@cs.cmu.edu> cmaeda+@cs.cmu.edu (Christopher Maeda) writes:
>>Not generating UDP checksums for directed broadcasts might be a useful
>>workaround for this bug.  It is not the correct fix; protocols other than
>>UDP are potentially affected.
>
>No.  It will still fail the checksum on the IP header.

Note that I said "might". :-)  I was assuming, actually, that the code
involved wasn't *totally* brain-dead, and was fixing the IP header
checksum or not calculating it until after its address mangling.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 92 00:00:45 GMT
From:      ciemmj@iscnvx.lmsc.lockheed.com (Mark J. Jackels)
To:        comp.windows.x.apps,comp.windows.x.motif,comp.protocols.tcpip
Subject:   X based/front end  ftp program


Hi folks,  can anyone tell me where I can get a copy of an X based ftp 
program or an X based front end to ftp (Motif if possible)?  I saw 
reference to one a while back but negelected to save the article or
the info.  Any info on this would be appreciated.

Mark J.

mjackels@lmsc.lockheed.com


-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 92 02:14:29 GMT
From:      yost@adobe.com (David Yost)
To:        comp.protocols.appletalk,comp.protocols.tcp
Subject:   Wanted: Telnet over ADSP

Now that we have AppleTalk remote access, it would be nice
to be able to do unix logins over the AppleTalk link.  It
occurs to me that one way to do that would be to use the
telnet protocol running over ADSP (the AppleTalk equivalent
of TCP).  Given a unix kernel running AppleTalk, and given
sources to telnet, I'm sure I can whip up the server side
in short order.  Has anyone got the wherewithall to whip up
a telnet/ADSP connection tool for the Mac?  Apple supplies
an ADSP connection tool, and I've seen a telnet/TCP connection
tool somewhere.  Can connection tools be cascaded?  Say, a
telnet connection tool that lets you choose the underlying
stream protocol connection tool?

 --dave yost
   yost@adobe.COM

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 1992 02:25:47 GMT
From:      hsu@cs.hut.fi (Heikki Suonsivu)
To:        comp.protocols.tcp-ip
Subject:   3c501 cards


Is there a reliable packet driver for 3c501?  I have problems with this
setup:

sun 3/60
|
 ethernet
|
 pc with 3c501, packetdriver (9.2), pcroute (pktslip.exe) (2.22)
|
 19200 slip link
|
 pc with 3c501, packetdriver (9.2), pcroute (pktslip.exe) (2.22)
|
 ethernet
|
sun 3/60

As long as I do not send large packets through the link, everything works.
Ping works always, telnet and rlogin sessions usually work if I don't cat
(etc) anything large, ftp dies if any large file is transmitted.

If I send large packets, the connections die with various symptoms,
sometimes packets seem to go there, but the sun driver forgets them (after
typing ^d in this "mode" I get normal "Connection closed").  Sometimes
almost everything dies, including other connections, sometimes only the big
packet-sent-connection dies.  There are so many different symptoms that I
guess there is one simple problem somewhere which causes packet corruption,
thus leading to the other problems I see.

I have had similar symptoms with mach 2.5, so it is not necessarily packet
driver or pcroute problem.

It might be that the card is incorrectly configured, but I have done telnet
and ftp from on of the pc's without problems (with or without packet driver).

When I rlogin, some trash characters appear before the password: prompt.
Never seen anything like that, so I assume it has something to do with the
other problems I have. 

I have tried swapping one of the cards.  

I know 501 cards stink, but I still suspect it could be made to work (seems
to be a software fixable?)  As the slip link is the bottleneck, I don't
mind low performance.

Any experiences (success or fail) with pcroute and slip links?

-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi  +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.


-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 92 02:34:44 GMT
From:      mbaker@ucs.adelaide.edu.au (Matthew Baker)
To:        comp.protocols.tcp-ip
Subject:   IEEE fax number & ethernet numbers

Hi,
	I need to apply for a set of ethernet numbers, and I believe
that I need to apply to IEEE for these.  Can anyone please supply
a fax number which I can fax the request to?
Does anyone know of the minimum numberof numbers that can be reqested?


Thanks,

Matt Baker
--------------------------------------------------------------------------
matt baker				mbaker@ucs.adelaide.edu.au
Applied Data Control
South Australia.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 92 05:09:26 GMT
From:      catone@dmark.wharton.upenn.edu (Tony Catone)
To:        comp.binaries.ibm.pc.wanted,comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.bsd
Subject:   Re: Need an LPD server for an XT

In article <1992Jul9.083408.18540@usage.csd.unsw.OZ.AU> pwb@newt.phys.unsw.oz.au (Paul W. Brooks esq.) writes:
	   Has anyone got the KA9Q LPD to print using the LPR that comes
   from any freeware package?

Works fine for me with Dec Ultrix 4.2A and NCSA 2.3.05.  Please email
any questions.


- Tony
  catone@dmark.wharton.upenn.edu



-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 1992 06:21:26 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE fax number & ethernet numbers

In article <7784@sirius.ucs.adelaide.edu.au>, mbaker@ucs.adelaide.edu.au
 (Matthew Baker) wrote:
>Does anyone know of the minimum numberof numbers that can be reqested?

Last I heard each "chunk" (2^24 many) costs US$1,000.

(2^24 = 16,777,216)

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 1992 13:15:03 GMT
From:      billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager)
To:        comp.protocols.tcp-ip
Subject:   The Message Send Protocol Version 2 (RFC 1312)

Does anyone know of any implementation of RFC 1312 (Message Send Protocol
Version 2)?  I have an implementation of the original RFC 1159, but am
looking for one that follows the new updated RFC.

Thanks,



-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 92 15:16:43 GMT
From:      sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE fax number & ethernet numbers

In article <7784@sirius.ucs.adelaide.edu.au> mbaker@ucs.adelaide.edu.au (Matthew Baker) writes:
>	I need to apply for a set of ethernet numbers, 
You may be able to use the "locally defined" set of numbers for your
application.  Perlman notes a global/local bit in the first octet of
the address.

>Does anyone know of the minimum number of numbers that can be requested?

IEEE provides 2^24 number blocks

You may be able to get a vendor to "give" you a small set than that provide
by the IEEE.
	"a vendor can purchase more than one block of addresses as well as
	 donate addresses to other vendors."  Perlman pg 25

Credit:  Interconnections by Radia Perlman (Addison-Wesley)
Disclaimer: I have not finished the book but really enjoyed using information
from it.  :-)

-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 741-4500   work
Greenfield, IN 46140

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 1992 15:22:28 GMT
From:      cherng@bhub.tay.dec.com (Tungning "Donnie" Cherng)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPIP source code


Me too.
If there is a public domain tcp/ip stack source code on the net,
I would like to know how to get one too.
Thanks,
Donnie,

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 92 17:37:49 GMT
From:      ta@slc1.UUCP (Tony Alicea)
To:        comp.protocols.tcp-ip
Subject:   ICM/SMTP Conversion (ATA/IATA)

I'd like to know if anyone knows about any work or paper done on
SMTP/ICM message conversion & gateways. ICM = Inter(air)line Communications
Manual, published by the International Air Transport Association (IATA) & the
Air Transport Association of America (ATA).

Thanks


Tony Alicea                       | uunet!opel!crusty.arinc.com!ta
Aeronautical Radio                |
Annapolis, MD            USA      |____________________________________

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 1992 20:36:30 GMT
From:      nectar@world.std.com (Jacques A Vidrine)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Token Ring 802.5 v. Token Ring SNAP

Could someone please tell me the difference between 802.5 frames
and SNAP frames?  I don't mean frame layout - I guess I mean for what
are each used and from where did each standard come? (802.5 is obvious,
but what about SNAP?)

Any help will be appreciated!
-- 
Jacques A. Vidrine 		|	What did the Zen Buddhist	
nectar@world.std.com		|	say to the hot dog vendor?
				|	"Make me one with everything."
Request my PGP public key	|

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 92 22:18:53 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Token Ring 802.5 v. Token Ring SNAP

In article <BrCH8v.6HH@world.std.com> nectar@world.std.com (Jacques A Vidrine) writes:
>Could someone please tell me the difference between 802.5 frames
>and SNAP frames?  I don't mean frame layout - I guess I mean for what
>are each used and from where did each standard come? (802.5 is obvious,
>but what about SNAP?)

802.5 assumes use of 802.2 LLC (Logical Link Control).  Protocols are
demultiplexed in 802.2 using the LSAP fields.  Since there are effectively
only 64 available global values, it is nearly impossible to get a new
one assigned.  Only a few code points exist, such as 0xFE for the standard
ISO protocols.  To circumvent this problem, the SubNetwork Access Protocol
(SNAP) was created to allow for extended demultiplexing.  This is basically
a protocol sublayer which immediately follows the LLC header and was
assigned LSAP value 170 (0xAA).  SNAP is now part of the IEEE specs, and
I'd assume eventually part of the ISO specs.  The SNAP headers consists
of a 3 octet OUI (Organizationaly Unique Identifier, same as manufactuer ID
in a MAC address) and a two octet protocol ID managed by the owner of the
OUI.  OUI 00:00:00 was grandfathered in to identify the Xerox Ethertypes.

Hope this helps,

Art

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 1992 23:19:41 GMT
From:      chrisp@efi.com (Chris Phoenix)
To:        comp.protocols.tcp-ip
Subject:   Non-graceful close of TCP socket connections

I have two related questions about closing TCP socket connections.

First: Someone suggested about a month ago that to avoid keeping
around connections in the TIME-WAIT state, you could do an ungraceful
close of the connection.  My question is: Doesn't this have the effect
of throwing away all data that has not been received by the
application already, on both sides of the connection?  So for example,
if I do a write and then an ungraceful close on a socket over a slow
network, there is a good chance that the data I have just written will
never arrive at the other end.

Second: In Berkeley Unix's LPD program, the way they deal with errors
is to write an error string to the connection and then exit the
program.  More specifically, when a socket s is opened they fork() a
child process.  The child dup2's s to 1, then closes s, then processes
the protocol.  On error, it does a printf() of the error string, then
immediately does an exit(1).  Will this do an abrupt or graceful close
on the socket?  And if it's abrupt, is there a risk of losing the
error string?

Now a question about TIME-WAIT.  Is it true that the purpose of
TIME-WAIT is to give both sides a better chance of getting the ACKs
and sequence numbers they need?  Please tell me if my understanding is
correct: Suppose A sends a FIN to B, B sends an ACK FIN to A, A sends
an ACK to B.  A doesn't know if B received the last ACK, so A has to
stay in TIME-WAIT in case B requests the ACK again (by sending another
ACK FIN).  If this is not what TIME-WAIT is for, please tell me what
the real purpose is?

Please email me the answers (whether or not you also post them) since
our news feed is a week slow.  Thanks!

-- 
"I did not walk into the wall!  OK, I did walk into the wall, but it wasn't
my fault!!"
			Chris Phoenix -- chrisp@efi.com

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 03:02:25 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   TLI interface (examples anyone?)

A co-worker is trying to port an IP application to a machine that
only supports the TLI interface to IP (i.e. it doesn't support BSD
sockets). I think this interface is sometimes called (perhaps
incorrectly) the STREAMS interface to IP.

He's rooted around in reams of documentation for quite a while and
can't find a code sample that shows how to open/read/write/close
a TCP and/or UDP 'connection'.

Pointers to some code that uses the TLI interface would be most
appreciated for this loathsome task.

		-John Kalucki
		johnk@gordian.com


-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 10:12:50 GMT
From:      mbaker@ucs.adelaide.edu.au (Matthew Baker)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE fax number & ethernet numbers


>>	I need to apply for a set of ethernet numbers, 
>>Does anyone know of the minimum number of numbers that can be requested?
>
>IEEE provides 2^24 number blocks
>
>You may be able to get a vendor to "give" you a small set than that provide
>by the IEEE.

Thanks to all the people who answered my question. I'll be faxing off to IEEE
tommorow and getting their side of the story.  If I have too, I'll pay the
$1000, though it does seem silly when all I need is <100 address'.


Thanks again,
-------------------------------------------------------------------------
Matt Baker
mbaker@ucs.adelaide.edu.au
Applied Data Control
South Australia

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 11:14:17 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   SUMMARY - TCP/IP Market Info Sources

Hello

Below are the results of my question to the net requesting 
information on TCP/IP market size.  

I have categorized the sources in the order listed below.
The articles I have obtained personally
have been given a short review, those I have not seen just
contain a reference.

                                    Dale Edgar
                                    Cybernetic Control Inc.
                                    DEDGAR@MTA.CA
                                    June 14, 1992

############################################################


     1) Magazine and Journal References containing
        information relevant to the size of the TCP/IP
        market. These have a short review done by myself.

     2) Magazine and Journal References without a review

     3) Newspaper Articles

     4) Available Market Surveys

     5) Commercial Market Research Surveys (fee required)

     6) Suggested (fee required) databases to search for more
        info

     7) Misc Sources

############################################################
1) MAGAZINE AND JOURNAL ARTICLES (with review)

COSTS ARE DECLINING FOR PC LANS            COMPUTER WORLD
                                           OCT 7, 1991 p106
     Discussion of the cost of implementing PC TCP/IP support
     on a network. Includes scenarios and price tags.

TCP APPLICATIONS SUITES FOR PC'S           COMPUTER WORLD
                                           OCT 7, 1991 p108
     Very good and comprehensive table listing all available
     commercial PC TCP/IP products on the market, what they
     offer and the cost.

CHALLENGERS RISE TO INTERNET               COMPUTER WORLD
                                           SEPT 23, 1991 p49

     Discusses competion between nations in terms of data
     communications, (a large part of which will be TCP/IP
     based) and trends for the future.  Has a nice table
     giving data on the number of computers on the Internet.

COMMERCIAL USERS MOVE ONTO INTERNET        COMPUTER WORLD
                                           NOV 25, 1991 p50

     An article about the increasing commercial use of the
     Internet, gives estimated numbers of nodes, networks,
     countrys etc.  Also has a illustrating projected
     bandwidth needs up to 1997.

TCP/IP MAKING UNIX AFFORDABLE              OPEN SYSTEMS TODAY
                                           MAY 25, 1992

     Says declining cost of Unix workstations and PC TCP/IP
     packages helping sales of each other. Discusses specific
     vendors, gives costs & etc.


NETWARE OPENED TO TCP/IP                   COMPUTER WORLD
                                           OCT 21, 1991 p81

     Article announcing Novells support for TCP/IP and also
     talks about other 3 party vendors and their Novell
     TCP/IP products.

VENDORS OPT FOR VARIED OSI STRATEGIES      OPEN SYSTEMS TODAY
                                           MAR 30, 1992 p25

     OSI floundering gives boost to TCP/IP sales, also talks
     about DEC, IBM, HP, UNISYS and SUN and gives lots of
     reasons why they all support TCP/IP now. Nice chart on
     protocols used by Fortune 1000 companies, now and
     planned in next 2 years.

FOR DUPONT ALL ROADS LEAD TO TCP/IP        OPEN SYSTEMS TODAY
                                           MAR 30, 1992 p30

     Article discussing the reasons why DuPont decided to go
     with TCP/IP.

BIG USERS OPTING FOR TCP/IP                OPEN SYSTEMS TODAY
                                           MAR 2, 1992 p13

     Says how the conglomerates are going for TCP/IP in a big
     way.  Gives projected number of TCP/IP nodes in U.S in
     1994 and also projected worldwide expenditures on TCP/IP
     up to 1993.

TCP/IP KEEPS SUBARU IN HIGH GEAR           OPEN SYSTEMS TODAY
                                           MAR 2, 1992 p 13

     Tells how and why Subaru decided to go for a TCP/IP
     work plus their plans for the future.

3COM SHRINKS TCP STACK SIZE                OPEN SYSTEMS TODAY
                                           MARCH 16, 1992 p8

     Article about the new small size of the TCP stack in
     3Coms new product.  Nice quote about the changing nature
     of the market.

PPP TOOL LINKS SUNS TO LANS                UNIX TODAY
                                           SEPT 16, 1991 p18
     Discusses comercial implementation of the PPP protocol
     and gives prices.

INTERNET TAPPED FOR GLOBAL VIRTUAL PUBLISHING ENTERPRISE
                                           COMPUTERWORLD
                                           MAR 23, 1992   p69

     How the Internet Society News got started. Mentions
     predictions about number of computers on local area
     networks in U.S. in 1995.  Gives numbers for internet
     nodes, users, networks, countries & etc in a chart.

EUROPEANS OPTING FOR TCP/IP OVER OSI       COMPUTERWORLD
                                           MAR 16, 1992 p49

     About networking trends in Europe. Has chart indicating
     what percentages of European sites are using what
     network protocols and the percentage of the traffic that
     those protocols carry.

FLOOD OF X.400 E-MAIL FLAVOURS CONFOUNDS USERS
                                           COMPUTERWORLD
                                           FEB 10, 1992 p6

     Not real relevant to TCP/IP but has general chart
     illustrating the anticipated growth in E-mail of all
     types in Fortune 2000 firms up to the year 1995.

THE INS AND OUTS OF THE INTERNET           OPEN SYSTEMS TODAY
                                           JUNE 22, 1992

     Introduction to the Internet plus a bit of history.


MULTIMEDIA SEEN AS SPUR TO NETWORK GROWTH  COMPUTERWORLD
                                           APR 27, 1992

     Says how growth in multimedia translates into heavier
     use of networks.  Not specific to TCP/IP but does have
     projected multimedia growth in dollars up to 1996.

ISDN ADAPTERS FOR THE PC                   COMPUTERDATA
                                           APR 91, p12

     Not relevant to TCP/IP but does have a general chart
     illustrating projected growth in potential and existing
     network attached user devices.

INTERNETWORKING PRODUCT DEMAND BOOMS       COMPUTERWORLD
                                           JAN 20, 1992

     Discusses how the demand for internetworking products is
     booming and why.  Gives figures for the internetworking
     market with chart & etc.

HPCC POLICY CHAMPION FORESEES NETWORKED NATION
                                           COMMUNICATIONS OF
                                             THE ACM
                                           NOV 91, p 15

     Senator Al Gore discusses his plans for a nationwide
     data highway and why its needed.

IS CASTS A BIGGER NET                      DATAMATION
                                           JAN 1, 1991 p32

     Article about the growth in Lans (not specific to
     TCP/IP) but does have a nice chart showing managers
     opinons on how critical local and wide area networks
     are.

TERMINAL EMULATION                         DEC PROFESSIONAL
                                           OCT 1991

     A comprehensive list of all VT220 and VT320 emulators
     on the market (most of which will do TCP/IP). Brief
     outline of their feature, no prices.

A GOOD YEAR FOR LINKING LANS               COMPUTERWORLD
                                           DEC 23, 1991 p40

     Discusses the boom in internetworking, and has a nice
     chart predicting future US lan interconnect revenue.
     Not TCP/IP specific, but does discuss it in passing.

INDUSTRY OUTLOOK                           COMPUTERWORLD
                                           DEC 23, 1991 p32

     Chart giving projected growth in revenue (to 1993) in
     the areas of, computers and related equipment, software
     and services, telecommunications, micro, mini, mainframe
     shipments, and PC software.

SNA-TCP ON SPEAKING TERMS                  LAN COMPUTING
                                           JUN 1992, p1

     Short article about the "landmark event" of the
     intervendor SNA-TCP showcase demo.  Discusses how
     linking IBM SNA based data centers to the emerging LAN
     internets is a top priority in the Fortune 1000.

MESHING LANS AND WANS                      LAN COMPUTING
                                           JUN 1992, p1

     Surveys says lans and wans will become increasingly
     intermeshed. Predicts top protocols in 1994 will be
     SNA, Netware and TCP/IP. Has chart.

######################################################################
Other Citations - (with thanks to Robert Young UMiami)

 Title:    The Significance and Impact of the Commercial Internet
 Authors:  Schrader, William; Kapor, Mitchell
 Journal:  Telecommunications (North American Edition)  Vol: 26  Iss: 2
           Date: Feb 1992  pp: S17,S21    ISSN: 0278-4831

 Title:    Army Reveals Its Plans for Nationwide LAN Internet
 Author:   Messmer, Ellen
 Journal:  Network World  Vol: 9  Iss: 4  Date: Jan 27, 1992  pp: 2,6
           ISSN: 0887-7661

 Title:    SNA vs. OSI vs. TCP/IP? There Is No Winner!
 Author:   Borthick, Sandra L.
 Journal:  Business Communications Review  Vol: 21  Iss: 10
           Date: Oct 1991  pp: 30-34   ISSN: 0162-3885

 Title:    The Trials, Tribulations and Triumphs of TCP/IP
 Author:   Juneau, Lucie
 Journal:  Computerworld  Vol: 25  Iss: 40  Date: Oct 7, 1991
           pp: 103,105  ISSN: 0010-4841

 Title:    A Peaceful Coexistence for TCP/IP and OSI
 Author:   Mosher, Robyn E.
 Journal:  Networking Management  Vol: 9  Iss: 9  Date: Aug 1991
           pp: 36-40  ISSN: 0746-6072

 Title:    Evans & Sutherland Lowers Networking Costs
 Author:   Ryding, Mark
 Journal:  InfoWorld  Vol: 13  Iss: 31  Date: Aug 5, 1991
           pp: S64-S65  ISSN: 0199-6649

 Title:    TCP/IP Allows High Availability Now
 Author:   Ladermann, Dan E.
 Journal:  Computer Technology Review  Vol: 11  Iss: 3  Date: Mar 1991
           pp: 34-35    ISSN: 0278-9647

 Title:    Finalist in ICA Competition Details Design of Internet
 Author:   Desmond, Paul
 Journal:  Network World  Vol: 8  Iss: 23  Date: Jun 10, 1991  pp: 1,54
           ISSN: 0887-7661

 Title:    Mac TCP/IP Network Carries Real-Time Financial Data
 Author:   Anonymous
 Journal:  Networking Mgmt  Vol: 9  Iss: 4  Date: Mar 1991  pp: 84-85
           ISSN: 0746-6072

 Title:    Which Communications Standards for Integrated Manufacturing?
 Author:   Mollenauer, James F.
 Journal:  Information Strategy: The Executive's Jrnl  Vol: 7  Iss: 2
           Date: Winter 1991  pp: 24-32   ISSN: 0743-8613

 Title:    Health Firm to Link LANs to TCP/IP Net
 Author:   Brown, Jim
 Journal:  Network World  Vol: 7  Iss: 53/v8n1
           Date: Dec 31, 1990/Jan 7, 1991 pp: 17,52-53   ISSN: 0887-7661

 Title:    Fidelity Builds Nationwide TCP/IP Backbone Network
 Author:   Desmond, Paul
 Journal:  Network World  Vol: 7  Iss: 48  Date: Nov 26, 1990
           pp: 2,71  ISSN: 0887-7661

 Title:    FTP Brings TCP/IP to OS/2 and DOS LANs
 Author:   Francett, Barbara
 Journal:  Data Communications  Vol: 20  Iss: 16  Date: Nov 21, 1991
                 pp: 69-78   ISSN: 0363-6399

 Title:    Product Spotlight: TCP/IP
 Authors:  Fisher, Sharon; Smalley, Eric
 Journal:  Computerworld  Vol: 25  Iss: 40  Date: Oct 7, 1991
                 pp: 97-102,106-108    ISSN: 0010-4841

 Title:    TCP/IP & Networks: Bridging Networks
 Author:   Frost, Lyle
 Journal:  UNIX Review  Vol: 9  Iss: 5  Date: May 1991  pp: 46-52
             ISSN: 0742-3136

############################################################
3) NEWSPAPER ARTICLES

BUSINESS TECHNOLOGY; FOR SHAKESPEARE, JUST LOG ON
                                           NEW YORK TIMES
                                           JUL 3, 1991
                                           Sec D, p1

     Discusses how a nationwide (US) network will allow users
     to access massive amounts of information.  Discusses the
     future impact of such a network and also talks about
     WAIS. Gives some numbers for the market for this kind of
     software.
 
IDEAS & TRENDS; FIBER OPTICS AT HOME       NEW YORK TIMES
                                           NOV 17, 1991
                                           Sec 4, p18

     About plans by the phone companies want to run optical
     fiber to every home, the cost, and possible
     implementation dates.  Talks about the benefits of
     voice, data and video going over the same lines.

SPEED-UP OF FIBER-OPTIC NETWORK DEBATED    NEW YORK TIMES
                                           DEC 8, 1991
                                           Sec 12NJ, p1

     A $1 billion plan by New Jersey to put optical fiber for
     data, voice and video into every home and business in
     the state is discussed along with the ramifications of
     doing so.

DATA NETWORK RAISES MONOPOLY FEAR          NEW YORK TIMES
                                           DEC 19, 1991
                                           Sec D, p7

     Much concern whether the new (US) NREN computer data
superhighway is going to be a monopoly and what to do about
it.  Discusses various carriers and gives some reference to
the continued growth in traffic.

BUSINESS TECHNOLOGY - THE GLOBAL LAB       NEW YORK TIMES
                                           Jan 1, 1991
                                           Sec 1, p49

     Article discussing the global internet and why its
     essential for science.  Gives lots of figures on
     internet size.  Nice quote about why the internet is
     growing so fast.
 
#########################################################################
4) MARKET SURVEYS

                "Interconnectivity: the role of TCP/IP."
                January, 1988  138 pg  $995

                "TCP/IP into the 1990's."
                -Published on demand-  $1500

      Both available from:  Newton-Evans Research Co. Inc.
                            10176 Baltimore National Pike
                            Suite 204
                            Ellicott City, MD 21042
                 Telephone: (410) 465-7316       Fax:  (410) 750 7429

        There are at least three additional market research
        organizations which are likely to have published studies on
        TCP/IP:  Frost & Sullivan
                 IRD - International Resource Development Inc.
                 Information Gatekeepers Inc.


#########################################################################
5) DATABASES

Suggested databases for a computer-based literature search service.
         (fee required)

         Industry Data Sources
         Findex

         in particular for limited-distribution publishers; and
                 ABI/Inform
                 Trade & Industry Index
          for business/trade journal literature articles.
                 PTS/PROMPT

##################################################################
6) Misc. Sources

INTERNET SOCIETY INFORMATION PACKAGE           isoc@reston.NRI.va.us

     Lots of information on why the Internet Society was formed. Has
     2-3 pages on size and growth of the internet.


HOW BIG IS THE INTERNET?
 
        M.  F.  Schwartz.  How Big is the Internet?  Internet News: The
        Newsletter of the Internet Society, 1(2), pp. 3-5, Spring 1992.

        Doesn't directly address the size of the TCP/IP market but does
        have interesting info on what domains are out there and the 
        most used applications (TELNET, FTP, & etc) in them.  Has additional
        references.

ZONE SURVEY 

        Network Information Systems Center                     April 1992
        SRI International                          Internet Domain Survey


             ZONE (Zealot Of Name Edification) Survey Results

        The ZONE survey attempts to discover every host on the Internet 
        by doing a complete search of the Domain Name System.  The latest 
        results gathered during April 1992 are listed.  For more information 
        see RFC 1296; for actual data see the pub/zone directory on 
        ftp.nisc.sri.com.  Also has a nifty little table of the top 50 most
        popular node names on the internet.  (All time favorite = VENUS)

                                             

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 13:17:00 GMT
From:      gavron@vesta.sunquest.com (Ehud Gavron +1-602-570-2546)
To:        comp.protocols.tcp-ip
Subject:   Query on legality of duplicate SYN packets


	In attempting to interoperate* with a PC running some flavor
	of TCP/IP one of our clients has detected a problem.

	Apparently the PC can't seem to respond in time to our first
	SYN on TCP connection formation.  By the time it gets around
	to sending an ACK+SYN our box (Decstation running Ultrix) has
	already sent off a second copy of that SYN packet, which 	
	promptly causes the PC to crash.

	From everything I can see in the RFC and the code, there is
	nothing prohibiting such a duplicate SYN packet.  However, I
	am having a hard time understanding how a host is expected
	to throw away duplicate packets on a ``connection'' that
	doesn't yet exist.  

	Comments?

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
Help!  I'm stuck in the mail queue and I can't get out!

*I hereby acknowledge conformance of the Buzzword Statute of 1992
 and its requirements,  which state that all communication
 regarding computers shall use one of the Golden Words of Wisdom
 which are defined as "Interoperate," "Open," "Multivendor,"
 "User Friendly," "Easy to configure," and "Comes configured."

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 14:22:21 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI interface (examples anyone?)

johnk@gordian.com (John Kalucki) writes:

>A co-worker is trying to port an IP application to a machine that
>only supports the TLI interface to IP (i.e. it doesn't support BSD
>sockets). I think this interface is sometimes called (perhaps
>incorrectly) the STREAMS interface to IP.
 
>He's rooted around in reams of documentation for quite a while and
>can't find a code sample that shows how to open/read/write/close
>a TCP and/or UDP 'connection'.
 
>Pointers to some code that uses the TLI interface would be most
>appreciated for this loathsome task.


The book "UNIX Network Programming" by W. Richard Stevens (Prentice Hall, 
Englewood Cliffs, NJ 07632) has a whole chapter on the TLI, with some good 
background explanation.  It also contains several simple examples, in "C",
of how to use TLI functions for TCP and UDP operations  This is a very 
popular UNIX book and so it should be available at any store that carries 
such materials.

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

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



-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 15:03:53 GMT
From:      bgi@stiatl.salestech.com (Brad Isley)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,sti.technical
Subject:   Sun's PCNFSD 2.0 with PC-NFS 3.5?

Setup:

We have approx 70 PC-NFS users running PC-NFS 3.5.  Our server, a 4/470,
is not an NIS server.  We have a 386i on the net that is the historical
NIS master.  No-one here knows how to "switch off" the 386i's NIS server
so we can turn on the NIS services on the 4/470.  And no, we can't just
turn of the 386i.

Problem:

Because of this problem, PC-NFS users are restricted to the group
permissions of the single group assigned upon login.  The rpc.pcnfsd 1.3 that
came with PC-NFS 3.5 doesn't consult the /etc/groups file to allow multiple
group permissions.  This is a serious restriction to our source control.
Sun tells me that the rpc.pcnfsd 2.0 that comes with PC-NFS 4.0 does consult
the /etc/groups file (as well as the NIS) for multiple group membership
permissions, as well as the NIS.  It's a royal pain to edit the passwd file
every time a PC-NFS user wants to change groups.

Question: Can we get and use the rpc.pcnfsd 2.0 that comes with PC-NFS 4.0?
          Or, should we upgrade to PC-NFS 4.0?

OR:

Question: How do we configure the 386i so it is no longer the NIS master?

Thanx much for any help.

-- 
    Itchy, Scratchy, Homer, Bart, Bugs, Elmer...  The list goes on and on.
                 They're so much more real than Congress...
-----------------------------------------------------------------------------
bgi@salestech.com           (404) 841-4169           Sales Technologies, Inc.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 15:42:40 GMT
From:      bjork@telebit.com (Steven Bjork)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   NetBlazer subnet hacks was Re: Subnetting for Novell routing.

In article <1992Jul14.015948.13636@novell.com> keith@novell.com (Keith Brown) writes:
>In article <1992Jul13.182601.25282@sifon.cc.mcgill.ca> id@sifon.cc.mcgill.ca (Ian Duncan) writes:
>>
>>From a summary reading and comments from wise folk it seems another new
>>routing protocol, RIP II, also has mechanisms for mixed length subnet
>>routing. Given the current wide reliance on RIP and the backward
>>compatibility this is quite likely to be playing soon in networks everywhere.
>
>Well, maybe. These things take time. RIP II is still only an IETF draft
>and I haven't seen an implementation yet (Steven... does one exist?).

I'm not aware of an existing implementation of RIP II.
Someone at the gated project (gated@gated.cornell.edu)
might know of this.

I have entered a request for RIP II support in our NetBlazer. 

The NetBlazer currently "supports" variable subnets as long as the
odd length masks are entirely within one NetBlazer.

For instance, you can have a class B 128.18, and use the standard
eight bit subnet mask of 255.255.255.0. Now, throw a NetBlazer
on your wire, within that NetBlazer you can use 255.255.255.240,
for a pile of fourteen host subnets. The NetBlazer can continue
to advertise the usual subnet via the 255.255.255.0 mask,
when the packets arrive the NetBlazer code divvies up the
packets and trickles them out the appropriate wire.

This trick is in use here at Telebit to allow some of us
lucky folks Internet access from home, and doesn't tie up
a subnet of 254 hosts, since no one at Telebit has more than
a half dozen or so network hosts at home :).

>Also, there is the issue of scalability. RIP as we know and love it
>in RFC 1058 doesn't scale too well and I quote.....
>
>>- The protocol is limited to networks whose longest path
>>  involves 15 hops.  The designers believe that the basic
>>  protocol design is inappropriate for larger networks.  Note
>>  that this statement of the limit assumes that a cost of 1
>>  is used for each network.  This is the way RIP is normally
>>  configured.......
>
>One is curious as to whether RIP II has improved upon this? I dare say
>one will have to get the draft and have a read when one has a moment.

No, the RIP II draft is concerned with the subnet mask and security.
It takes something like OSPF to handle the monstrous network out there
these days. Heh, I remember traceroute showing a T3 routing loop
day before InterOp opened fall '91... Lotsa hops, mon.

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

--Steven

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 17:20:05 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Query on legality of duplicate SYN packets

gavron@vesta.sunquest.com (Ehud Gavron +1-602-570-2546) writes:

>	Apparently the PC can't seem to respond in time to our first
>	SYN on TCP connection formation.  By the time it gets around
>	to sending an ACK+SYN our box (Decstation running Ultrix) has
>	already sent off a second copy of that SYN packet, which 	
>	promptly causes the PC to crash.

The PC is braindead (hope it's not running any software we sell :-)

>	Comments?

No possible doubt whatever.  From RFC 793 (page 25):

  We have taken advantage of the numbering scheme to protect certain
  control information as well.  This is achieved by implicitly including
  some control flags in the sequence space so they can be retransmitted
  and acknowledged without confusion (i.e., one and only one copy of the
  control will be acted upon).   ...    The SYN and FIN
  are the only controls requiring this protection, and these controls
  are used only at connection opening and closing.

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
	The road to hell is paved with melting snowballs - Larry Wall

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 17:31:37 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Non-contiguous subnet masks

Has anyone ever run accross a network that had a non-contiguous subnet mask?
(ie 0xffff00ff)

Are they really legal any more?

RFC 1247, which describes OSPF Version 2, states that OSPF won't
work correctly with such subnet masks (pg 55). Are there other
references in the current RFCs about these bizzare masks?

		-John Kalucki
		johnk@gordian.com

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 18:10:07 GMT
From:      john@yo_dud.NoSubdomain.NoDomain (John Frame)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and Banyan

Has anyone had any experience with TCP/IP and Banyan Vines?  I'm looking at interconnecting a backbone Ethernet carrying TCP/IP with local LANs running Ethernet/Token Ring Banyan Vines.  What are the important issues here?

Thanks,

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| John Frame                      |
| OD Business, Bell Canada        |
| Ottawa, ON Canada K1G 3J4       |
| Internet:  john@stam.qe.bell.ca |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 92 18:25:56 GMT
From:      seifert@netcom.com (Rich Seifert)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Token Ring 802.5 v. Token Ring SNAP

In article <BrCH8v.6HH@world.std.com>, nectar@world.std.com (Jacques A Vidrine) writes:
> Could someone please tell me the difference between 802.5 frames
> and SNAP frames?  I don't mean frame layout - I guess I mean for what
> are each used and from where did each standard come? (802.5 is obvious,
> but what about SNAP?)
> 

The 802.5 MAC resides below the 802.2 LLC. LLC allows only 8 bits for
upwards multiplexing (and half of these are reserved for multicasts). 
There are obviously not enough LSAPs (Link Layer Service Access Points)
for all of the possible Link clients. SNAP is a well-defined mini-layer
which uses one LSAP (0xAA) as an "escape" mechanism. If you use the
SNAP SAP (yes, that is what it is called!)this indicates that following
the LLC part of the frame will be two fields: First a 24 bit 
Organizationally Unique Identifier (OUI, aka the vendor code one gets
to assign addresses uniquely). Second is a 16 bit OUI-unique field
which is typically used as an upwards multiplexing protocol
identifier (similar to the TYPE field in an Ethernet). This
effectively expands the 8 bits of LSAP to 16 bits PER VENDOR!
We have reserved some OUIs for vendor-independent functions as
well.


-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 18:42:03 GMT
From:      aspyray@cidsv01.cid.aes.doe.CA (Raymond Benoit)
To:        comp.protocols.tcp-ip
Subject:   IP over HPPI


  
I'm trying to find information on TCP/IP over HPPI (or HIPPI). Is there
an RFC or draft RFC or other document in the works that would help me
write specifications (reference the RFC ot other document) for high speed
TCP/IP over this high performance interface (not the HIPPI standard itself
but TCP/IP specs.)         

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 18:48:49 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Query re. transition to CLNP

In article <1992Jul11.001923.12896@rs6000.cmp.ilstu.edu> ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes:
> As many helpful people told me, this isn't the best group for this. Try
> info.ietf, or subscribe to big-internet list distributed by munnari.oz.au.

I was wondering why there hadn't been any comment on this here. This seems
a trifle narrow-minded, since this transition IS going to impact us folks
with our little-i-internets whether or not we're on the big-I-Internet.

Sigh. The Internet insists on flooding Usenet with bogus groups, but when
there's something on that's really useful THEN they hide it away in a hierarchy
of their own. Double-sigh.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 19:39:13 GMT
From:      dave@SABRE.BELLCORE.COM (Dave Piscitello)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

Dan,

Your dispute with the IESG and Stephen Crocker notwithstanding, I
find your electronic "conduct" reprehensible. I do not wish
to interfere with your ability to express your opinions publicly,
but I find your frequent, highly abusive personal attacks deplorable.
They are inappropriate on this or any other medium. I would also
like to call to your attention that by participating on lists
such as these, you implicitly accept the responsibility to act
within the rules of conduct and propriety we all accept when
we forward traffic across the NSFnet. (I will send you a copy
if you do not have one). Please grow up.

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 20:27:42 GMT
From:      koft@gandalf.rutgers.edu (Dan Koft)
To:        comp.infosystems,comp.misc,comp.periphs,comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Getting a 3270 terminal to clear screen

Distribution: usa


Background: We have an information system that is running on a Sun running
UNIX.  Users on many other computers of various types telnet to it.  The
only one we are having display problems with are 3270 terminals on a IBM
Mainframe using TSO.

We feel that we could get an acceptable display if our info system could
send a signal back through the telnet session that would cause the terminal
to clear the screen.  We can tell when user is coming from a 3270 and can
adjust the signals sent for different situations (when a 3270 terminal is
sensed files are sent via cat instead of more).

Please followup to comp.infosystems.


[=============================================================================]
Dan Koft			 dot dot dot: koft@gandalf.rutgers.edu
RU-CS, Rutgers University	  bang  bang: {backbone}!rutgers!gandalf!koft
Hill 133, Busch Campus		  ring  ring: (908) 932-3216
Piscataway, NJ  08855
[=============================================================================]
-- 

[=============================================================================]
Dan Koft			 dot dot dot: koft@gandalf.rutgers.edu
RU-CS, Rutgers University	  bang  bang: {backbone}!rutgers!gandalf!koft
Hill 133, Busch Campus		  ring  ring: (908) 932-3216
Piscataway, NJ  08855
[=============================================================================]

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 20:32:49 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   subnet masks


	Are subnet masks assigned on a per-host, per-network, or
per-interface basis?  Does it make any sense to have different subnet masks
on different interfaces on a given host?  I just re-read RFC-950 and it's
not particularly clear on this.  My impression is that it has to be
per-network, but it's not 100% clear.

	Where's a good place to learn more about subnets than RFC-950 has
to offer (besides comp.protocols.tcp-ip)?
-- 
roy@wombat.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"This never happened to Bart Simpson."

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 21:41:30 GMT
From:      perv@flash.emf.mcgill.ca (Irwin Roger Gibson)
To:        comp.protocols.tcp-ip
Subject:   Access to the Internet from Barbados


	Hello.  I will be going to Barbados in August.  Does
anyone know the status of Internet access in the Carribean?

	Any help is appreciated.

Irwin Gibson
perv@flash.emf.mcgill.ca
perv@emf.lan.mcgill.ca

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 92 22:38:46 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: How to multihome a server (using YP in a DNS-friendly way)

In <1992Jul14.163324.1351@Warren.MENTORG.COM> tal@Warren.MENTORG.COM (Tom Limoncelli) writes:

[...]
>Now introduce a file server, say a Sun 4/490.  It's going to be equally
>used by machines on both networks, so we put two ethernet boards into
>it, call one board "bigserver-left" and the other board
>"bigserver-right".  Machines on one network nfs-mount off of
>bigserver-left and machines on the other network nfs-mount off
>bigserver-right.

This appears to be the way that Sun expects you to do it.

>This all works fine BUT it this is not how I see other sites
>configuring things.  I see other sites give both ethernet boards
>different addresses but the same name ie, in /etc/hosts:
 
>137.202.214.100   bigserver
>137.202.215.100   bigserver
 
>and two "A" records in their DNS zone for the one machine.

I have a couple of servers set up this way, and I think I did it
pretty cleanly.

[...]
>So, I guess my question is "What's the best way to multihome
>a server and how does it all work?"

I use DNS and NIS, with the NIS hosts map virtually empty, so that
all NIS host lookups become DNS lookups.  On a server, the files look
like this:

/etc/hosts:
127.0.0.1	localhost
137.202.214.100   bigserver

/etc/hostname.le0:
bigserver

/etc/hosts.le1:
137.202.215.100

/etc/netmasks:
137.202.0.0	255.255.255.0

The only related hacking to the rc files was to add static host routes
for the other multi-homed server, so this server would issue ICMP
redirects for it

In DNS, I have two A records and two PTR records for this server.

It all seems to work, although there are a few problems.  Some client
programs look up the hostname, get back two IP addresses, and only use
the first one.  When I export a filesystem read-write to this server,
and mount it read-write, it behaves as if it's read-only.  I haven't
tracked this one down yet, but I assume it's a bug.
-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jul 1992 22:51:44 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: How to multihome a server (using YP in a DNS-friendly way)

In article <1992Jul14.163324.1351@Warren.MENTORG.COM> tal@Warren.MENTORG.COM (Tom Limoncelli) writes:
[...]>
>Everything works fine.
>
It does? Can I hire your network manager? :-)

>Now introduce a file server, say a Sun 4/490.  It's going to be equally
>used by machines on both networks, so we put two ethernet boards into
>it, call one board "bigserver-left" and the other board
>"bigserver-right".  Machines on one network nfs-mount off of
>bigserver-left and machines on the other network nfs-mount off
>bigserver-right.
>
>         |                     |
>         |                     |--lucy
>         |---bigserver-left    |
>         |      Sun 4/490      |
>         |   bigserver-right---|
>         |                     |
>
>This all works fine BUT it this is not how I see other sites
>configuring things.  I see other sites give both ethernet boards
>different addresses but the same name ie, in /etc/hosts:
>
>137.202.214.100   bigserver
>137.202.215.100   bigserver
>
>and two "A" records in their DNS zone for the one machine.
>

That's because a DNS query for bigserver will return both addresses,
but if the query came from a machine on the "left" ethernet,
bigserver-left will be the first address listed, and if it came from
the "right" ethernet, bigserver-right will be the first address
listed. Nfs-mount uses the first address it gets, so machines on the
left hand side ethernet will mount bigserver-left, and machines on the
right hand side ethernet will mount bigserver-right.


>Then they have clients nfs-mount off of "bigserver" and their clients
>magically "know" to route their bits via the shortest path.  Users
>telnet from a Cisco terminal server into bigserver from the outside
>seem to pick a random ethernet, but if it's down it switches to the
>other (at least while connecting).
>

If one ethernet is down, and the terminal server attempts to telnet to
that seide of bigserver first, it will timeout and try the second
address it got from its DNS request. No magic there. I find it kinda
hard to believe that you get random behavior if both ethernets are up;
where is your terminal server connected?

i>So, I guess my question is "What's the best way to multihome
>a server and how does it all work?"

The answer depends on what you want to do with your multihomed host.
If you're using it as an NFS server, then the setup above is good.

[[IETFers: Please let's not start another flame war here about
multihoming and policy-based routing :-) ]]

>
>Tom
>-- 
>Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
>  "Don't get creative here.  Standards are good for you."
>                                   -H. Spencer

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 92 01:10:45 GMT
From:      billp@niagara.Tymnet.COM (Bill Putney)
To:        comp.protocols.tcp-ip
Subject:   Does pcnfsd work under Ultrix?


Has anyone had luck running pcnfsd on Ultrix?  I haven't.  I've been
useing FTP's Interdrive and can mount NFS files on any of the Sun
servers around.  I recently had a requirement which necessitated
mounting files that were located on an Ultrix (RISC) workstation.
After looking around for a pcnfsd like equiv. for DEC I compiled
Sun's version on the DEC workstation.  No error and it seemed to 
be happy to run.  Just one minor problem.  It didn't work.  Every
time I tried to mount a file system I got authorization errors.

I'm not an Ultrix wizard so there is a chance greater than zero 
that I missed something else in the set up but I can't find it.

If someone out there knows for sure that it works or doesn't
work let me know PLEASE...  If it doesn't work can you steer me 
to the Ultrix equiv?

I asked out DEC software person about 3 weeks ago and I haven't gotten 
an answer yet.  She seemed more interested in why I didn't want
to use Pathworks instead.

Thanks - Bill

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 01:48:45 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Does pcnfsd work under Ultrix?

billp@niagara.Tymnet.COM (Bill Putney) writes:

>If someone out there knows for sure that it works or doesn't
>work let me know PLEASE...  If it doesn't work can you steer me 
>to the Ultrix equiv?

	decuac.dec.com:/pub/binaries/pcnfsd.tar.Z

	It's unsupported, etc, but it should work. (And if it doesn't,
let me know and I'll try to fix it even without a copy of PCNFS) ;)
I didn't really want to support a PCNFS binary distribution, but I
figured that since it's ULTRIX and I work for DEC...

mjr.
-- 

	SVR4 for president. Can four years of System V be *THAT* much worse
than 4 more years of George Bush?			-notebooks of a heretic

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 92 02:16:30 GMT
From:      ahalim@ics.uci.edu
To:        comp.protocols.tcp-ip
Subject:   Need doc for FTP


Hi
I need to write a client that talks directly with tftpd using the FTP
protocols. Besides the RFC for FTP that I already have, are there any
other sources (like user-manual, book, sample-programs, etc) that can
help me get started?

Please reply directly to my mailbox.
Your help is greatly appreciated!

/aha

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 03:38:26 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: subnet masks

In article <1992Jul14.203249.15560@phri.nyu.edu>, roy@alanine.phri.nyu.edu (Roy Smith) writes:
>
>	Are subnet masks assigned on a per-host, per-network, or
>per-interface basis?  Does it make any sense to have different subnet masks
>on different interfaces on a given host?  I just re-read RFC-950 and it's
>not particularly clear on this.  My impression is that it has to be
>per-network, but it's not 100% clear.
>

In general, you have the same subnet mask for an entire network.
Each host with an interface on that network will have that subnet
mask associated with that interface.

There isn't much in the RFC literature that precludes having
variable-width subnet masks. Formally it is ok to have subnets
of differing size. This is mentioned in rfc 1219, which is, btw,
'informational only'. Unfortunatly certain routing algorithms (RIP
rfc1057, and I think IGRP) assume that all subnets are of the same
size within a given network. There are probably other things that
will break with variable-width subnet masks.

One routing protocol,  OSPF doesn't have such limitations, it makes
special provisions for propagating subnet masks. This paves the
way for more flexible sizing of subnets, a la rfc 1219.

		-John Kalucki
		johnk@gordian.com




-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 03:50:34 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI interface [SUMMARY]

In article <1992Jul14.030225.16569@gordian.com>, johnk@gordian.com (John Kalucki) writes:
>A co-worker is trying to port an IP application to a machine that
>only supports the TLI interface to IP (i.e. it doesn't support BSD
>sockets). I think this interface is sometimes called (perhaps
>incorrectly) the STREAMS interface to IP.
>

Judging by the response, W. Richard Stevens must be a rich man. I
received 5 e-mail responses mentioning it, and only 1 that didn't!

Thanks to all who pointed out the Stevens book:

tashhian@sword.eng.pyramid.com (Rob Tashjian)
evans@titan.tsd.arlut.utexas.edu (Eric Evans)
Doug.McCallum@Central.Sun.COM (Doug McCallum)
fjd@ultra.com (Farokh J. Deboo)
scott@npg-sd.SanDiegoCA.NCR.com

And thanks to the only person who didn't mention the omni-present
bible of Unix Network Programming:
nick@spider.co.uk

		-John Kalucki
		johnk@gordian.com




-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 06:18:43 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-graceful close of TCP socket connections

In article <1992Jul13.231941.19934@efi.com> chrisp@efi.com (Chris Phoenix) writes:
>First: Someone suggested about a month ago that to avoid keeping
>around connections in the TIME-WAIT state, you could do an ungraceful
>close of the connection.  My question is: Doesn't this have the effect
>of throwing away all data that has not been received by the
>application already, on both sides of the connection?

Yes, it would, so this approach is only appropriate in cases where the
two parties have a preconceived idea that there isn't any important
data in the pipe.  For example, it would be appropriate in a protocol
in which one side sends "quit" and the only thing the receiving side
is expected to do after having received the "quit" is close the
connection.

>Now a question about TIME-WAIT.  Is it true that the purpose of
>TIME-WAIT is to give both sides a better chance of getting the ACKs
>and sequence numbers they need?

Although this description doesn't appear accurate to me, the example
you give following it is correct.  The way i'd describe it is that
TIME-WAIT is required so that the context of the connection is retained
long enough to allow for recovery from the last ACK getting lost.  If
the last ACK is lost, the other node will retransmit the FIN.  If the
connection context is gone, that FIN wil generate a RST, causing the
other node to believe the connection closed abruptly even though it
successfully closed gracefully.
						don provan
						donp@novell.com

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 08:40:55 GMT
From:      wiesel@ipf.bau-verm.uni-karlsruhe.de (Joachim Wiesel Ext. 2316)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun's PCNFSD 2.0 with PC-NFS 3.5?

This may be the wrong newsgroup --- but:  For all people administering
NIS/NFS systems I recommend reading
        'Managing NFS and NIS' by Hal Stern (O'Reilly&Associates).

In this book at page 64 ff. Hal decribes accurately what to do if you want to change
NIS master servers and/or NIS slave servers.

Joachim 
---

Joachim Wiesel, Institut fuer Photogrammetrie und Fernerkundung,
Universitaet  Karlsruhe, Englerstr. 7, D-7500 Karlsruhe, Germany
Phone: +49 721 608 2316                      Fax: +49 721 694 568
Internet: wiesel@ipf.bau-verm.uni-karlsruhe.de


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 92 08:50:10 GMT
From:      gdmr@dcs.ed.ac.uk (George Ross)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: How to multihome a server (using YP in a DNS-friendly way)

Background: our (dcs.ed) network currently has about a couple of hundred
clients and maybe 20 servers hung off perhaps a dozen or so ethers (it's the
Great Summer Reshuffle Time, which is why the numbers are a bit vague!).  Most
of the servers are multi-homed (they're our routers in their spare time). 
Most of them carry home directories as well as binaries.  We use amd to
auto-mount all home directories and local binaries.  The NFS servers are also
all NIS and DNS/Hesiod servers.  I would call this a largish network (no doubt
others will consider it tiny 8-)).

In article <1992Jul14.163324.1351@Warren.MENTORG.COM>, tal@Warren.MENTORG.COM (Tom Limoncelli) writes:
> Now introduce a file server, say a Sun 4/490.  It's going to be equally
> used by machines on both networks, so we put two ethernet boards into
> it, call one board "bigserver-left" and the other board
> "bigserver-right".  Machines on one network nfs-mount off of
> bigserver-left and machines on the other network nfs-mount off
> bigserver-right.

[Aside: the "second" ether interface may not have the same throughput as the
"first" interface.  SBus-based machines are OK.  VME-based machines may well
have faster access to the on-board interface than to any additional
interfaces.  The LANCE (le*) is inhernetly faster than Intel's chip (ie*) --
ref Van Jacobsen.]

This is how we used to do it.  It was fine while things were still small, but
as our network grew our amd maps were becoming more and more unwieldy (I think
amd's "-wire" hack originated here), so much so, in fact, that we were
seriously considering adopting a DNS solution when much greater University
connectivity and finally Internet connectivity forced our hand.

> This all works fine BUT it this is not how I see other sites
> configuring things.  I see other sites give both ethernet boards
> different addresses but the same name ie, in /etc/hosts:
> 
> 137.202.214.100   bigserver
> 137.202.215.100   bigserver
> 
> and two "A" records in their DNS zone for the one machine.

This is what we do now.  The nameservers return both (all) the addresses
sorted according to the originating resolver's address, and amd and mount just
choose the first address returned.  In most cases, including all the most
common ones, the "best" address is used automatically.

HOWEVER: for this to work properly the resolver MUST be called directly by the
process performing the mount.  You have to statically-link the resolver into
amd (which we do for bootstrapping reasons anyway) or drop it into libc.so. 
It's no good accessing the DNS via the NIS.  If you do, the resolver is called
by ypserv and the addresses returned are sorted to suit the ypserv machine,
NOT the machine performing the mount.  In our setup this would most likely
result in a random interface being chosen; other scenarios could easily result
in the wrong interface being consistently chosen.
 
> So, I guess my question is "What's the best way to multihome
> a server and how does it all work?"

"It depends".  If you have a small isolated network then "-left" and "-right"
is probably the easiest way to go.    If you have a large network then using
the DNS is much easier, and if you have Internet connectivity so much the
better as you can amortise the cost of setting up the DNS in the first place.
For a middle-size network it's less clear.  "-left" and "-right" has a lower
setup cost but a higher maintenance cost, and that maintenance cost increaese
as your network size increaese.  DNS has a higher setup cost, but a much lower
maintenance cost that's essentially constant irrespective of network size.

> Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
 
-- 
George D M Ross, Department of Computer Science, University of Edinburgh
     Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Tel: 031-650 5147   Internet: gdmr@dcs.ed.ac.uk   JANET: gdmr@uk.ac.ed.dcs

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 12:30:26 GMT
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: How to multihome a server (using YP in a DNS-friendly way)

In <BrEI68.7Bo@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:

Hey, I know you! :-)

>That's because a DNS query for bigserver will return both addresses,
>but if the query came from a machine on the "left" ethernet,
>bigserver-left will be the first address listed, and if it came from
>the "right" ethernet, bigserver-right will be the first address
>listed. Nfs-mount uses the first address it gets, so machines on the
>left hand side ethernet will mount bigserver-left, and machines on the
>right hand side ethernet will mount bigserver-right.

I didn't know DNS sorts the queries so that the "local" net will be
the first one.  I guess that's the magic I was seeing.  (silly me,
I knew that DNS returns a list of answers)

>If one ethernet is down, and the terminal server attempts to telnet to
>that seide of bigserver first, it will timeout and try the second
>address it got from its DNS request. No magic there. I find it kinda

Yes, I guess that's not magic.

>hard to believe that you get random behavior if both ethernets are up;
>where is your terminal server connected?

Well, I guess it isn't random, I just never really looked hard for
a patern.  The terminal server is on yet another network.  (Ah, the
old "yet another network" trick :-) ).

>The answer depends on what you want to do with your multihomed host.
>If you're using it as an NFS server, then the setup above is good.

You mean the -left/-right solution is good?  Or the DNS solution is
good, or both are good?

>[[IETFers: Please let's not start another flame war here about
>multihoming and policy-based routing :-) ]]

That's their job, isn't it?  :-)

Thanks!
Tom

-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
I never understand statements like, "I saw the beta version and it
had a lot of bugs."  If we took the bones out it wouldn't be CRUNCHY!

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 92 15:05:42 GMT
From:      brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein")
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

Piscitello writes:
> Your dispute with the IESG and Stephen Crocker notwithstanding, I
> find your electronic "conduct" reprehensible. I do not wish
> to interfere with your ability to express your opinions publicly,
> but I find your frequent, highly abusive personal attacks deplorable.

``Personal attacks''?

Jim Galvin said, on 2 January: ``It is the opinion of those SAAG members
who have been carefully tracking this effort that the protocol should be
renamed as the "Identity Server" (or something similar)... If you agree
you will need to revise your document accordingly, after which we will
push it on to the "standards track" as expeditiously as possible.''

I agreed. I revised my document accordingly, two days later, after
asking rfc931-users about the name change. SAAG did not push my document
onto the standards track. In fact it did nothing at all. Despite my
requests SAAG never told me anything and never acted. (Communication
started again two months later, after I complained to Vint Cerf.)

You tell me: Was Galvin telling the truth?

If you think that this is a ``personal attack,'' and that you can stop
such ``personal attacks'' by quoting the NSFNet AUP, then I'm afraid you
have a lot to learn about what free speech means in this country.

---Dan

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 15:33:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: How to multihome a server (using YP in a DNS-friendly way)

In article <38910@skye.dcs.ed.ac.uk>, gdmr@dcs.ed.ac.uk (George Ross) writes:
> ...
> This is what we do now.  The nameservers return both (all) the addresses
> sorted according to the originating resolver's address, and amd and mount just
> choose the first address returned.....


Inside Silicon Graphics we use NFS, automount, NIS, DNS, and multihomed
machines to hold the many source trees.  The source tree servers are
generally not routers; they generally are not expected to forward IP.
DNS is used only for inter-domain addressing.  We use NIS (YP)
exclusively within domains.  Most of the network of hundreds of class-C
networks and thousands of workstations uses RIP, but Cisco's
proprietary botch is used in the wide area network.  Routers are mostly
Silicon Graphics boxes, with some Ciscos.

After years of fruitless worrying about getting the "best" or "right"
address into the right NIS domains, I modified the RIP daemon, routed,
to accept a "-m" which tells it to advertise a host-route for the
machine's "main" address on all interfaces.  "-mq" tells it routed
advertise only that host-route, and be quiet otherwise.

Because of this, machine all over the world always use the primary name
and IP address of each source machine.  Routing takes care of
preventing the extra hops to the multi-homed servers.

The only trouble we've had is that Cisco routers go crazy in the
presense of host routes.  We use host routes a lot for SLIP links, so
we have had a lot of aggrevated Cisco jun--uh boxes.  In response, I
modified the SGI routed again, to add an "-h" which "aggregates" host
routes back into IP network routes in the obvious way; a host route to
the same next hop as the corresponding network route and with a larger
metric is not advertised.

The man-page for routed on any up-to-date IRIS has more information.

I don't think we feel any significant proprietary interest in these
routed source changes.  Except for the death of CSRG and the large
changes in the routed source caused by the new routing table
interface, we would have offered them for 4.4BSD.  I suspect we'd
be happy to give them to either of the de facto, sort-of heirs to CSRG.



Vernon Schryver,  vjs@sgi.com

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 16:46:17 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Query re. transition to CLNP

 peter@ferranti.com (Peter da Silva) writes:
> ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes:
>> As many helpful people told me, this isn't the best group for this. Try
>> info.ietf, or subscribe to big-internet list distributed by munnari.oz.au.
>
>I was wondering why there hadn't been any comment on this here. This seems
>a trifle narrow-minded, since this transition IS going to impact us folks
>with our little-i-internets whether or not we're on the big-I-Internet.
>
>Sigh. The Internet insists on flooding Usenet with bogus groups, but when
>there's something on that's really useful THEN they hide it away in a hierarchy
>of their own. Double-sigh.

There is a lot of traffic on the big-internet list.  The S/N ratio is
quite good (when the politiking stops), but few applications people or
users will find much of interest there.  It's a group of network
protocol designm, and since many of the points being discussed will
be transient and not actually reflect the final protocols, I'd question
whether most people on this group would find the content 'useful'.

Thems' just my opinions,

Erick


-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1992 16:47:50 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: How to multihome a server (using YP in a DNS-friendly way)

In article <38910@skye.dcs.ed.ac.uk> gdmr@dcs.ed.ac.uk (George Ross) writes:
>HOWEVER: for this to work properly the resolver MUST be called directly by the
>process performing the mount.  You have to statically-link the resolver into
>amd (which we do for bootstrapping reasons anyway) or drop it into libc.so. 

Unfortunately, /usr/etc/mount is statically linked.

>It's no good accessing the DNS via the NIS.  If you do, the resolver is called
>by ypserv and the addresses returned are sorted to suit the ypserv machine,
>NOT the machine performing the mount.  In our setup this would most likely
>result in a random interface being chosen; other scenarios could easily result
>in the wrong interface being consistently chosen.

It would also be a problem at our site, since our NIS servers are almost
all multihomed.  However, for sites where the NIS servers aren't
multihomed, the NIS server and client will generally be on the same subnet,
so the addresses will be sorted properly.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 92 17:02:55 GMT
From:      nick@spider.co.uk (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)

In article <id.7C2R.423@ferranti.com> peter@ferranti.com (Peter da Silva) writes:

 [ Talking about an API for tcp ]
>
>So would, perhaps, a file I/O API that worked like this:
>
>	fib = malloc(sizeof(struct FileInfoBuffer));
>	fib->fib_clean = 0;
>	initialize_fib(fib);

  [ ... 16 more lines of wonderful code to open a file ]

>
>But most of us prefer operating systems that hide this sort of detail for
>the general case, and provide an escape (ioctls) for more complex operations.
>
>If you want OS/360, you know where to get it...

Just be grateful that they never let the folk who did TLI near the file
system interface!

Nick

-- 
Nick Felisiak 						nick@spider.co.uk
Spider Systems Limited					+44 31 555 5166

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 1992 22:20:39 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary of TAP discussion

brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein") writes:

>``Personal attacks''?

	Would you prefer ``endless whining''??

	Given that:
		a) This argument has already been had in the past
		b) There was (clearly!) no agreement in the past
		c) This "dialog" in comp.protocols.tcp-ip has turned
			into a repetitive, "I said he said she said"
			follow-up war that is helping nobody's credibility
		d) There's no evidence that discussing the topic here
			going to cause agreement

	Can you guys agree to disagree someplace else?

mjr.
-- 

	SVR4 for president. Can four years of System V be *THAT* much worse
than 4 more years of George Bush?			-notebooks of a heretic

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 1992 03:39:29 GMT
From:      craig@ec.uwa.oz.au (Craig Richmond - division)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc,comp.dcom.lans.ethernet,comp.protocols.appletalk,comp.windows.x
Subject:   Re: NCD X terminals over AppleTalk/TCP-IP

mcgrant@rascals.stanford.edu (Michael C. Grant) writes:

>Now, I've been looking at acquiring an NCD X terminal for use in the
>apartment, and I would really really prefer to avoid (1) having to tie up
>my phone line, and (2) adding another line (which may not even be possible
>anyway).  So, I was wondering if there was a standalone box for a single
>user which would strip the incoming TCP/IP packets of their AppleTalk
>envelopes and repackage them as Ethernet packets, and vice versa for
>outgoing packets.

One solution would be to by a macintosh and run MacX.  (I am not saying
these are good solutions).  This way you get a great word processor out of
the deal.  I seem to recall reading that you need at least 9600 baud for
"satisfactory" X-Windows performance and I personally wouldn't want to see
it running that slow.

There are protocols that enable TCP to travel through appletalk and vice
versa.  These are generally built into Macintoshes adn Appletalk routers.
Depending on the flavour router they have between their appletalk network
and the ether, you may be able to use these, but I don't know what your
chances are of getting a box to convert your X-Terminal outgoing TCP into
appletalk packets.

Hope this has helped a little bit.

Craig
--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au
     "Only users are allowed to make messes on their computers"  I.M.VI

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 92 08:36:36 GMT
From:      sensei@dojo.mi.org (the Maniak)
To:        comp.protocols.tcp-ip
Subject:   The care and feeding of MX records


I'm looking for documentation or FAQs on what MXes are all about, how to
set one up in a Unix TCP/IP universe, etc.  Any pointers would be
appreciated.  For that matter, is there an FAQ for this group, other
than the various RFCs?  :)

                                                ...Sensei

--
 Internet:  sensei@dojo.mi.org
 UUCP:  ...!wsu-cs!dojo!sensei                      


-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 13:31:08 GMT
From:      chad.w.german.1@nd.edu (Chad W. German)
To:        comp.protocols.tcp-ip
Subject:   Telnet, Tn3270 w/ ODI Shell

What changes need to be made to config.tel if wanting to run the ODI novell 
shell and Telnet or Tn3270 together.....

Thanks

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 13:47:03 GMT
From:      wvb@sunvax.sun.ac.za
To:        comp.protocols.tcp-ip
Subject:   Is RFC877 really used?

Is RFC877 really used by any significant proportion of IP over X.25
systems out there?  We need to find out what we must make happen for
a system we have (with X.25) to connect and interoperate with other
TCP/IP hosts over X.25.  RFC877 is not the most complete of the Internet
specs, and any further notes or experiences will really help.

Thanks 

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 14:58:50 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        de.comm.internet,comp.protocols.tcp-ip,eunet.misc
Subject:   Unique internet IP adr. without changing local IPs ?


Hi guys!
In our company we have decided to connect to the world wide internet.
Therefore I think we have to apply for a world wide unique IP
address. My problem is, if we get this IP address we don't want to
change all our local IP addresses we are using now. But if we don't
act this way then we have local IP addresses which are matching IP
addresses on the internet. Is there configuration to solve this
problem. I think this problem should has been appeared before. I don't
want to change 500 nodes.?
Any information would be appreciated!

-- 
------ < MAGIC > ------

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 15:15:02 GMT
From:      bgi@stiatl.salestech.com (Brad Isley)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,sti.technical
Subject:   Re: Sun's PCNFSD 2.0 with PC-NFS 3.5?

bgi@stiatl.salestech.com (Brad Isley) writes:

>Question: Can we get and use the rpc.pcnfsd 2.0 that comes with PC-NFS 4.0?
>          Or, should we upgrade to PC-NFS 4.0?

All is working now.  The 386i is off the net.  The 4/470 is the NIS master.
I installed the 2.0 pcnfsd, but all our users have to upgrade to PC-NFS 3.5c
for NIS to work (or so it seems).

Thanx for all the email.
-- 
    Itchy, Scratchy, Homer, Bart, Bugs, Elmer...  The list goes on and on.
                 They're so much more real than Congress...
-----------------------------------------------------------------------------
bgi@salestech.com           (404) 841-4169           Sales Technologies, Inc.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 15:30:23 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.unix.solaris,comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   SLIP for Solaris 2.0?

Does anyone have a version of SLIP for Solaris 2.0?

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


-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 17:36:42 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Is RFC877 really used?

In article <5413.2a6561b7@sunvax.sun.ac.za> wvb@sunvax.sun.ac.za writes:
>Is RFC877 really used by any significant proportion of IP over X.25
>systems out there?  We need to find out what we must make happen for
>a system we have (with X.25) to connect and interoperate with other
>TCP/IP hosts over X.25.  RFC877 is not the most complete of the Internet
>specs, and any further notes or experiences will really help.

RFC877 has been used as the basis for most IP over X.25 for the past
several years.  Admittedly it is a bit incomplete, but there seems
to be general interoperability amoung most vendors.  More recently
an IETF working group has updated the work and there is an Internet
Draft called "Multiprotocol Interconnect over X.25 and ISDN".  This
documents use of ISO NLPIDs (and use of SNAP) for protocol demultiplexing.
This should eventually find its way into the RFC track.

Art

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 1992 18:31:31 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Is RFC877 really used?

In article <5413.2a6561b7@sunvax.sun.ac.za> wvb@sunvax.sun.ac.za writes:
   Is RFC877 really used by any significant proportion of IP over X.25
   systems out there?  We need to find out what we must make happen
   for a system we have (with X.25) to connect and interoperate with
   other TCP/IP hosts over X.25.

Yes, if you're going to exchange IP over an X.25 network, RFC-877 is
the way to do it.  Though, as you note, there's plenty of slack left
there for ambiguities, and the tricks and wisdom of the implementors.
And one implementor's wisdom may not be interoperable with another's.

   RFC877 is not the most complete of the Internet specs, and any
   further notes or experiences will really help.

Updating RFC-877 is one focus of the IETF's "IP over Large Public Data
Networks" working group.  Their most recent product is available from
nic.ddn.mil:internet-drafts/draft-ietf-iplpdn-x25_isdn-03.txt.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 1992 20:28:27 GMT
From:      jdschn@nicsn1.monsanto.com (John D Schneider)
To:        comp.protocols.tcp-ip
Subject:   MAC TCP/IP print utilities

I am sorry if this is outside the realm of this newsgroup.  I am looking for
a program that runs on a Mac that allows you to print a file over TCP/IP to
a printer on a Unix machine.  Perhaps something on the Mac that connects to
and talks to the lpd daemon.  I would prefer public-domain, of course, but
a vendor source would be alright, too.

Thanks in advance,

John Schneider
p.s. Please post to me directly, I do not frequent this newsgroup.

*******************************************************************************
*  John D. Schneider                Internet: jdschn@nicsn1.monsanto.com      *
*  Research Computing Consortium    Telephone: (314)537-6808                  *
*  Monsanto Company - Mail Zone GG3I _________________________________________*
*  700 Chesterfield Parkway North   | "No sciences are better tested than     *
*  St. Louis, Missouri 63198        |  the religion of the Bible."            *
*                                   |                   - Sir Isaac Newton    *
*******************************************************************************


-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 20:41:17 GMT
From:      dan@willamette.edu (Daneher D. Revel)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.system,comp.protocols.appletalk
Subject:   MacTCP ARPs itself!

I have noticed that MacTCP ARPs its own IP address when it starts up,
if it receives an ARP response it quits and gives me a dialog about not
having installed it correctly.

The problem is: I have a router on my network that proxy-ARPs a response
to MacTCP's ARP.  I suppose MacTCP refuses to run because it suspects that
it has a duplicate IP address, but...

I don't have control over the router or I could just turn the proxy-ARP
off (I don't think it's needed here).  Are there any other solutions?

Is MacTCP behaving correctly when it ARPs itself?

I have assumed that MacTCP ARPs itself to identify duplicate IP addresses
could it have another motive?

Thanks.
-- 
Dan Revel (dan@willamette.edu)					Nullum
Network and Technical Services					Gratuitum
Willamette University						Prandium

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 1992 21:18:59 GMT
From:      umrice02@ccu.umanitoba.ca (Stephen Rice)
To:        comp.protocols.tcp-ip
Subject:   NEEDED: Opinions on PC-NFS - Do I need it?

I have recently obtained a copy of SOSS and I understand that, although it puts
a PC into server mode for a NFS mount from UNIX, you cannot mount the DOS disks
on another PC.  My question is: Does PC-NFS support this?  Is a shareware/free-
ware version out there that might prove useful?

So you get the picture, we have a TCP/IP network consisting of 2 UNIX machines
and 3 PCs (386s and better).  The PCs are running NCSA Telnet (the newest 
release).  The ability to 'mount' a PC disk on another PC would be a great
asset and, yes, I am willing to sacrifice the slave machine to leave it in
'host' mode.


As an aside, Telnet seems to not be able to allow users to log in via 'telnet'
onto a PC.  Is this a shortcoming or are we doing something wrong?  It seems to
work OK for 'lpr' and 'ftp' but Telnet ziltch.  We can 'telnet' from a PC to
UNIX (or, yes smart-ass, UNIX-UNIX) but not UNIX to PC or PC to PC.


Any help would be appreciated.


P.S.	Thanx to all of the people who responded to my query about TCP/IP for
	the IBM and PC.  As mentioned above, this package seems to work just
	DANDY!
-- 
+-----------------------------------------------------------------------------+
Stephen Rice                                          "I am, therefore I think"
umrice02@ccu.umanitoba.ca                 "These are definitely my own opinions
University of Manitoba  CANADA                  or I would not have said them."

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 92 22:48:47 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.system,comp.protocols.appletalk
Subject:   Re: MacTCP ARPs itself!

In article <1992Jul16.204117.8574@willamette.edu> dan@willamette.edu (Daneher D. Revel) writes:
>I have noticed that MacTCP ARPs its own IP address when it starts up,
>if it receives an ARP response it quits and gives me a dialog about not
>having installed it correctly.
>
>The problem is: I have a router on my network that proxy-ARPs a response
>to MacTCP's ARP.  I suppose MacTCP refuses to run because it suspects that
>it has a duplicate IP address, but...
>
>I don't have control over the router or I could just turn the proxy-ARP
>off (I don't think it's needed here).  Are there any other solutions?
>
>Is MacTCP behaving correctly when it ARPs itself?
>
>I have assumed that MacTCP ARPs itself to identify duplicate IP addresses
>could it have another motive?

Broadcasting an ARP for your own address(es) is a fairly well accepted
mechanism to check for duplicate IP address assignments.  Duplicate IP
addresses can cause much trouble on IP networks.  Unless you have mis-
configured the IP address of the MAC, the router should absolutely not
respond as a proxy for that IP address.  That would screw up ARPing for
any machine on that IP subnet.  Make sure that the IP address you are
trying to use belongs on this subnet and not a subnet beyond the router.

Art

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 1992 00:02:08 GMT
From:      cataldo@samui.trl.OZ.AU (Tony Cataldo)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   REPOST: Setting up clients to access MVS/ESA NFS server (DFP Ver 3.1.0)


I am currently installing an NFS server on an MVS/ESA system. In order to set
up a client to access the NFS server, 3 modules have to be compiled on the
client workstation. These modules are called mvslogin, mvslogout (mvslogut on
PC) & showattr. The source codes are supplied by IBM and can be compiled
without any problem on a Sun Workstation. However, we are unable to compile
the source codes on two clients:
 
1.  NCR3000 with System 5 Release 4 Unix
2.  386 PC running Wollongong's Pathway NFS software & Ms-Dos Ver 5.0.
 
Has anyone successfully compiled the modules on the above 2 platforms? If so,
please kindly provide details of the necessary modifications required. I would
also appreciate any feedbacks you may have on the MVS NFS server, and also
other clients that have been succesfully set up to access the server.
 
Thanks.
Albert Fu.

Please direct your email to t.cataldo@trl.oz.au, so that he can forward
it to me. 

Will sumarise for those interested!!!?!
Tony CATALDO				

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 1992 00:06:04 GMT
From:      oldera@twg.com (Ed Alcoff -  Prod Mtg)
To:        comp.protocols.tcp-ip
Subject:   Looking for "fetch"

I'm looking for information and/or a contact at Dartmouth
for the Mac (DOS?) based ftp program called "Fetch".

Thx in advance,

Ed Alcoff
oldera@twg.com


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 1992 00:23:21 GMT
From:      peterd@tscc2.macarthur.uws.edu.au (Peter Degotardi)
To:        comp.dcom.sys.cisco,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   pc-route, cisco, token-ring & IBMTOKEN. Incompatible ?

Does anyone out there in netland use a combination of PC-ROUTE, CUTCP,
the IBMTOKEN packet driver and CISCO boxes on 16Mb Token Ring networks (IBM) ?
We use CISCO's to bridge/route 2 remote sites, and PCROUTE to route between
local rings.
This more or less works.
We have problems with terminals who use the cisco's as their default gatways,
not being able to start tcp/ip sessions (it takes >5 attempts before the
cisco's see them)
The other problem came when we went to upgrade our cisco's to use the
multi-port token ring cards. They didn't work (neither did the 8.3 software)
It has been suggested that the IBMTOKEN packet driver and the PCROUTE machines
are at fault.

I'mt trying to find a site with a similar setup *THAT WORKS* so that I can
show that our current setup is ok.

Anyone have such a setup ?

--
Peter Degotardi        (__)   *  University of Western Sydney, Macarthur
PC Support Programmer  /00\   *  Computing Centre.
Fax    +61 46 26-6937   oo    *  Campbelltown, New South Wales, Australia !
Email  p.degotardi@uws.edu.au *  Just in case - 'My opinions are all mine !'

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 1992 07:57:30 +0000
From:      nigel@cotswold.demon.co.uk (Nigel Roles)
To:        comp.protocols.tcp-ip
Subject:   Summary of TAP discussion

Can someone post a summary of the summary please.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 1992 08:08:04 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Unique internet IP adr. without changing local IPs ?

In article <1992Jul16.145850.1980@edfd.uucp> markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:
>In our company we have decided to connect to the world wide internet.
>Therefore I think we have to apply for a world wide unique IP
>address. My problem is, if we get this IP address we don't want to
>change all our local IP addresses we are using now. But if we don't
>act this way then we have local IP addresses which are matching IP
>addresses on the internet. Is there configuration to solve this
>problem. I think this problem should has been appeared before. I don't
>want to change 500 nodes.?

Now you know why most TCP/IP configuration guides and gurus recommend
getting an official IP subnet even if you're not currently connected to the
Internet.

I don't think there's a way to do what you want.  You apparently are
looking for a gateway that would translate your old addresses to new
addresses as it forwards the packets.  While this could be done for
addresses in the IP headers (but I've never heard of a gateway with this
functionality), that's only a partial solution.  IP addresses are often
embedded in the higher-level protocol data (e.g. the FTP "PORT" command, or
DNS A records), and the gateway would have to find these and convert them.
Also, TCP and UDP checksums include the source and destination addresses,
so the gateway would have to recompute these higher-level checksums.  If
you try to use a transport or application protocol that the router doesn't
know about, and it has embedded IP addresses or information based on IP
addresses, it won't be able to convert it.

Furthermore, you won't be able to communicate with the outside hosts whose
IP addresses you conflict with.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 1992 14:06:02 GMT
From:      mahesh@amnese.eng.uab.edu (B.G. Mahesh)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc,comp.unix.admin
Subject:   Need some info about X400 administration (SunNET MHS)


I am posting this for a friend in India. Please respond to
rani@ece.iisc.ernet.in directly.

thanks
Mahesh


-----------starts here---------------

hello,

	I am looking after X400 administration at the ERNET
	project, Indian Institute of Science, Bangalore, India.
	We have SunNET MHS version 7.0 running on a Sun Sparc 1+,
	running SunOS release 4.1.1 ( GENERIC + OSI ). I have a few
	questions regarding SunNET MHS configuration. It would be
	extremely helpful if anyone could please provide clarifications
	on the following points :

	   (i) I see from the SunNET MHS System Administration manual
	       ( page 191) that only IA5Text is supported as bodytype.
               Is it possible to extend the configuration to support
	       other body types, in particular Voice and Binary. Is
               software already available from Sun for this purpose ?

	 (ii) The timeout for connection establishment appears to be
	       about 2 days. How can this be increased ?

         (iii) In the configuration file this.gc for SunNET MHS, it is
		possible to give optional parameters like windowsize
	        (in neighbor-mta entry).  However, this is not documented
	        in the SunNET MHS System Administration manual.
		I would like to know the details of all possible options.

		Please respond at the earliest to rani@ece.iisc.ernet.in.

Thanks in advance,
Rani

_______________________________________________________________________________
Saraswathi Ammal.M.                     e-mail: rani@ece.iisc.ernet.in
Project Associate                       Phone: (91)-812-340855
ERNET Project                           Fax: (91)-812-340855 or
Dept. of Electrical Communication Engg.      (91)-812-341683
Indian Institute of Science
Bangalore 560 012, INDIA


_______________________________________________________________________________


-- 
B.G. MAHESH                           | Email : mahesh@evb.com
Software Engineer                     |         widget!mahesh@uunet.uu.net
SETT Inc.			      | 
Frederick MD                          |

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 92 15:54:18 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        de.comm.internet,comp.protocols.tcp-ip,eunet.misc
Subject:   Re: Unique internet IP adr. without changing local IPs ?

In article <1992Jul16.145850.1980@edfd.uucp> markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:
   In our company we have decided to connect to the world wide
   internet.  Therefore I think we have to apply for a world wide
   unique IP address. 

Yes, you (or your IP connectivity provider) will need to work that out
with hostmaster@nic.ddn.mil.

   My problem is, if we get this IP address we don't want to change
   all our local IP addresses we are using now.  

You could use an IP address from your assigned space on the outside of
a gateway system, and continue using your old address space
internally.  That way, people could connect to that gateway machine,
then invoke Internet-capable applications there.  The gateway machine
would operate as your mail hub, name server, etc.

The advantage of this scheme is that your network would be firewalled
from the Inernet and all your network-related administrative headaches
would be localized to that machine.  The disadvantage of this scheme
is that individual hosts on your network wouldn't have direct access
to the Internet.

   I don't want to change 500 nodes.?  

This is why I encourage everyone, whether or not they know yet that
they'll someday be connecting to the rest of the world, to get an
officially-assigned IP network number at the very beginning, while
they're still small, and save the headache later when they eventually
do get connected.  I've seen networks larger than 500 nodes with your
problem, and while it's not pleasant, it's at least a do-able task.

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 92 16:59:50 GMT
From:      art@acc.com (Art Berggreen)
To:        de.comm.internet,comp.protocols.tcp-ip,eunet.misc
Subject:   Re: Unique internet IP adr. without changing local IPs ?

In article <1992Jul16.145850.1980@edfd.uucp> markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:
>
>Hi guys!
>In our company we have decided to connect to the world wide internet.
>Therefore I think we have to apply for a world wide unique IP
>address. My problem is, if we get this IP address we don't want to
>change all our local IP addresses we are using now. But if we don't
>act this way then we have local IP addresses which are matching IP
>addresses on the internet. Is there configuration to solve this
>problem. I think this problem should has been appeared before. I don't
>want to change 500 nodes.?
>Any information would be appreciated!

About the only thing I can think of is to set up a "firewall" machine
which has two interfaces.  One of the interfaces gets hooked up to
the Internet with a legal address and the other hooked to your existing
network.  All Internet access would initially require logging into the
firewall machine and then going into the Internet.  Then you could
slowly start renumbering machines to legal addresses and setting up
the firewall to route between their new subnets and your old network.

Art

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 92 17:09:55 GMT
From:      umrice02@ccu.umanitoba.ca (Stephen Rice)
To:        comp.protocols.tcp-ip
Subject:   CLARIFICATION: NCSA Telnet problems

I recently posted a message regarding a problem I am having with telnet'ing 
into a PC this message is meant to define the problem a little clearer:

The problem is that I set up the PC in server mode (*) with NCSA Telnet for
the PC.  I find that I can ftp to that machine but I cannot Telnet to the
machine ("Request for invalid port..." etc.).  My question is: Is it possible
to setup Telnet for the PC to do this or am I doing something wrong?

*  As an aside, I am also having difficulty getting NCSA Telnet into server
mode.  I try to use 'telnet -s' to place a PC into server mode but after it
goes into server mode, it does not accept any FTP requests from any machine...
BUT if I issue 'telnet machine', where 'machine' is not currently accepting
telnet requests (ie. a PC not in server mode), the program attempts to telnet
to it which fails (of course) and places Telnet into server mode after which
any FTP requests are accepted.

Strange, huh?
-- 
+-----------------------------------------------------------------------------+
Stephen Rice                                          "I am, therefore I think"
umrice02@ccu.umanitoba.ca                 "These are definitely my own opinions
University of Manitoba  CANADA                  or I would not have said them."

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 92 18:06:09 GMT
From:      weare@bostech.com (Ged Weare)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet,comp.sources.wanted
Subject:   Help wanted: Interlan Ethernet drivers

Hi:

I just acquired two Interlan NP600A Ethernet cards real cheap, and am
trying to find drivers for DOS and AT&T Sys V/386 R3.2 (preferably STREAMS).

DOS:
I got the Clarkson (Crynwr) packet driver set, but no NP600A was
included.  I downloaded a packet driver, an NDIS driver and an ODI
driver from the Interlan BBS.  I don't know how to use the NDIS or
ODI drivers with NCSA Telnet or ka9q (seems to require some utilities
I don't have), and the Interlan packet driver requires the use of some
Novell utilities (WSGEN and some other *GEN I don't recall), instead of
just being the usual .COM file you get in the Clarkson collection.  So,
my questions are (for DOS):

1.	anyone have a NP600A packet driver I can use w/o the Novell
	utilities?
2.	Are the Novel utilities PD, and if so how do I get them?
3.	How do I use the NDIS and/or ODI drivers with the PD TCP/IP
	stuff, such as ka9q, NCSA Telnet, and so on?

I don't have any Novell or other commercial network SW, and don't want to
buy them (these are for private use, so no funds available).

Unix:
Interlan has a complete TCP/IP package for Sys V, but they sell it for
$1090, and it includes the NP600A itself.  This is way outside my budget,
and I already have the cards anyway.  I can do it a lot cheaper by
junking the NP600As, and buying something mainstream like 3C503's.

They can't, or won't, sell or give me just the ethernet driver.  They
also won't give me technical docs that would let me write my own
driver.  I could go on at length about this situation, but I won't.  Let
me just say that other PC peripheral  board manufacturers are often
very generous with their unix drivers and/or docs, which is the way it
should be.  Let me also say that the Interlan Tech Support people were
very good, I have no complints with them.

Anyhow, my unix questions are:

4.	Does anyone have/know where there is an NP600A driver for
	AT&T Sys V/386 R3.2?  Streams, preferable, but not picky.
5.	Does anyone happen to know the programming characteristics
	of the NP600A?

Again, I don't want to spend money; I can always buy a cheap supported
controller at low cost and junk the NP600As.

Apologies for length of this: trying to preempt answers I already know!  
E-mail replies on the above would be appreciated.  Thanks in advance.


----
Jed Weare                      |     weare@bostech.com
Boston Technology              |     (617) 246-9000 x3519
100 Quannapowitt Parkway       |     Amateur Radio NF1Z
Wakefield, MA 01880.           |

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 92 18:21:01 GMT
From:      coolidge@speaker.wpd.sgi.com
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.system,comp.protocols.appletalk
Subject:   Re: MacTCP ARPs itself!

In article <1992Jul16.224847.9115@acc.com>, art@acc.com (Art Berggreen) writes:
|> In article <1992Jul16.204117.8574@willamette.edu> dan@willamette.edu (Daneher D. Revel) writes:
|> >I have noticed that MacTCP ARPs its own IP address when it starts up,
|> >if it receives an ARP response it quits and gives me a dialog about not
|> >having installed it correctly.
|> >
|> >Is MacTCP behaving correctly when it ARPs itself?
|> >
|> >I have assumed that MacTCP ARPs itself to identify duplicate IP addresses
|> >could it have another motive?
|> 
|> Broadcasting an ARP for your own address(es) is a fairly well accepted
|> mechanism to check for duplicate IP address assignments.  Duplicate IP
|> addresses can cause much trouble on IP networks.  Unless you have mis-
|> configured the IP address of the MAC, the router should absolutely not
|> respond as a proxy for that IP address.  That would screw up ARPing for
|> any machine on that IP subnet.  Make sure that the IP address you are
|> trying to use belongs on this subnet and not a subnet beyond the router.
|> 
|> Art

There's another reason, too. Many ARP implementations will cache
any ARP requests they receive that are not for their own address.
This has a couple advantages: a) any attempt to talk with that host
need not generate an ARP request, so the one unsolicited ARP can
prevent many ARPs from individual hosts trying to talk with the
original, saving network bandwidth and reducing the overhead every
node would otherwise have in processing many ARPs not for itself, and
2) It allows a host that has replaced its Ethernet board (or otherwise
changed its IP or medium address) to let other hosts know, avoiding
stale entries in remote AREP tables that could preclude communication.

Don Coolidge
coolidge@speaker.wpd.sgi.com 

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 92 18:42:14 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        de.comm.internet,comp.protocols.tcp-ip,eunet.misc
Subject:   Re: Unique internet IP adr. without changing local IPs ?

>In our company we have decided to connect to the world wide internet.
>Therefore I think we have to apply for a world wide unique IP
>address. My problem is, if we get this IP address we don't want to
>change all our local IP addresses we are using now. But if we don't
>act this way then we have local IP addresses which are matching IP
>addresses on the internet.

	I've set a few of our customers up like this for exactly the
reason you describe. We do it as part of our internet firewall offering,
which includes a routing configuration that isolates all routes between
the internal network and the internet.
	As a result, internal nodes with addresses that are "illegal"
are hidden and don't cause any problems. Of course, when someone
tries to do mail or file transfer through the firewall, they run into
problems and are politely encouraged to "get an address".
	At least the private network gets to make a slow transition
and cut-over to a real addressing scheme rather than having to change
everything all at once.
	Basically, what you do is set up an isolating subnet and show
a route to it to the internet. (like 192.5.214, which is one of my
isolated subnets) The host(s) on that net act as nameservers and
mail exchangers, and run FTP and telnet gateways that allow internal
systems access out. Routes to the isolated subnet are also given
to internal hosts, so they can mail out and whatnot. Internal systems
never get a route to the internet, just to the isolating subnet -
there is no direct exchange of data between the two networks - all
data has to go through the "gatekeeper" on the isolated subnet.
	I have a paper on how we do this that I'm presenting at
FEDunix. I can put a copy of the file up for FTP, I guess.

mjr.
-- 
	There are only ~17,000 possible three-letter acronyms left for possible
products. When the current supply runs out, in 1994, the computer industry will
transition to a ten-letter product acronym scheme that can support naming of
products and vaporware well into the year 2,000.	-notebooks of a heretic

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 1992 21:05:18 GMT
From:      matthews@mis.uswest.com (John Matthews)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Good 10BT transceivers?


Does anyone know of companies making transceivers that sound like the one
described below.  I am looking for nice, tiny transceivers that offer as
many diagnostic functions as possible.  So far, I like what I've seen with
the CSP transceivers (have these), LanTronix (Only seen in magazines) and
ANCO (Only seen in magazines).  Most of these only offer a subset of what
I've listed below.  If you REALLY like the transceivers you're using, then
please reply anyway.
				Thanks,
					John Matthews
					matthews@mis.uswest.com



    THE PERFECT 10BT TRANSCEIVER
    ----------------------------

    - 2 or 3ft Pigtail Cable with Thumb-Screws.

    - both AUI cable and RJ-45 should come in same place (Rear)

    - should have square tri-state LEDs mounted on corner so that
      LEDs are visable from two different mounting positions.

    - very small

    - reasonably priced. ($50-$100)




      RJ45    +---------+
    -------||||         |
              |         |  <-- 4 LEDs should go on a corner here
    +=========|         |
    | AUI     +---------+
    |
    |
    | 2-3ft cable -|||
    +==============|||     AUI connector with thumb screws
                  -|||     Molded plastic hoods (Lightweight)


                            NOTE: It would be a good idea to supply
                                  customer with 2 standoffs to replace
                                  worthless slide-locks.  Maybe even
                                  a couple of pieces of Velcro for
                                  mounting.


    SQE - ON/OFF switch   Both of these switches should be accessible
    LNK - ON/OFF Switch   by removing "at most" one screw.  It could be
                          openly accessible as well.


    4 TRI-STATE SQUARE LEDS
    -----------------------

    o SNDLNK/TX-DATA/COL) Green=Send-Link, Amber=TX-DATA, RED=Collision

    o RCVLNK/RX-DATA/JAB) Green=Rec-Link,  Amber=RX-DATA, RED=Jabber

    o POL             Green=Normal,Amber=Reversed,RED=NO-LINK/CAN'T TELL
                                             This ^^^ could flash RED too!
    o PWR/SQE         Green=POWER,Amber=POWER+SQE


    RED lights should always denote a problem.  GREEN should always
    mean something is GOOD.  Flashing/Pulsing Orange should denote an
    act or state.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 92 19:37:20 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Looking for info on Multicast.

Does anyone know where any information on (proposed) implementations
for multicast IP can be found ?  And are any vendors in the process
of implenting such ?  As far as I know, multicast IP still remains
shrouded in grey on shelves.

Darren

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 92 20:38:32 GMT
From:      hgschulz@gaia.cs.umass.edu (Henning Schulzrinne)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for info on Multicast.

In article <avalon.711488240@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes:
>Does anyone know where any information on (proposed) implementations
>for multicast IP can be found ?  And are any vendors in the process
>of implenting such ?  As far as I know, multicast IP still remains
>shrouded in grey on shelves.
>
>Darren
Multicast IP comes with Silicon Graphics IRIX. Kernel implementations for
Sun OS 4.1.x, BSD 4.3 and Ultrix are available from
gregorio.stanford.edu, directory vmtp-ip.

Multicast IP was used just this past week to multicast audio and slow-scan
video of working group and plenary sessions of the Boston IETF to
roughly 200 sites located in four continents.

Multicast is implemented in OSPF-capable routers. As far as I know,
Proteon is shipping the appropriate software.

Thus, multicast is very much alive. Your regional network provider
should know about it.
---
Henning Schulzrinne  (hgschulz@cs.umass.edu)  [MIME mail welcome]
Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jul 1992 23:55:31 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: CLARIFICATION: NCSA Telnet problems

In article <1992Jul17.170955.17295@ccu.umanitoba.ca>, umrice02@ccu.umanitoba.ca
 (Stephen Rice) wrote:
>The problem is that I set up the PC in server mode (*) with NCSA Telnet for
>the PC.  I find that I can ftp to that machine but I cannot Telnet to the
>machine ("Request for invalid port..." etc.).  My question is: Is it possible
>to setup Telnet for the PC to do this or am I doing something wrong?

NCSA Telnet doesn't have incoming Telnet support.

However, the Waterloo TCP stand-alone Telnet server for PC is available
for anonymous FTP at sunee.uwaterloo.ca:pub/wattcp/telnetd.zip .

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Jul 92 15:35:47 GMT
From:      baw@terminator.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip,comp.dcom.lans,alt.internet
Subject:   Experiences with ANS or PSInet for Internet access


I am trying to help another organization connect up to Internet with
56kbps access and they currently have proposals from ANS and PSInet. The
services are somewhat apples to apples on paper, what I'd like to hear
is feedback from subscribers of ANS and PSInet on their level of satisfaction 
with these services.

The things I'm interested in are

	1)	Quality of Support and timeliness of response
	2)	Network performance, throughput to other regional netorks
	3)	Quality and accessibility of dialup service for remote staff


Please respond via email to bwolfe@rad.rpslmc.edu and I will summarize if 
there is sufficient interest.


Thanks in advance,

Brian


--
Brian Wolfe                    
Associate Director             Internet: bwolfe@rad.rpslmc.edu
Diagnostic Radiology 
Rush Medical Center            Voice:    (312)-942-5781

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 92 17:21:13 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.sources.wanted,comp.protocols.tcp-ip,alt.sys.sun
Subject:   PPP for SunOS wanted

Does anyone know where I can find sources for PPP for SunOS?  We
have a Sparc II and a 670/MP that need to talk PPP (not to each 
other), and are not in a position to slap a router into each site.
Any pointers gratefully accepted.
 
 ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
 Paul Nash                                         paul@frcs.Alt.ZA
 Box 12475, Onderstepoort, 0110 South Africa         +27-12-8413050

   Ex Africa semper aliquid novi                Pliny the Elder
   There is no new thing under the sun          Ecclesiastes

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 01:18:00 GMT
From:      mhw@warlord.UUCP (Michael H. Warfield)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet,comp.sources.wanted
Subject:   Re: Help wanted: Interlan Ethernet drivers

In <1992Jul17.180609.11685@bostech.com> weare@bostech.com (Ged Weare) writes:

>Hi:
 
>I just acquired two Interlan NP600A Ethernet cards real cheap, and am
>trying to find drivers for DOS and AT&T Sys V/386 R3.2 (preferably STREAMS).

	I've got a pile of them.  Lotsa luck!  I'm not going to be much
help.  I've got a little info and more requests.

>1.	anyone have a NP600A packet driver I can use w/o the Novell
>	utilities?
>2.	Are the Novel utilities PD, and if so how do I get them?
>3.	How do I use the NDIS and/or ODI drivers with the PD TCP/IP
>	stuff, such as ka9q, NCSA Telnet, and so on?

	You need some stubs that should have come with the Clarkson
package.  There should be and NDIS stub for PDS in there somewhere.

>I don't have any Novell or other commercial network SW, and don't want to
>buy them (these are for private use, so no funds available).

	Hmm...  Same here.  It's a catch 22.  I got the boards basically
because they were excess and useless for a commercial application (read
that as "Your software is way overpriced!!!!").  I have the klunky DOS
package but I need drivers for SCO UNIX.  All personal stuff.  Nobody
in there right commercial minds will touch the things because they can
get better boards and MUCH better software for less than the price of
the drivers for the board!

>Unix:
>Interlan has a complete TCP/IP package for Sys V, but they sell it for
>$1090, and it includes the NP600A itself.  This is way outside my budget,
>and I already have the cards anyway.  I can do it a lot cheaper by
>junking the NP600As, and buying something mainstream like 3C503's.

	I got refered to NCM (I don't remember what that stands for).  They
seem to be supplying the software for the boards.  They can quote you
separate software packages for a lot of configurations, including upgrades.
HOWEVER....  The individual I talk to didn't seem real enthusiastic.  I
got the feeling he was being put out to even be discussing the subject with
some lowly individual.  They also want around $500 just for the SCO drivers.
Needless to say, there are better routes to go than that.  I don't know
if they have anything for the ATT stuff but their number is 1-800-786-3696.
As I say - their rep had a real attitude and their pricing sucks so lots'a
luck.

	I do a lot of consulting as well as my normal job as an Engineering
VP for an outfit down here in Georgia.  My recommendation to anyone, after
that encounter with NCM, is to avoid Interlan products like the plague!
If that's their attitude to a consultant who can recommend for or against
their products, heaven help the poor user who is stuck with them!

>Again, I don't want to spend money; I can always buy a cheap supported
>controller at low cost and junk the NP600As.

	Yea, my dozen or so are now collecting dust.  And Interlan has
already lost several sales as a direct result!  Anyone asking or consulting
me will get told that the software was so expensive I could not justify
even evaluating the boards.  And I certainly would never recommend something
that I couldn't even evaluate!

	Michael H. Warfield
	mhw@warlord.uucp

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 04:48:12 GMT
From:      reid@pa.dec.com (Brian Reid)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: SLIP over a TELNET Link?

In article <1992Jun27.042050.4180@qualcomm.com> karn@chicago.qualcomm.com writes:
>Ahem. Anyway... my idea was to encode IP datagrams as lines of
>printable ASCII characters, one packet per line. Something like
>uuencode or binhex encoding would work. You'd probably have to limit
>your MTUs to whatever will fit in the line buffers along the way.

I figured the right thing to do was to layer IP datagrams on top of Kermit.
Kermit runs absolutely everywhere, over anything, and if you can get IP
running on top of that, then you own the world.

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 13:22:19 MDT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: ODI and Clarkson driver spec

In article <1992Jul20.170533.19619@pacdata.uucp>, johnr@pacdata.com (John Reed) writes:
> 
> 
> Would a kind soul point me in the right location to find the
> ODI (Open Data-link Interface) specification and the
> Clarkson Packet Driver specification.
----------
	I commented to John privately on this, but here's a public pointer.
The ODI specs are currently five Postscript files
	ODI_DOS.ZIP, ODI_OS2.ZIP, ODI_SRV.ZIP	board level specs
	PSTACK_D.ZIP, PSTACK_S.ZIP 	DOS and Server applications level specs
These are all large Postscript files. The OS/2 app layer document is at the
OS/2 v1.3 level at the moment, and Novell indicates it is being updated. The 
prime site for them is sjf-lwp.novell.com. 
	Copies are also on NW 3.11 server netlab2.usu.edu, cd misc. Also in 
that directory are files ODIREAD.ME and MSNPDI.ASM which demonstrates working 
code to use ODI and Packet Drivers in an application (MS-DOS Kermit v3.12 beta).
        Joe D.

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 13:43:27 MDT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over a TELNET Link?

In article <auy1H==nk8@atlantis.psu.edu>, barr@darwin.psu.edu (David Barr) writes:
> In article <1992Jul20.044812.5525@PA.dec.com> reid@pa.dec.com (Brian Reid) writes:
>>In article <1992Jun27.042050.4180@qualcomm.com> karn@chicago.qualcomm.com writes:
>>>Ahem. Anyway... my idea was to encode IP datagrams as lines of
>>>printable ASCII characters, one packet per line. Something like
>>>uuencode or binhex encoding would work. You'd probably have to limit
>>>your MTUs to whatever will fit in the line buffers along the way.
>>
>>I figured the right thing to do was to layer IP datagrams on top of Kermit.
>>Kermit runs absolutely everywhere, over anything, and if you can get IP
>>running on top of that, then you own the world.
> 
> Yeah, but V E R Y  S L O W L Y.
> 
> And I thought it was sick when the College of Engineering decided to use
> DECNET to encapsulate IP packets so they could have one virtual ethernet
> spanning buildings.  (It was apparently the only solution.  I still can't
> believe it)
> 
> --Dave
> -- 
> System Administrator, Population Research Institute    barr@darwin.psu.edu
>   Contains: Carbonated water, high fructose corn syrup and/or sugar, caramel 
>   color, phosphoric acid, caffeine, citric acid and natural flavorings.
----------------
	Ok, everyone has had some fun knocking their favorite protocols. But
if you are into the protocol business then some common sense should prevail.
In this case slowness depends on two things: the line capacity and the 
implementation of the protocols at each end. If one is going to do SLIP then
we are discussing serial lines, and that will be slow regardless. The Kermit
protocol is not slow, but you can configure just about anything to be slower
than normal. For discusssion purposes, putting Kermit packets on a Telnet
stream (the opposite of the thread) I get a long term throughput of about
15K file chars/sec, say around 160K "baud", from a PC to C Kermit on a Unix
machine. This is faster than any serial link from PCs so the protocol and
the implemenation code are plenty fast enough to loaf when using any serial
port.
	A point worth paying attention to in the tunneling thread is finding
suitable widely used transport protocols to act as the carriers. The Kermit
protocol has advantages of working with either 7 or 8 bit channels while
providing a 8-bit clean virtual channel, it has sliding windows for good
long distance work, and it's naturally robust in the face of errors. Taking
things a step further, it also handles transportation of text in different
character sets (something folks in the US tend to ignore, but the rest of
the world does not). I'm not advocating Kermit protocol here, but rather
pointing out some characteristics which I think a general transporter ought
to have.
	As Brian Reid pointed out, the Kermit protocol is implemented on
almost every machine in existance so at least you know the other end can
talk with you no matter what. So I guess that means the two most widely
used protocols are IP and Kermit when we count machines.
	Joe D.

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 13:54:22 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for info on Multicast.

In article <50589@dime.cs.umass.edu> hgschulz@gaia.cs.umass.edu (Henning Schulzrinne) writes:
>   Multicast IP comes with Silicon Graphics IRIX. 

Solaris 2.0 has multicast also, I hear. I assume it's similar to 
the gregorio.stanford.edu work.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 1992 15:11:14 GMT
From:      redmill@ee.eng.ohio-state.edu (Keith A. Redmill)
To:        comp.protocols.tcp-ip
Subject:   Decnet Packets over Sun Router ??

I have a Sun 4 (IPC) with two ethernet cards running as a router for
a small subnet.  I would like to install some vax stations under this
subnet but Decnet packets don't seem to make it through the sun routed
software.  

Can this be done??

--------------------------------------------------------------
redmill@ee.eng.ohio-state.edu
-- 
Keith A. Redmill     (redmill@ee.eng.ohio-state.edu)
    The opinions expressed above are well reasoned and insightful.  Needless to
    say, they are not those of OSU, its faculty, or lackeys.  Anyone who says
    otherwise is itching for a fight.  -- Whad'ya Know? 

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 1992 15:15:20 GMT
From:      hoang1@litwin.com (Ted Hoang)
To:        comp.protocols.tcp-ip
Subject:   IP address to Ether addr

Hi,
I would like to know any C function I can use to find out Ether. address
if I have the IP address.
Ex:
  I use socket() and bind() the IP address.
	Can I use ioctl() to find the Ether address?
	Any examples?

Thank in advance
Ted Hoang
Email:hoang1@dynsim1.litwin.com


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 15:41:58 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??

In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu> redmill@ee.eng.ohio-state.edu (Keith A. Redmill) writes:
>I have a Sun 4 (IPC) with two ethernet cards running as a router for
>a small subnet.  I would like to install some vax stations under this
>subnet but Decnet packets don't seem to make it through the sun routed
>software.  
>
>Can this be done??

The routing in the SunOs kernel and the functions of routed, are only
for performing IP forwarding.  I assume you meant Phase IV when you
mentioned Decnet.  If so, you might try Ki Research, Inc for Decnet
Phase IV software that runs on Suns (and also does routing, I believe).

If you are eventually going to need to route more protocols or deal
with unroutable protocols (such as LAT), you might want to consider
a dedicated Bridge/Router.
 
Art

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 92 16:59:38 GMT
From:      barr@darwin.psu.edu (David Barr)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <1992Jul20.044812.5525@PA.dec.com> reid@pa.dec.com (Brian Reid) writes:
>In article <1992Jun27.042050.4180@qualcomm.com> karn@chicago.qualcomm.com writes:
>>Ahem. Anyway... my idea was to encode IP datagrams as lines of
>>printable ASCII characters, one packet per line. Something like
>>uuencode or binhex encoding would work. You'd probably have to limit
>>your MTUs to whatever will fit in the line buffers along the way.
>
>I figured the right thing to do was to layer IP datagrams on top of Kermit.
>Kermit runs absolutely everywhere, over anything, and if you can get IP
>running on top of that, then you own the world.

Yeah, but V E R Y  S L O W L Y.

And I thought it was sick when the College of Engineering decided to use
DECNET to encapsulate IP packets so they could have one virtual ethernet
spanning buildings.  (It was apparently the only solution.  I still can't
believe it)

--Dave
-- 
System Administrator, Population Research Institute    barr@darwin.psu.edu
  Contains: Carbonated water, high fructose corn syrup and/or sugar, caramel 
  color, phosphoric acid, caffeine, citric acid and natural flavorings.

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 1992 17:05:33 GMT
From:      johnr@pacdata.com (John Reed)
To:        comp.protocols.tcp-ip
Subject:   ODI and Clarkson driver spec



Would a kind soul point me in the right location to find the
ODI (Open Data-link Interface) specification and the
Clarkson Packet Driver specification.

Thank you!

JR





-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr%pacdata.uucp@ucsd.edu   |
  |                    ---------------------                           |
  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
  |                                                                    |
  |                 Huge Berserk Rebel Warthog                         |
  |                                     -- From Cosmic Trigger II      |
   \------------------------------------------------------------------/

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 17:45:18 GMT
From:      bob@comlab.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip
Subject:   Re: ODI and Clarkson driver spec

In article johnr@pacdata.com (John Reed) writes:
>Would a kind soul point me in the right location to find the
>ODI (Open Data-link Interface) specification and the
>Clarkson Packet Driver specification.

I know you didn't ask for it but if you have any interest, the NDIS driver
spec can be found a couple of places also.  It is also another major
network driver spec in the PC world.  I keep a copy of the NDIS 2.0.1 spec
in Rich Text Format on "comlab.gatech.edu" in the "/pub/lanman/ndis"
directory. 

Bob
--
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 18:10:16 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

David> == David Barr <barr@darwin.psu.edu> 

 David> And I thought it was sick when the College of Engineering
 David> decided to use DECNET to encapsulate IP packets so they could
 David> have one virtual ethernet spanning buildings.  (It was
 David> apparently the only solution.  I still can't believe it)

Sickest of all was the "proposal" to put IP packets in MIME-format
multimedia messages.  That gives you IP over UUCP, even over a
multiple-hop UUCP path.

(You definitely have to tweak the retransmit timers though :-)
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
   ``The First Amendment is often inconvenient.  But that is besides the
  point.  Inconvenience does not absolve the government of its obligation
         to tolerate speech.'' --Justice Anthony Kennedy, in 91-155

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 92 19:37:52 GMT
From:      andr@elvis.msk.su (Andrei Arkhipov)
To:        comp.protocols.tcp-ip
Subject:   SLIP connection between Sun and PC/ICS Unix

Hi.

Did anybody do SLIP connection between Sun SPARCstation under SunOS 4.1.1 and
PC under ISC?

What I need to know is what software I need on both sides, installation and 
connection procedure (maybe some special points only).

Thank you in advance,
             Andrei.

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 92 20:11:44 GMT
From:      piet@cwi.nl (Piet Beertema)
To:        de.comm.internet,comp.protocols.tcp-ip,eunet.misc
Subject:   Re: Unique internet IP adr. without changing local IPs ?


	In our company we have decided to connect to the world wide
	internet.  Therefore I think we have to apply for a world
	wide unique IP address.
Quite right, otherwise you won't even get Internet access,
within or outside Europe.

	My problem is, if we get this IP address we don't want to
	change all our local IP addresses we are using now.
You have no other choice.

	But if we don't act this way then we have local IP addresses
	which are matching IP addresses on the internet.
That's why. You wouldn't be able to reach those external IP
addresses; and if you would manage to announce your internal
self-chosen IP addresses to the outside world, you would be
cut off by your network service provider the next minute.

	I think this problem should has been appeared before.
It sure did:
	I don't want to change 500 nodes.?
CERN had exactly the same problem a few years ago; they had
to change -and changed- the IP addresses of 2000+ hosts...


-- 
	---
	Piet Beertema, CWI, Amsterdam, Netherlands
	Internet: Piet.Beertema@cwi.nl
	X.400: G=Piet;S=Beertema;O=cwi;P=surf;A=400net;C=nl

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 1992 22:06:27 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   "large-MTU" tcp-ip questions


	I would like to know if anyone has heard of any work toward
modification/alteration of tcp-ip to handle very large MTU's (i.e. >64K)

	I know about the window scale work done for "big" tcp-ip.  One 
thing I'm looking for is probably existing or proposed options to extend
the size of various protocol header fields.

	I'm interested to know if there is any existing work or draft
work or even rumors of what is going on in this area. 

Thanks.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 92 00:10:10 GMT
From:      barr@darwin.psu.edu (David Barr)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <CKD.92Jul20140814@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>David> == David Barr <barr@darwin.psu.edu> 
>
> David> And I thought it was sick when the College of Engineering
> David> decided to use DECNET to encapsulate IP packets so they could
> David> have one virtual ethernet spanning buildings.  (It was
> David> apparently the only solution.  I still can't believe it)

I got the above story wrong.  They are encapsulating _ethernet_ packets
over DECNET in order to get one big "virtual ethernet".

>Sickest of all was the "proposal" to put IP packets in MIME-format
>multimedia messages.  That gives you IP over UUCP, even over a
>multiple-hop UUCP path.

rmail: No carrier - transceiver cable problem?

--Dave
-- 
System Administrator, Population Research Institute    barr@darwin.psu.edu
Emacs is a fine operating system, but I still prefer UNIX. - Tom Christiansen

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 21 Jul 1992 09:03:43 MST
From:      Shahjehan Khatri <IDSAK@ASUACAD.BITNET>
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Intermittent "Host Unknown" problem

We're getting problems such as the following, intermittently:

VTVM1.CC.VT.EDU unable to deliver following mail to recipient(s):
    <USER@ospnov.vprc.asu.edu>
550 Host 'ospnov.vprc.asu.edu' Unknown

I found out the following by using Multinet NSLookup on one of our VAXes:

> ospnov.vprc.asu.edu
Server: dcssvx.cc.vt.edu
Address:  128.173.4.247

Non-authoritative answer:
ospnov.vprc.asu.edu     preference = 10, mail exchanger = cncsnov.INRE.ASU.EDU

Authoritative answers can be found from:
ASU.edu nameserver = ASUVAX.EAS.ASU.EDU
ASU.edu nameserver = CCNUCB.COLORADO.EDU
cncsnov.INRE.ASU.EDU    internet address = 129.219.9.85
ASUVAX.EAS.ASU.EDU      internet address = 129.219.30.5
CCNUCB.COLORADO.EDU     internet address = 128.138.238.34

However, yesterday morning this server was saying that it couldn't find
ospnov, but it found facmgt.inre.asu.edu alright.  The later domain is an
identical entry in the asuvax server, as shown below:

> server asuvax
Default Server:  asuvax.ASU.EDU
Address:  129.219.30.5

> ospnov.vprc.asu.edu
Server:  asuvax.ASU.EDU
Address:  129.219.30.5

ospnov.vprc.asu.edu     preference = 10, mail exchanger = cncsnov.INRE.ASU.EDU
cncsnov.INRE.ASU.EDU    internet address = 129.219.9.85
> facmgt.inre.asu.edu
Server:  asuvax.ASU.EDU
Address:  129.219.30.5

facmgt.inre.asu.edu     preference = 10, mail exchanger = cncsnov.INRE.ASU.EDU
cncsnov.INRE.ASU.EDU    internet address = 129.219.9.85

Please note that dcssvx.cc.vt.edu is not the only server that can't find
ospnov. every now and then.  Yuma.acns.colostate.edu, for instance, has run
into the same difficulty.  Actually, sometimes dcssvx. can find ospnov. but
yuma. cannot.

Any replies will be greatly appreciated.

Khatri@PCMAIL.INRE.ASU.EDU
IDSAK@ASUACAD


-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 02:30:48 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

David> == David Barr <barr@darwin.psu.edu> 

 ckd> Sickest of all was the "proposal" to put IP packets in MIME-format
 ckd> multimedia messages.  That gives you IP over UUCP, even over a
 ckd> multiple-hop UUCP path.

 David> rmail: No carrier - transceiver cable problem?

Yeah, well, you should have seen the broadcast storm that happened when
somebody arped the sf-lovers mailing list :-)
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
   ``The First Amendment is often inconvenient.  But that is besides the
  point.  Inconvenience does not absolve the government of its obligation
         to tolerate speech.'' --Justice Anthony Kennedy, in 91-155

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 07:36:28
From:      cws@vax.ftp.com  (Cris Shuldiner)
To:        comp.protocols.tcp-ip
Subject:   Re: ODI and Clarkson driver spec

In article <1992Jul20.170533.19619@pacdata.uucp> johnr@pacdata.com (John Reed) writes:

    
    
    Would a kind soul point me in the right location to find the
    ODI (Open Data-link Interface) specification and the
    Clarkson Packet Driver specification.
    
Actually it is the FTP Packet Driver Specification and it can be
found on vax.ftp.com in the pub directory.  There are three copies
there:  packet-d.ascii (plain text), packet-d.mss (FinalWord Format),
and packet-d.prn (HP-GL Format).

				Cris.



-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 03:54:20 GMT
From:      kent@exodus.reuters.com.sg (kent)
To:        comp.protocols.tcp-ip
Subject:   ISDN Driver

I am looking for an ISDN driver for TCP/ip on either BSD r System V
Unix. If that is not available, an X.25 driver will do. Even some
documentation tht explain how to interface IP to X.25 ( particularty on
the address translation part) will be helpful. I need something more
detail than RFC 877.


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 11:27:12 GMT
From:      jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
To:        comp.protocols.tcp-ip
Subject:   Help?


I am trying to write what amounts to a really simple telnet (in C) and
cannot seem to get it working.  I have some old rlogin code I found
and some code in another language that does exactly what I want.
Unfortunately I have to do it in C.  I know it is really easy and that
is why I am frustrated.

Here's what I have: Following the Sun doc (net programming guide page
265) 

- get a socket, 
{- bind the socket using INADDR_ANY and port 0}
- setup an address structure with port 23 and the host's info from
	gethostbyname.
- call connect using the above mentioned address structure.

So far so good.  Note that as per the example I did not bind since
that will be done for me by the local machine?  I put the {} there
because I tried this with that step in and it made no difference.

So now that I have a connection?  (it didn't complain), I fork a
reader and writer task.  The writer repsonds to my key presses and
claims to have written successfully.  The reader ALWAYS immediately
reports 3 characters whose values when printed at integers are -1, -3
and 24.  That is all I ever hear from the reader.  I would have
expected that the getty on the receiving end would say something.  Are
these chars some sort of handshake that I have to respond to?  What is
the response?

All I want to do is pass, *completely* unprocessed characters from
standard in to the socket stream and from the socket stream to stdout.
I would really appreciate any help or code :-) you can give me.

Thanks for reading this.

--
ja mata, |m       -- Silence and stillness were everywhere except his head.
                     Sweat dripped and "I'd rather be drinking a beer",
                     roared as he contemplated the remaining threads.      #2

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 12:55:02 GMT
From:      mark@homebase.vistachrome.com (Mark Alexander)
To:        comp.protocols.tcp-ip
Subject:   ftp network programming

I am trying to learn how to write a C program which uses the 
socket library to connect to a remote ftp server and negotiate
file transfers.  I am having a bit of a hard time although I
believe I understand a good deal of what needs to be done.

If someone could direct me to a good beginner's book or to some
code which is easy to follow I would appreciate it.  I have the
source to ftp, and rfc959 for ftp, but there's too much I dont
know about the basics. 
-- 

-----------------------------------------------------------------------
      Mark Alexander      alexand@nu.cs.fsu.edu    mark@vistachrome.com
                          Florida State Univ.      Vista-Chrome, Inc.
                          Tallahassee, FL          Tallahassee, FL 
-----------------------------------------------------------------------

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 92 15:04:18 GMT
From:      andr@elvis.msk.su (Andrei Arkhipov)
To:        comp.protocols.tcp-ip
Subject:   SLIP connection between Sun and PC/ICS Unix

Hi.
 
Did anybody do SLIP connection between Sun SPARCstation under SunOS 4.1.1 and
PC under ISC?
 
What I need to know is what software I need on both sides, installation and 
connection procedure (maybe some special points only).
 
Thank you in advance,
              Andrei.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 92 16:16:21 GMT
From:      GJAMES@HUSKY1.STMARYS.CA (GJames)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP info wanted

I am lookin for any public domain guides to TCP/IP, IPX, internet protocols.
Is there anything available by FTP

Thanks

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 92 17:30:59 GMT
From:      bill@prijat.cs.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??

In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A. Redmill) writes:
|> I have a Sun 4 (IPC) with two ethernet cards running as a router for
|> a small subnet.  I would like to install some vax stations under this
|> subnet but Decnet packets don't seem to make it through the sun routed
|> software.  
|> 
|> Can this be done??

NO.

You need to go back and read up some more on DECNET.  
It is definitely not TCPIP.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 17:35:20 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Intermittent "Host Unknown" problem

In article <92203.090343IDSAK@ASUACAD.BITNET> Shahjehan Khatri <IDSAK@ASUACAD.BITNET> writes:
>We're getting problems such as the following, intermittently:
>
>VTVM1.CC.VT.EDU unable to deliver following mail to recipient(s):
>    <USER@ospnov.vprc.asu.edu>
>550 Host 'ospnov.vprc.asu.edu' Unknown

  According to NS.NIC.DDN.MIL there are two nameservers for your
domain:


;; ANSWERS:
asu.edu.	172800	NS	ASUVAX.EAS.ASU.EDU.
asu.edu.	172800	NS	CCNUCB.COLORADO.EDU.

 Your problems are due to a gross inconsistency between the records being
reported by CCNUCB.COLORADO.EDU and ASUVAX.EAS.ASU.EDU.  Any nameserver
attempting to resolve an address such as:
	ospnov.vprc.asu.edu
could contact either of these servers.

 The inconsistency could be caused by broken software.  However the most
likely explanation is a failure to always increment the SOA serial
number whenever there is any change in data.  Your secondary server at
CCNUCB examines the SOA serial number.  If it is unchanged, it presumes
that the data is unchanged, and does not make a new copy of your
data.


-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 92 17:54:21 GMT
From:      danson@lgc.com (Doug Anson)
To:        comp.protocols.tcp-ip
Subject:   RPC daemons using TCP

Hi:

Does anyone know of any sources for examples of RPC based daemons
that use TCP transports and are fired off by inetd?  I am trying to
develop a daemon that will be fired off by inetd and will satisfy
RPC requests using the TCP transport. TCP is a requirement in this 
particular case. 

Anyway, I have read the man pages on using rpcgen to create the appropriate
stubs for use with inetd. However, these stubs apparently only work when I
use UDP for the transport (surely I'm missing some point here..)

I would appreciate any help, direction, comments you might have.

Thanks,
Doug

-- 
-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713-579-4739
SNAIL:    Landmark Graphics Corporation LGC	
	  333 Cypress Run			
	  Houston, TX 77094			
-------------------------------------------

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 1992 18:11:38 GMT
From:      nectar@world.std.com (Jacques A Vidrine)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Token Ring and FDDI on same ring?

Simple question, but I don't expect a simple answer.

Can FDDI and Token Ring be run on the same ring?

My organization has in place a 16Mbps Token Ring network using the
IBM Cabling System with optical fiber.  It is our goal to move to
FDDI in the future.  Thus the question.


-- 
Jacques A. Vidrine 		|	What did the Zen Buddhist	
nectar@world.std.com		|	say to the hot dog vendor?
				|	"Make me one with everything."
Request my PGP public key	|

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 92 18:46:39 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp network programming

mark@homebase.vistachrome.com (Mark Alexander) writes:
: I am trying to learn how to write a C program which uses the 
: socket library to connect to a remote ftp server and negotiate
: file transfers.  I am having a bit of a hard time although I
: believe I understand a good deal of what needs to be done.

look at
- "ftpget", from ftp.uunet.ca
- "mirror", from a number of sites including
	ftp.uu.net:networking/archival/mirror

the first is in C, the 2d is in perl, both of them speak FTP and
deal with file transfers.

you might also take a peek at 
	alex.sp.cs.cmu.edu:/
and take a look at Vince Cate's "alex" system, which builds a file
system on top of FTP servers.

	--Ed

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1992 00:43:23 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Help?

In article <1992Jul21.112712.12158@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:
>So now that I have a connection?  (it didn't complain), I fork a
>reader and writer task.  The writer repsonds to my key presses and
>claims to have written successfully.  The reader ALWAYS immediately
>reports 3 characters whose values when printed at integers are -1, -3
>and 24.  That is all I ever hear from the reader.  I would have
>expected that the getty on the receiving end would say something.  Are
>these chars some sort of handshake that I have to respond to?  What is
>the response?

That's an IAC sequence.  These are sent by TELNET implementations to
implement control operations in the protocol and negotiate options.  That
specific sequence is IAC DO TERMINAL-TYPE, i.e. a request for the client to
send the user's terminal type.  If you don't want to send the terminal
type, you should respond IAC WONT TERMINAL-TYPE.

See the specification of the TELNET protocol in RFC 854.  You should
probably use unsigned characters, so that the values will match the
character codes used in the specification (e.g. it describes that sequence
as 255 253 24).

>All I want to do is pass, *completely* unprocessed characters from
>standard in to the socket stream and from the socket stream to stdout.
>I would really appreciate any help or code :-) you can give me.

If you're going to talk to a TELNET server, you have to talk its language.
And that requires recognizing and acting on control operations in the
protocol.  TELNET isn't just a simple pass-through protocol, it's a virtual
terminal protocol with great flexibility.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jul 92 02:21:02 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   ODI and Clarkson driver spec

In article <1992Jul20.170533.19619@pacdata.uucp> johnr@pacdata.com writes:

   Would a kind soul point me in the right location to find the
   ODI (Open Data-link Interface) specification and the
   Clarkson Packet Driver specification.

Actually, the spec belongs to FTP Software.  It's on vax.ftp.com, in
pub/packet-d.ascii.

The largest (only?) collection of packet drivers used to be
maintained by myself while I was employed by Clarkson University.
Crynwr Software now owns the copyright on the packet driver skeleton.
The software remains freely copyable.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice   [ if mail bounces, forward it ]
Potsdam, NY 13676          315-268-9201 FAX     [ to uuadmin@uu.psi.com.      ]

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 03:10:48 GMT
From:      mandell@bach.helios.nd.edu (Dan Mandell)
To:        comp.protocols.tcp-ip
Subject:   FTP's Kernel and Ipx/Netx compatibility

We currently use Hummingbird's Exceed Xwindows product with FTP's TCP/IP
ethdrv kernal running on top of the wd8003e packet drivers. Works great.
Except, that I don't seem to be able to run ipx/netx while FTP's ethdrv 
kernel is loaded.  I have been asked if it is possible to do this - and 
seem to recall being told by FTP tech support that it can't be done.  But 
I thought one of the motivations for the packetdrivers was to allow several 
protocoll stacks to use the same ethernet card (Western Digital) -
simultaneously, if need be.  Is there something we could do to make this work?
Is theresomething that would replace the packetdriver that would support 
a connection to both a unix host and a novell server at the same time.
Is anybody doing this?
 
Dan Mandell

Dan Mandell (mandell@saintmarys.edu)
Saint Mary's College, Computer Services 
Notre Dame, Indiana 46556  -  Phone: (219) 284-4610

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 03:23:56 GMT
From:      timb@ksgbbs.harvard.edu (Tim Buehrer - 625-6829)
To:        comp.protocols.tcp-ip
Subject:   Problems with c-kermit telnet, right place to post?


I hope that this is a good place to post this question.  If it is not, I would
appreciate suggestions on where it should go.

We are setting up a system to communicate between our SCO XENIX box and a PC
using c-kermit on the PC and the WATTCP telnetd on the PC.  Most parts are
working fine, but there is one fundamental problem.  c-kermit insists on send-
ing a return-linefeed combination when I type a return, even if the terminal
setting for return-linefeed is off.  (When I just use the telnet that came
from SCO, I don't have this problem.)  Is there a way to configure c-kermit to
avoid this problem?  I've tried using set key but that doesn't seem to help.

Tim Buehrer
timb@ksgbbs.harvard.edu

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 03:43:20 GMT
From:      markb@spock.dis.cccd.edu (Mark Bixby)
To:        comp.protocols.tcp-ip
Subject:   ping works, but ftp/telnet get "no route to host"

Why would I be able to ping a site OK, but when I try to ftp or telnet to it
I receive a "no route to host" error?  Traceroute can find the host, and it
is apparently on Alternet, if that makes a difference.

Any info would be most helpful to this tcp/ip novice.  Thanks.

-- 
Mark Bixby                         Internet: markb@spock.dis.cccd.edu
Coast Community College District   1370 Adams Avenue
District Information Services      Costa Mesa, CA, USA  92626
Technical Support                  (714) 432-5064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 10:13:16 MDT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with c-kermit telnet, right place to post?

In article <1992Jul22.032356.9842@ksgbbs.harvard.edu>, timb@ksgbbs.harvard.edu (Tim Buehrer - 625-6829) writes:
> 
> I hope that this is a good place to post this question.  If it is not, I would
> appreciate suggestions on where it should go.
> 
> We are setting up a system to communicate between our SCO XENIX box and a PC
> using c-kermit on the PC and the WATTCP telnetd on the PC.  Most parts are
> working fine, but there is one fundamental problem.  c-kermit insists on send-
> ing a return-linefeed combination when I type a return, even if the terminal
> setting for return-linefeed is off.  (When I just use the telnet that came
> from SCO, I don't have this problem.)  Is there a way to configure c-kermit to
> avoid this problem?  I've tried using set key but that doesn't seem to help.
> 
> Tim Buehrer
> timb@ksgbbs.harvard.edu
----------
Tim,
	Version numbers?
	My quick guess is the WATTCP stuff is not doing NETASCII properly.
CR-LF is the line terminator signal on the wire, and gets converted at each
end to suit the local system. Instead of WATTCP get MS-DOS Kermit 3.12 beta
and use that on the PC. C Kermit and MSK work properly for the CR-LF stuff.
	Further questions on the Kermit parts would get quicker attention if
sent to me, jrd@cc.usu.edu, for MS-DOS Kermit and to Frank da Cruz,
fdc@watsun.cc.columbia.edu, for C Kermit.
	Joe D.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 07:10:03 GMT
From:      zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
To:        comp.protocols.tcp-ip
Subject:   Re: CLARIFICATION: NCSA Telnet problems

In article <1992Jul17.170955.17295@ccu.umanitoba.ca>, umrice02@ccu.umanitoba.ca
(Stephen Rice) writes:
|> I recently posted a message regarding a problem I am having with telnet'ing 
|> into a PC this message is meant to define the problem a little clearer:
|> 
|> The problem is that I set up the PC in server mode (*) with NCSA Telnet for
|> the PC.  I find that I can ftp to that machine but I cannot Telnet to the
|> machine ("Request for invalid port..." etc.).  My question is: Is it
|> possible
|> to setup Telnet for the PC to do this or am I doing something wrong?

You can only use ftp with NCSA telnet in server mode - you cannot telnet to
the PC.
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jul 1992 11:11:25 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP's Kernel and Ipx/Netx compatibility

In article <1992Jul22.031048.27400@news.nd.edu> mandell@bach.helios.nd.edu (Dan Mandell) writes:
>We currently use Hummingbird's Exceed Xwindows product with FTP's TCP/IP
>ethdrv kernal running on top of the wd8003e packet drivers. Works great.
>Except, that I don't seem to be able to run ipx/netx while FTP's ethdrv 
>kernel is loaded.  I have been asked if it is possible to do this - and 
>seem to recall being told by FTP tech support that it can't be done.  But 
>I thought one of the motivations for the packetdrivers was to allow several 
>protocoll stacks to use the same ethernet card (Western Digital) -
>simultaneously, if need be.  Is there something we could do to make this work?
>Is theresomething that would replace the packetdriver that would support 
>a connection to both a unix host and a novell server at the same time.
>Is anybody doing this?

I'm doing this right now! What you need is an IPX that is linked with a
packet driver interface. If you use an IPX linked with a WD8003e driver,
you have two programs that try to control the NIC simultaneously. Needless
to say that this is a safe way to create disaster. Get yourself the archive
NOVELL.EXE (available from omnigate.clarkson.edu) and follow the
instructions to create a new IPX. It works just fine for me.

Regards,
-Roger
(I speak for myself)

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jul 1992 13:41:35 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: ping works, but ftp/telnet get "no route to host"

In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>I receive a "no route to host" error?  Traceroute can find the host, and it
>is apparently on Alternet, if that makes a difference.
>
>Any info would be most helpful to this tcp/ip novice.  Thanks.
>

The site you are trying to ping is running a firewall gateway, because
they're too lazy to beef up their host security and are relying on the
firewall to protect themselves against external attacks. The site
router(s) look inside your packets, and if they are not to/from
specific hosts or ports, they don't forward them, but rather send you
an ICMP host unreachable message back.

I wish I had a transcript of Dave Clark's talk at the IETF last week.
He said some great things about firewall gateways and mailbridges, and
how they've essentially destroyed the whole purpose of having an IP
internet, and have forced a lot of us to use mail as a transport-level
protocol.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jul 1992 16:14:36 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ping works, but ftp/telnet get "no route to host"

In article <BrsM1C.36v@cs.columbia.edu>, ji@cs.columbia.edu (John Ioannidis) writes:
> ....
> The site you are trying to ping is running a firewall gateway, because
> they're too lazy to beef up their host security and are relying on the
> firewall to protect themselves against external attacks....


That you're return address is at a university is somehow unsurprising.


Many of us out here in the commercial world have thousands of machines
on corporate networks with minimum internal, inter-machine security.

Using firewalls allows us to do the jobs we're paid to do without
spending so much time fiddling with "security," whether choosing
passwords, typing them, or using FTP instead of rcp (.rhosts are
unsafe, remember?).  It is true that parts of the commercial world do
not mind wasting high salaries and far greater "lost opportunity
costs" to have all machines on their networks "secure."  As far as I
know, all such commercial organizations are not what anyone would call
nimble or industry leading.  (Yes, before everyone asserts their
Military Industrial employer is different, I'm sure there must be at
least one exception.)

Firewalls are like guards at the front desk instead of patroling the
halls.  Some places have guards in the halls, rules about leaving
papers on your desk, and so forth, but many of us decline to work in
such places.

It is nicest to not have any guards, just as it is nicest to not worry
about locking your door.  Unfortunately, zillions of tiny minds,
frequently jejune university students, have proven that the Internet is
too much like a big city to do without locks.

To have someone at a big city university suggest that we lock our
bedrooms instead of our front doors is either amusing or offensive.


Vernon Schryver,  vjs@sgi.com

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 20:32:00 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??

In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A. Redmill) writes:
|> I have a Sun 4 (IPC) with two ethernet cards running as a router for
|> a small subnet.  I would like to install some vax stations under this
|> subnet but Decnet packets don't seem to make it through the sun routed
|> software.  
|> 
|> Can this be done??
|> 
|> --------------------------------------------------------------
|> redmill@ee.eng.ohio-state.edu
|> -- 
|> Keith A. Redmill     (redmill@ee.eng.ohio-state.edu)
|>     The opinions expressed above are well reasoned and insightful.  Needless to
|>     say, they are not those of OSU, its faculty, or lackeys.  Anyone who says
|>     otherwise is itching for a fight.  -- Whad'ya Know? 

The vaxes are running either Decnet IV or the new OSI based Decnet.
in either case, the Suns won't handle it without some new software.
The Sun handles IP and that is it.  The four solutions are :

1. Upgrade the vaxes to use tcp/ip.
2. Upgrade the Sun to route the correct Decnet.
3. Replace the Sun with either a bridge or router to handle all 
   protocols.
4. Place a bridge or router in parallel with the sun and have it
   handle all non IP traffic.

My personal preference would be 3.  Especially if I could get a low
cost, two ethernet port PC and a copy of the PCBridge software.
Then, for the cost of the PC I get back a Sun.  This would however 
require that the IP hosts on both ethernets be part of the same
(sub)network.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 20:50:51 GMT
From:      peter@nuustak.csir.co.za (Peter Greenwood)
To:        comp.protocols.misc,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   3270 terminal access to a UNIX application

I want to connect a 3270-type terminal to a UNIX computer running an
application that is usually accessed via a VT100-type terminal.  In fact, 
I need to do this for up to 150 simultaneous sessions.

At the moment I'm achieving this by running some software on an MVS 
mainframe which does SNA to TCP/IP conversion.  So an SNA user logs
on to the mainframe, selects the TCP application, and then telnets to
the UNIX host.

In effect, I'm using an expensive mainframe as a protocol convertor.  There
must be a better, cheaper way.  What's the best way of giving an SNA user
access to a UNIX application?  Is it possible to do this without using the
mainframe at all?


Peter Greenwood
CSIR                                peter@dobs.csir.co.za

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 92 21:06:05 GMT
From:      kearns@actcon.canton.oh.us (Steve Kearns)
To:        comp.protocols.tcp-ip
Subject:   rwho core dumping under SCO UNIX

My rwhod process is core dumping on a freshly installed system.  I'm
running SCO UNIX 3.2.4 and TCP/IP 1.1.3f.  TCP/IP is started on boot up;
all of my daemons start up normally.  However, for no apparent reason 
(at least to me), after about 10 minutes, the rwhod core dumps in the
/usr/spool/rwho directory.  This occurs with no TCP/IP traffic whatsoever;
there are no other servers and no workstations active. 

Any ideas?  Thanks for any help.

steve
-- 
Steve Kearns              A.C.T. Consulting, Inc.                  216-455-1444

Internet: kearns@actcon.canton.oh.us                
UUCP    : uunet!aablue!redpoll!mrsmouse!actcon!kearns

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jul 92 14:39:20 +0400
From:      saty@ntc.togliatti.su (Sergey A. TsYbanov)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Clemson University Packet Driver: I have one problem B-(.

Hi !

I write some application ( TSR type ) based on Packet Driver
( Clemson University Engineering Comp Ops Version 9) and I have
one tragic problem. I can not send ethernet packets while
my receive handle works. How can I do it correctly?
My ethernet card is 3C505.
Thanx.

! iH




-- 
 ******************* Is There Anybody Out There ? **********************
 *                   SATY ( Sergey A. TsYbanov ).                      *
 *  E-mail : saty@ntc.togliatti.su Phone : number +7 (8482) 378-17-53. *
 ***********************************************************************




-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 92 02:51:55 GMT
From:      ahalim@ics.uci.edu
To:        comp.protocols.tcp-ip
Subject:   FTP question


Is it possible to execute remote program on the other side of a ftp
session? (like 'rsh' inside ftp)

thanks
/aha
 

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 92 03:01:22 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??

In article <1992Jul22.203200.28669@tridom.com>, mwr@tridom.uucp (Mark Reardon) writes:
| In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A.
| Redmill) writes:
| |> I have a Sun 4 (IPC) with two ethernet cards running as a router for
| |> a small subnet.  I would like to install some vax stations under this
| |> subnet but Decnet packets don't seem to make it through the sun routed
| |> software.  
| |> 
| |> Can this be done??
| 
| The vaxes are running either Decnet IV or the new OSI based Decnet.
| in either case, the Suns won't handle it without some new software.
| The Sun handles IP and that is it.  The four solutions are :
| 
| 1. Upgrade the vaxes to use tcp/ip.
| 2. Upgrade the Sun to route the correct Decnet.
| 3. Replace the Sun with either a bridge or router to handle all 
|    protocols.
| 4. Place a bridge or router in parallel with the sun and have it
|    handle all non IP traffic.

There's one more solution which we use here in similar situations:
if the VAXen are running MultiNet, then just set up MultiNet to 
encapsulate DECnet IV in TCP/IP.  (You also need a friendly 
VAX on the backboneward side of the Sun to pull the DECnet
out of the TCP/IP packets and route them onward to the
rest of your DECnet.)  A fast, reliable, cheap solution (assuming
you've already got MultiNet!)

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
|>   If it ain't broke, break it.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 92 05:29:40 GMT
From:      shani@GENIUS.TAU.AC.IL (Oren Shani)
To:        comp.protocols.tcp-ip
Subject:   Re: ping works, but ftp/telnet get "no route to host"

In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>I receive a "no route to host" error?  Traceroute can find the host, and it
>is apparently on Alternet, if that makes a difference.
>
>Any info would be most helpful to this tcp/ip novice.  Thanks.
>
>--
 Looks like there are traffic filters somewhere along the route. Some, more
advanced, routers and bridges, are able to filter traffic, and for instance,
allow ping or finger and disable ftp or telnet to certain targets.

This probably should be in the FAQ list (?)
-- 
    __    __  Oren Shani (shani@genius.tau.ac.il) 
   /  /  /    Faculty of Engineering, Tel Aviv university
  /  /   --   Israel
 /__/ . __/ . "Hold your temper" -- The caterpillar to Alice

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 1992 07:47:09 GMT
From:      Alfred.Kayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Anybody installed 'authd' on IBM RS/6000???

Help, I want to install 'authd' on our RS/6000. Both available sources:
the original 'authd' and 'pidentd' fail to find certain vars in the kernel.
These variables are called '_file' and '_nfile'.

Anybody knows a solution???

Thanks in advance, Alfred

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

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 23 Jul 1992 11:56:01 CET
From:      Karl Keyte <KKEYTE@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   RFCs - How do I submit one?

Does anyone know the procedure for submitting an RFC, getting an RFC
number, etc?

Please answer to me directly:  KKEYTE@ESOC.BITNET

Thank-you,

Karl

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 1992 14:20:26 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <BrsM1C.36v@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
>In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>>I receive a "no route to host" error?  ....
 
>The site you are trying to ping is running a firewall gateway, because
>they're too lazy to beef up their host security and are relying on the
>firewall to protect themselves against external attacks.

I have to take exception to this remark. Use of a firewall doesn't indicate
laziness on the part of a site; it most probably means that the persons
responsible for the Internet connection and security of the sites' net are
either too understaffed to maintain all the hosts on their site, or they
don't have control over all the hosts, and are therefore not able to make
them secure. And there are doubtless many sites that suffer from both 
problems.

>I wish I had a transcript of Dave Clark's talk at the IETF last week.
>He said some great things about firewall gateways and mailbridges, and
>how they've essentially destroyed the whole purpose of having an IP
>internet, and have forced a lot of us to use mail as a transport-level
>protocol.

Yeah, I'd probably enjoy reading it myself. Unfortunantly, with the explosive
growth of the net, it's no longer an approximation of an ideal world. In
an ideal world, we wouldn't need locks on our doors, keyswitches in our 
cars, or firewalls on our nets. 

There are other considerations, too; accounting for net traffic (it does 
cost someone money somewhere down the line), maintaining security of
proprietary, sensitive, confidential, or classified information, and 
insuring that resorces are used for the intended purpose by the people
they're provided for.

Flaming admins as being "lazy" because a firewall is in place is *way*
out of line.


-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chariman of the Board and the CFO speak for SCI. I'm neither.
"Always remember, that someone, somewhere, is making a product that will
make your product obselete." Georges Doriot, founder of American R & D.

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 1992 14:39:36 GMT
From:      umrice02@ccu.umanitoba.ca (Stephen Rice)
To:        comp.protocols.tcp-ip
Subject:   Summary: Solutions(?) to NCSA Telnet Problems

After posting a message regarding the problems I was facing regarding the use
of NCSA Telnet I received many replies.  This is a summary of those responses.

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

NCSA Telnet will not allow you to log into a machine placed in host mode using
the 'telnet' command, only 'ftp' is allowed.

Telnetd, the Waterloo TCP stand-alone Telnet server will allow you to do this
and is available at sunee.uwaterloo.ca in directory pub/wattcp.  Though I have
downloaded this myself I have not got it working yet.

I have got SOSS working successfully on our network.  For those of you un-
familiar with this package, it is a package which allows you to mount IBM
PC disks on your unix machine using NFS.  It has a few shortcomings, 

1.	You must leave the machine in 'NFS server' mode.  The program is
	not memory resident, etc.  (though this is true for 'ftp'ing into
	a PC running NCSA Telnet also).

2.	You cannot mount a PC disk on another PC using this package though
	I understand using IDRIVE by FTP software or PC-NFS by Sun Micro-
	Systems will allow this.

Current Situation:  We have our PCs configured to run either SOSS or NCSA
Telnet server mode.  We can mount or ftp to any of the PCs (or from any of
the PCs to unix via Telnet/FTP) AND anyone can use the printer via NCSA's
lpr (included with Telnet).

Aside:

Number 2. above also raises the question.  We are running Interactive UNIX
(now owned by Sun) and there is a 'pcnfs' daemon.  Why?  Using SOSS we can
use the normal NFS daemon used by other UNIX systems why can't PC-NFS? --
Just my $0.02 (prices slightly higher in Canada, please include GST).
-- 
+-----------------------------------------------------------------------------+
Stephen Rice                                          "I am, therefore I think"
umrice02@ccu.umanitoba.ca                 "These are definitely my own opinions
University of Manitoba  CANADA                  or I would not have said them."

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 92 15:36:34 GMT
From:      Norbert_Papke@mindlink.bc.ca (Norbert Papke)
To:        comp.protocols.tcp-ip
Subject:   NDIS SLIP Driver

Hi,

I have a connectivity question that my local DEC office has not been able to
solve.  I am hoping that somebody on the net has an answer.

I need to dial in from my PC at home into our office network via a terminal
server (DECServer 300).  Once connected, I'd like to talk X over TCP/IP to some
of our Unix servers (it will be slow but it will be better than having to go
into the office at 3AM :-).  At the office I run Pathworks over TCP/IP, and
DECwindows or eXcursion.  Rather than go out and buy a different protocol stack
and X Server, I'd like to use the same software.  What I need is something that
will allow me to run IP over a serial line with DEC's TCP/IP for DOS.  This
"something" will probably be SLIP (supported by the terminal server).  Does
anybody know of an implementation of SLIP that works with DEC's TCP/IP?  Maybe
an NDIS SLIP driver?  Or am I totally off the mark and should be approaching
this problem differently?

Any help and suggestions are greatly appreciated,

-- Norbert.

--
Norbert Papke (Norbert_Papke@mindlink.bc.ca)
Prince Rupert Grain Ltd.
900 - 1055 West Hastings St.
Vancouver, BC, Canada

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 92 16:16:41 GMT
From:      weare@bostech.com (Ged Weare)
To:        comp.protocols.tcp-ip
Subject:   Re: Help wanted: Interlan Ethernet drivers

In article <241@warlord.UUCP> mhw@warlord.UUCP (Michael H. Warfield) writes:
>
>> [stuff deleted]
>
>	Hmm...  Same here.  It's a catch 22.  I got the boards basically
>because they were excess and useless for a commercial application (read
>that as "Your software is way overpriced!!!!").  I have the klunky DOS
>package but I need drivers for SCO UNIX.  All personal stuff.  Nobody
>in there right commercial minds will touch the things because they can
>get better boards and MUCH better software for less than the price of
>the drivers for the board!
>
Yeah, the unix package is overpriced, as far as private use goes.  As far
as being clunky, I can't say.  NCM did say they had vastly improved the
TCP package for unix.  You're right about price;  I can buy a version of
SysVR4 with TCP for $500, plus an Etherlink or something for less than
$100.

>
>	I got refered to NCM (I don't remember what that stands for).  They
>seem to be supplying the software for the boards.  They can quote you
>separate software packages for a lot of configurations, including upgrades.
>HOWEVER....  The individual I talk to didn't seem real enthusiastic.  I
>got the feeling he was being put out to even be discussing the subject with
>some lowly individual.  They also want around $500 just for the SCO drivers.
>Needless to say, there are better routes to go than that.  I don't know
>if they have anything for the ATT stuff but their number is 1-800-786-3696.
>As I say - their rep had a real attitude and their pricing sucks so lots'a
>luck.
>
>	I do a lot of consulting as well as my normal job as an Engineering
>VP for an outfit down here in Georgia.  My recommendation to anyone, after
>that encounter with NCM, is to avoid Interlan products like the plague!
>If that's their attitude to a consultant who can recommend for or against
>their products, heaven help the poor user who is stuck with them!
>> [stuff deleted]
>	Yea, my dozen or so are now collecting dust.  And Interlan has
>already lost several sales as a direct result!  Anyone asking or consulting
>me will get told that the software was so expensive I could not justify
>even evaluating the boards.  And I certainly would never recommend something
>that I couldn't even evaluate!
>
>	Michael H. Warfield
>	mhw@warlord.uucp

Well, I gotta say, in a pathetic attempt at fairness, that I had nothing but
good service from both Interlan (Ooops, Racal-Datacom), and from NCM.  They
did try hard to help me.  I talked to three or four different NCM people,
including a technical guy.  They even called me back!  In fact, a supervisor
called me back to ask if I'd been treated right.  I have to admit I was.
I'm bummed that I can't get a unix driver, but that's their marketing
policy, so I have to respect it, but not like it.  I agree with your
comments about losing sales through restrictive marketing policies (how
many copies of OS/2 would sell if IBM didn't do cheap competitive upgrades?).
Plus I kinda feel a hardware vendor ought to publish enough info for
a purchaser to write his own software.  Actually, the situation is
strange here, with one company making the HW (Racal Datacomm), and another
selling SW packages; maybe R-D can be persuaded to publish the NP600
interface, so they sell more boards?  May lose NCM some sales (actually
doubtful, at $1K per), but what does R-D care?

I also have to thank the many people who replied to my post (this included
several Interlan people).  Currently, I have the NP600 working for DOS in a
386.  I got pkt, NDIS and ODI drivers from the Racal Datacomm BBS, and some
shims and got ka9q working at least.  I couldn't get it to work in my old
286, because (I think) the 286 doesn't like bus-mastering (which the card
seems to need).  I also got DOS diagnostics.  I ended up using the ODI
driver, b/c it didn't need any non-PD software (the pkt driver was not
a .COM file, still can't figure *that* one out).  

As I said, still no unix.  The only un-explored avenue was that one of
the NCM people said (or implied, or atleast I inferred) that the NP600
might work in NI6510 (?) mode, as a dumb card.  That should not need
bus mastering, so I plan to check it out.  


----
Jed Weare                      weare@bostech.com
Boston Technology              (617) 246-9000 x3519
100 Quannapowitt Parkway
Wakefield, MA 01880.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 92 16:43:14 GMT
From:      dyer@spdcc.com (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

I was always under the opinion that "firewalls" and "mailbridges" (as they
were originally proposed for use when the ARPAnet and MILNET split) were a
Bad Thing.  To a certain extent I still agree.  However, after my experience
with this most recent Sun hacker/cracker who was meandering around the net
a few months ago invading hundreds of Suns and Ultrix machines, I have a
different opinion.  I was in the unfortunate situation of being responsible
for a group of Suns which were being invaded, and the loss of time and the
disruption which the research group experienced due to this was more than
annoying; it disrupted and sometimes destroyed real work.  I was doing
this strictly pro-bono in an informal capacity with a group I am associated
with, but at least I'm pretty familiar with the kinds of problems there are.
God help the burgeoning majority of workstation users who are totally
ignorant of issues like security as it relates to networks.

Listen, unless someone has a dedicated system manager who does nothing
else, and is a security fiend, it is very difficult to be protected
against someone who has infinite time, machine-like patience and an
encyclopedic knowledge of existing security holes in the binary distributions
of systems as shipped from companies like Sun.  Oh, and did I mention Sun?
These days, the situation is much more likely to be an autonomous
researcher taking a commodity out of a box and plugging it into their
institution's 10-Base-T connector in the wall.  Their interests are not
security; they've purchased this box to get their job done.  You can't hand
them a 20 page paper giving them instructions on how to FTP and then apply
the 30 most recent program patches to their version of the OS, that is,
once they've determined that patch #8 doesn't conflict with patch #1
and if they haven't upgraded their OS and wiped out earlier patches which
never got into subsequent commercial releases.  And few sites are large
enough and deem it important enough to provide support for this endeavor
centrally.

The creation of CERT was a good idea, but it's so far been mainly
reactive.  That's not a criticism, mind you--right now, that's a
full time job as it is.

I see the use of gateways and other technologies to provide a firewall
as inevitable and, for some sites, essential to their use of internetworks
today.  It's not just big multi-billion companies worrying about the loss
of trade secrets anymore, it's a matter of allowing unsophisticated users
to get their work done without interference from some sociopath with too
much time on his hands.

There are some real structural problems here.  Just one part of this
is the attention to security in their distributed products by the OS
vendors, which is remarkably lackluster.  Of course, what do you expect
when they don't warrant their software to actually DO anything anyway
except take up space on a distribution medium? :-)


-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 92 18:41:48 GMT
From:      joe@eng3.sci.com (Joe LaRocque)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wanted: PD Source for rwho

Is there someone out here who would be kind enough to mail a public domain
version of rwho to me? We don't have a full internet connection (we're using
UUCP) so I can't ftp to a site. 

Appreciation is given in advance.

Thanks

Joe La Rocque
SCI, Inc.
Huntsville, AL


-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 92 19:38:24 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??


In article <1992Jul22.200123.3530@arizona.edu>, leonard@telcom.arizona.edu 
|>| In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A.
|>| Redmill) writes:
|>| |> I have a Sun 4 (IPC) with two ethernet cards running as a router for
|>| |> a small subnet.  I would like to install some vax stations under this
|>| |> subnet but Decnet packets don't seem to make it through the sun routed
|>| |> software.  
|>| |> 
|>| |> Can this be done??
|>There's one more solution which we use here in similar situations:
|>if the VAXen are running MultiNet, then just set up MultiNet to 
|>encapsulate DECnet IV in TCP/IP.  (You also need a friendly 
|>VAX on the backboneward side of the Sun to pull the DECnet
|>out of the TCP/IP packets and route them onward to the
|>rest of your DECnet.)  A fast, reliable, cheap solution (assuming
|>you've already got MultiNet!)

Or WIN/TCP. The next release (called Pathway for VMS V1.0; don't ask why)
also supports DECnet over IP.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 92 19:40:20 GMT
From:      schultz@halley.est.3m.com (John C. Schultz)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   APPN and TCP/IP

APPN came up in a conversation regarding communications for VM and MVS
machines.  I was hoping someone could provide a review of TCP/IP
compared to APPN issues or point me to an appropriate location.

Thank you very much for your time.
--
   John C. Schultz   +1 (612) 733-4047   schultz@halley.serc.3m.com
   How to include the taste of Glendronach in a multi-media system?

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 1992 04:27:08 GMT
From:      iane@ccadfa.cc.adfa.oz.au (Ian Ellis)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip and WANB

Does anyone know of a product, public domain or otherwise, which will
provide tcp/ip facilities on a WANG 8000 series?

We have a WANG 7370 with an internal LAN controller and are looking for
alternative products to those supplied by WANG

Thanks


Ian Ellis

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 1992 04:52:28 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

>Use of a firewall doesn't indicate
>laziness on the part of a site; it most probably means that the persons
>responsible for the Internet connection and security of the sites' net are
>either too understaffed to maintain all the hosts on their site, or they
>don't have control over all the hosts, and are therefore not able to make
>them secure.

	It also can mean that the site cares about security. There are
loads of sites on the net that run NIS...  A firewall helps. Having a
firewall changes your problem domain. Basically, once you are firewalled,
you presumably *still* have some security - but the firewall acts a
multi-part role as:
	a) shield - making things harder is always better.
	b) fly-paper - detect intrusion attempts, and you *bet* I do.
	c) a logger - it is hard to get through any decent firewall
		without leaving a logged trace. note the phraseology
		here - many firewalls are not what I would call "decent".

mjr.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 1992 04:57:48 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

>I was always under the opinion that "firewalls" and "mailbridges" (as they
>were originally proposed for use when the ARPAnet and MILNET split) were a
>Bad Thing.  To a certain extent I still agree.

	Firewalls are a lot like Jersey barriers on a freeway. They keep
the irresponsible drunks in the other lane from being able to hit you
head on.

	Since a firewall is the individual site's decision, it's neither
good nor bad - it's just something you feel you need or not. There are a
LOT of companies on the net who wouldn't be there if they didn't have a
decent firewall.

mjr.

[Incidentally, put some recent stuff about the firewall I run is up for
FTP from decuac.dec.com, /pub/docs/firewall/*]

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 19:50:35 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??

In article <1992Jul23.193824.15759@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
>
> In article <1992Jul22.200123.3530@arizona.edu>, leonard@telcom.arizona.edu
> |>| In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A.
> |>| Redmill) writes:
> |>| |> I have a Sun 4 (IPC) with two ethernet cards running as a router for
> |>| |> a small subnet.  I would like to install some vax stations under this
> |>| |> subnet but Decnet packets don't seem to make it through the sun routed
> |>| |> software.
> |>| |>
> |>| |> Can this be done??
> |>There's one more solution which we use here in similar situations:
> |>if the VAXen are running MultiNet, then just set up MultiNet to
> |>encapsulate DECnet IV in TCP/IP.  (You also need a friendly
> |>VAX on the backboneward side of the Sun to pull the DECnet
> |>out of the TCP/IP packets and route them onward to the
> |>rest of your DECnet.)  A fast, reliable, cheap solution (assuming
> |>you've already got MultiNet!)
>
> Or WIN/TCP. The next release (called Pathway for VMS V1.0; don't ask why)
> also supports DECnet over IP.

Is the method used compatible with the method used by MultiNet?

> --
> Reece R. Pollack
> Senior Software Engineer
> The Wollongong Group, Inc.
--
James Harvey    IUPUI OIT Technical Support/Networks
harvey@iupui.edu  uucp: iugate!harvey  bitnet: harvey@indyvax

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 12:52:46 GMT
From:      kurt@rsvl.unisys.com (Kurt Matthys )
To:        comp.protocols.tcp-ip
Subject:   FIN and PUSH

I have recently run into a situation where a TCP implementation would not
process an input if the FIN flag was set and the PUSH flag was not. It appeared
to just stage the input and wait forever for a PUSH. As I read RFC 793, the
FIN implies a PUSH on input and the host should process the FIN and send a 
close to the application.

Comments anyone?

Kurt Matthys
Unisys

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 1992 14:25:54 GMT
From:      fillmore@emr1.emr.ca (Bob Fillmore 992-2832)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <CKD.92Jul20140814@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>David> == David Barr <barr@darwin.psu.edu> 
>
> David> And I thought it was sick when the College of Engineering
> David> decided to use DECNET to encapsulate IP packets so they could
> David> have one virtual ethernet spanning buildings.  (It was
> David> apparently the only solution.  I still can't believe it)
>
>Sickest of all was the "proposal" to put IP packets in MIME-format
>multimedia messages.  That gives you IP over UUCP, even over a
>multiple-hop UUCP path.
>

How about IP-over-SLIP-over-DECNETsethost-over-X.25?
Somebody here is actually using that in a production network!

-- 
Bob Fillmore, Technical Services Division          email: fillmore@emr.ca
  Information Management Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  580 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 16:06:34 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Jul23.224600.11081@polari> jsanchez@polari.online.com writes:
>A potential customer of ours wants some advice and I thought I would run
>it past the net.  Some/all of this may be a FAQ but bear with me.  First,
>he wants to be able to create lots of subnets and as a consequence is
>parsimonious with ip addresses.  He thinks that being able to run multiple
>subnets from one router port would allow him to have small subnets (to
>save IP addresses) and yet put several of them together in one physical
>ethernet segment.  Kinda weird I admit but that is the way customers are.
>
>To accomplish the above, he plans on running a netmask that is not on byte
>boundaries.  Nothing in principal wrong with this but are there practical
>problems that would lead you to avoid this kind of configuration.

Having multiple subnets one a wire is not that uncommon.  It's often
done when a site wants to have all subnets be the same size (hard to
avoid when running RIP), and some LANs have many more hosts than other
LANS.

The only problem I can think of right now with non octet aligned masks,
is that some older host TCP/IP implementations would only take octet
sized chuncks on netmasks.

Art

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 16:10:06 GMT
From:      brunner@practic.com (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <1992Jul23.142026.20112@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
>In article <BrsM1C.36v@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
>>In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>>>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>>>I receive a "no route to host" error?  ....

They are probably doing packet filtering based on ports at one or another of
the routers under their adminstrative control, for reasons of their own.

>>The site you are trying to ping is running a firewall gateway, because
>>they're too lazy to beef up their host security and are relying on the
>>firewall to protect themselves against external attacks.

Hmm, an ad hominum explination, always a pleasure to read in a technical list.
Having reluctently made a few dollars working for or against host security,
I respectfully note to those not entirely convinced by the offered rational
above, that for reasons of their own, the site in question, or any site,
may have chosen to obtain hosts which meet specific local needs, and don't
as yet meet a narrow subset of features thought of as offering "security"
to ip- (or smtp-, or decnet-, or uucp-) addressable hosts. In short, they
may be heterogeneous with some hosts meeting higher locally-defined needs
than denial of unathorized use -- like computing for instance.

>I have to take exception to this remark. Use of a firewall doesn't indicate
>laziness on the part of a site; it most probably means that the persons
>responsible for the Internet connection and security of the sites' net are
>either too understaffed to maintain all the hosts on their site, or they
>don't have control over all the hosts, and are therefore not able to make
>them secure. And there are doubtless many sites that suffer from both 
>problems.

They may also have intellectual property, or operational function, which
they value sufficiently to attempt some form of administrative filtering,
in addition to the staffing and competency issues.

>>I wish I had a transcript of Dave Clark's talk at the IETF last week.
>>He said some great things about firewall gateways and mailbridges, and
>>how they've essentially destroyed the whole purpose of having an IP
>>internet, and have forced a lot of us to use mail as a transport-level
>>protocol.

Dave is usually correct, but as he thinks quite a bit more than many, and
says what he thinks, he is frequently not correct. Send him mail and ask
for a copy, or invite him to write. Perhaps he's been misstated in this
summary of his remarks. In any event, this was not one of the more important
topics on the IETF adgenda, had it been, I'm sure there would have been
other points of view expressed, as well as discussion of technical details
of implementation, which are more to the point.

I'm looking forward to John's posting, "Administrative Packet Filtering
Considered Harmfull"... in comp.security.misc, or as an internet-draft...

-- 
#include <std/disclaimer.h>
Eric Brunner, Tule Network Services
uunet!practic!brunner or practic!brunner@uunet.uu.net
trying to understand multiprocessing is like having bees live inside your head.

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 16:12:26 GMT
From:      billp@Syntex.COM (Bill Putney)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Wang VM? Does it exist?

HELP!!!!

Does anyone out there know of a package that will allow a Wang
VS8000 running VM to communicate with TCP/IP users on a LAN?

Wang has come out with TCP/IP for VM (kind of...).  It implements
out bound telnet but not in bound.  People with some standard
connection to the Wang can telnet to other hosts but people on
other hosts (or terminal servers or PC's running TCP/IP or...)
can't connect to the Wang.

We are trying to convert all of our network connections to TCP/IP
and the Wang VM systems are the last hold out.

Thanks, Bill

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 17:44:34 GMT
From:      tim@rri.uucp (Tim Buck)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   New Internet protocol for image transfer

I recently heard of a new protocol being developed for image transfer
on the Internet, including compression.  Does anyone know what I'm talking
about?  Can you point me towards some information?  An RFC?

Thanks
Tim Buck
timbuck@borg.lib.vt.edu
rri!tim@vtserf.cc.vt.edu

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 19:10:56 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

Let me very strongly second what Marcus Ranum said about the need for
firewalls.  No, I don't want to run one.  However, given the abominable
state of host security, I have no choice.  You can blame software
designers for not paying enough attention to the problem (and certainly,
that's some of the trouble), or you can blame the current state of
software engineering (if all large programs have bugs, then by Murphy's
Law all large network servers have security bugs), or you can blame
lax administration by folks who are more interested in getting their own
work done.  It doesn't matter.  I may or may not be able to keep my
own machine secure (modulo new surprises from the Hole of the Month Club);
I *know* I can't secure the tens of thousands of machines connected
to AT&T's internal networks.

Are their attackers out there?  You'd better believe it.  Skeptics are
invited to ftp dist/internet_security/dragon.{dvi,ps} from research.att.com;
it's a draft of a paper I'll be presenting at the UNIX Security Symposium.

		--Steve Bellovin

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 1992 20:35:44 GMT
From:      nrt@watson.ibm.com (Nicholas R. Trio)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

I do use firewalls/secure servers here at IBM.  I've sometimes thought
of myself as a "bad neighbor" or a leach since my users can get out
to the Internet, but we don't really provide much return service for
others.  However, it is a necessary evil because of folks who I'm sure
would love to get into our systems.

When someone asks me about networks, I think of them as a highway, with
folks host systems/workstations as houses with front doors and locks
on them.  In an ideal environment, every workstation or host would have
really secure front doors on them, and everyone can drive up to the houses
anywhere on the net...only if they have the right key can they get
into the house.

The problems are (1) the "front doors" to the computers just aren't strong
enough and (2) even if they were, it's possible to get copies of the
"keys" (passwords, etc.) by sniffing the network.  Thus, for the most
part, I have to have a gate that only allows folks to get out, and only
lets in those who are authentic users.

Authentication is possible (many places are using authenticator
"smart cards" like the Digital Pathways' Secure-Net Key which allows
for authentication of remote users.  However, for the immediate future,
I suspect many organizations worried about who's "driving up to their
door" will use firewalls.

Nick Trio (nrt@watson.ibm.com)
IBM T.J. Watson Research Center




-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 1992 21:05:41 GMT
From:      gmarzot@mitre.org (G. S. Marzot)
To:        comp.protocols.tcp-ip
Subject:   what is ifnet?

I need to be pointed in the right direction.
I am setting up a syncronous 256kbit link on a SPARC2 w/ a Sun HSI/S card.
The card claims to support a standard "ifnet" interface to the kernel. The
card also claims to support INR, X.25, and SNA. What I want is basic TCP/IP
services(rlogin, ftp) over the link. Oh, I should also mention that the
link is fairly long delay (~250 msec one way) so we are considering a
variant transport layer protocol, NETBLT. Any info, books to read, source
code to check out , etc. would be greatly appreciated. Thanks in advance
for any help.
-GSM

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 92 22:48:56 GMT
From:      jpm@cs.hut.fi (Jussi-Pekka Mantere)
To:        comp.protocols.appletalk,comp.protocols.tcp
Subject:   Re: Wanted: Telnet over ADSP

David Yost <yost@adobe.com> writes:

   Now that we have AppleTalk remote access, it would be nice
   to be able to do unix logins over the AppleTalk link.

A French company has done something like this for A/UX. It let's you
connect to the A/UX host via the ADSP tool, and the session you end up
with "feels" just like a telnet/rlogin connection. The software
consists of a server for the A/UX host, which provides you with the
ADSP connection point. The login at the A/UX end ends up using a pty
device, so I suppose there's some TCP/IP going around, although
internally on the ADSP server host. 

I have no idea if this has been implemented on other AppleTalk-capable
UNIX platforms.

From the "banner":

 **** CI-Sunset 1.02 DEMO version ****
  (restricted to 2 sessions of 5 mn)
   Authors: F.Bouquet & R.Flattin
(C)opyright 1991-92 CORNUT Informatique
      Phone: (33) 77 93 57 46
       AppleLink: CORNUT.INF

Best Regards,

Chape

PS. Iff you have a FastPath/GatorBox/whatever doing AppleTalk-IP
gatewaying somewhere on the corporate net, you could use MacTCP on the
ARA connected Macintosh...

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 92 23:50:03 GMT
From:      lamy@sobeco.com (Jean-Francois Lamy)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

>>The site you are trying to ping is running a firewall gateway, because
>>they're too lazy to beef up their host security and are relying on the
>>firewall to protect themselves against external attacks.

Or have to convince auditors that the advantage the development groups
get by being on the Internet does not compromise the security of the
operational and strategic data on the other sites on the network.  If you're
unable to clearly show that the packets from the outside world aren't touching
the production wires, you may find yourself on the wrong side of an
inquisition real quick...

Jean-Francois Lamy                                        |   lamy@sobeco.com
Computer Networks and Systems				  |   lamy@sobeco.ca
Sobeco Ernst & Young, Montreal, Canada H2Z 1Y7            |   uunet!sobeco!lamy

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jul 1992 04:05:58 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <1992Jul23.142026.20112@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
>In article <BrsM1C.36v@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
>>In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>>>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>>>I receive a "no route to host" error?  ....
 
>>The site you are trying to ping is running a firewall gateway, because
>>they're too lazy to beef up their host security and are relying on the
>>firewall to protect themselves against external attacks.
>
>I have to take exception to this remark. Use of a firewall doesn't indicate
>laziness on the part of a site; it most probably means that the persons
>responsible for the Internet connection and security of the sites' net are
>either too understaffed to maintain all the hosts on their site, or they
>don't have control over all the hosts, and are therefore not able to make
>them secure. And there are doubtless many sites that suffer from both 
>problems.

There are a number of reasons other than laziness or overwork that an
organization may firewall (seeing as I put these things in, I'll explain):

1)	The company may have rather loose security internally (i.e. Runs NIS
	for password validation) and doesn't like the idea of someone doing
	a ypset/ypcat on their password files, or its moral equivalent.
	This "rather loose" part may be a >requirement< by some of their
	hardware or software that they cannot control (see some of the major
	system vendors for some of the worst offenders here, and their utter
	failure to provide off-the-shelf secure alternatives.  KERBEROS is
	>NOT< adaquate in most commercial environments, as tickets expire,
	and for most people in these environments that is plain unacceptable).
	Organizationally it may be deemed acceptable to have this security
	level for employees, but not against outsiders.

2)	The organization may have a large number of MAC and PC desktops, all
	or any of which may be able to be compromised to someone's extreme
	detriment with no good way to stop the abuse.  Not all the world's a
	Unix.

3)	The organization may want to run NFS, and either has too many hosts
	to do individual host validation in the exports file, or just can't
	for other reasons.  This is a real bitch with the NFS mount
	protocols; there is >no< good way to stop this from being a
	potential problem in many organizations.  The ability to wild-card
	domain names in the export list as in "allow anyone from "mcs.com"
	access), along with a local name server (which prevents spoofing the
	reverse lookups) would solve this easily -- but it isn't happening
	these days with the major vendors -- again.  The NETGROUP paradigm
	does >not< help in many of these cases, especially when combined
	with the NIS problem.

4)	The organization may not like the idea of the local (or
	long-distance) teen-age hacker crowd taking pot-shots at their 
	security on a daily basis across several hundred or thousand hosts.  
	It is much easier to watch, and defend, one entry point.

5)	Change the offender in #4 to some corporate espionage types, and add
	a company that has significant computer-based assets, and you have
	yet another argument.

>>I wish I had a transcript of Dave Clark's talk at the IETF last week.
>>He said some great things about firewall gateways and mailbridges, and
>>how they've essentially destroyed the whole purpose of having an IP
>>internet, and have forced a lot of us to use mail as a transport-level
>>protocol.

Hogwash.  If it is that important to an organization, the firewall can 
provide proxy service for it.  It is >not< that big a deal to provide a
proxy connection for these kinds of things, >provided< that you have a nice
clean requirement.  The generic "anyone can do anything" doesn't cut it in
Corporate America anyway.

>Yeah, I'd probably enjoy reading it myself. Unfortunantly, with the explosive
>growth of the net, it's no longer an approximation of an ideal world. In
>an ideal world, we wouldn't need locks on our doors, keyswitches in our 
>cars, or firewalls on our nets. 
>
>Flaming admins as being "lazy" because a firewall is in place is *way*
>out of line.

Agreed.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 92 08:34:28 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <1992Jul24.203544.28491@watson.ibm.com> nrt@watson.ibm.com (Nicholas R. Trio) writes:
>The problems are (1) the "front doors" to the computers just aren't strong
>enough and (2) even if they were, it's possible to get copies of the
>"keys" (passwords, etc.) by sniffing the network.

Call me a Capitalist Pig, but no matter how strong my front door is
and no matter how well protected i keep my keys, i still consider my
front yard private property and i might put up a fence to keep people
away from my house.
						don provan
						donp@novell.com

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jul 1992 14:46:31 GMT
From:      ravi@mercury.uucp (Ravindra P Nirgudkar)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <CKD.92Jul20140814@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>David> == David Barr <barr@darwin.psu.edu> 
>
> David> And I thought it was sick when the College of Engineering
> David> decided to use DECNET to encapsulate IP packets so they could
> David> have one virtual ethernet spanning buildings.  (It was
> David> apparently the only solution.  I still can't believe it)
>
>Sickest of all was the "proposal" to put IP packets in MIME-format
>multimedia messages.  That gives you IP over UUCP, even over a
>multiple-hop UUCP path.
>
>(You definitely have to tweak the retransmit timers though :-)
>--
>Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
>   ``The First Amendment is often inconvenient.  But that is besides the
>  point.  Inconvenience does not absolve the government of its obligation
>         to tolerate speech.'' --Justice Anthony Kennedy, in 91-155


Hello Netters,

I am Ravi Nirgudkar, a graduate student in Electrical Engg. at Mississippi
State Univ. I would like to have information on following terms.

(1) F.L.D.I. Fiber Line Distributed Interface.

(2) Dual F.D.D.I.

I will appreciate, if any of you can send me references, where I can get more information.

Thanks

Ravi
P.S. Please send me the mail at ravi@ee.msstate.edu

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jul 92 16:37:22 GMT
From:      alan@oetl1.scf.lmsc.lockheed.com (Alan Strassberg)
To:        comp.protocols.tcp-ip
Subject:   Re: ODI and Clarkson driver spec

In article <711771662snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>In article <1992Jul20.170533.19619@pacdata.uucp> johnr@pacdata.com writes:
>
>   Would a kind soul point me in the right location to find the
>   ODI (Open Data-link Interface) specification and the

	The ODI specs can be found on ftp.is.sandy.novell.com
	(137.65.12.2) in odi/specs. Here's the readme.txt from
	there below.

					alan

This directory contains specifications for the Novell Open Datalink Interface
specification (ODI).

The ODI provides a media independent mechanism for multiple flavours of
overlying network and transport protocols to share LAN interfaces
within network entities. Currently, specifications exist for the DOS, OS/2
and NetWare 3.X server environments. Of course, implementations of all
the ODI specifications exist and are available from Novell.

Note: These specifications are provided as informational pieces only.
      Driver developers should contact Novell Labs regarding professional
      developer programs, training and toolkits. Details are in the README
      files contained in the various ZIP files.

The relevant files are:

      ODI_SRV.ZIP:	Specs for the NetWare 3.X server ODI
      ODI_DOS.ZIP:	Specs for the (DR)(MS)(PC)-DOS ODI
      ODI_OS2.ZIP:	Specs for the IBM OS/2 ODI

Refer to the "LICENSE.TXT" files for legal details on what you may and
may not do with these files.
-- 
Alan Strassberg   alan@oetl1.scf.lmsc.lockheed.com     (408) 425-6139

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jul 92 02:11:53 GMT
From:      andr@elvis.sovusa.com (Andrei Arkhipov)
To:        comp.protocols.tcp-ip
Subject:   DesqView/X

I wonder if DesqView/X is working on PC-NFS 4.0.

   Andrei.


-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jul 1992 10:08:25 GMT
From:      kbridge@magnus.acs.ohio-state.edu (Doug Karl)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

Folks,  I have recently released for annonymous ftp an IP, DECNET, AppleTalk,
etc firwall.  It is in the form a bridge similar to PCBRIDGE called
KarlBridge.  If you get a chance please pick it up and let me know what
you think.  (Also an inexpensive version is available from a real company
with support and all that stuff).

OSU KarlBridge can be found on: nisca.acs.ohio-state.edu (128.146.1.7)
 /pub/kbridge

FROM THE BROCHURE:

The OSU KarlBridge is a full featured protocol filtering bridge for Ethernet.
It has the most extensive filtering capability of any bridge or router
available.  It will filter packets by any Ethernet protocol or Ethernet
address and also IP Socket (incomming and/or outgoing), IP address, IP Subnet,
AppleTalk Server Name, AppleTalk Zone Name, DECnet Object and DECnet address.

Features:
	1) Ping'able with SNMP support for MIB-II, Ethernet-like Interface MIB,
	   and Bridge MIB.
	2) Can be configured to filter specific packets by protocol, address
	   server name and zone name by the use of easy to understand menus.
	3) Provides protection against erroneous Ethernet packets, that a
	   standard bridge does not provide.
	4) Leaks are greatly reduced compared to standard bridges, due to
	   unique filtering and timed-learning algorithms.
	5) Works on any Thin or Thick Ethernet with 10BASE-T optional.
	6) Very good packet forwarding rate; 8100 packets per second.
		(If you choose to use your own clone this may vary)
	7) Excellent packet forwarding delay; 140 uS (for small packets)
		(If you choose to use your own clone this may vary)
	8) Easily upgraded, since the code and filters are on standard PC
	   compatible bootable floppy.

Any questions....  Send e-mail to kbridge@osu.edu

Doug Karl
Senior Computer Specialist
Ohio State University

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 92 16:35:28 EST
From:      ejones@desire.wright.edu
To:        comp.protocols.tcp-ip
Subject:   HELP: Slip connection between PC and DECstation

I would like to be able to run SLIP between a pc at home and our DECstation
5000 at school. I need to dial up to a terminal server and connect to our
machine over LAT. I have set up the DECtstation end correctly. (I think) But,
how do I connect to it from the PC? I tired using procomm to dial the modem
and connct to our machine. Then, I exit procomm without hanging up the line.
Then, I run the slip packet driver SLIP8250 and the run CUTCP. But, how
does cutcp know that I am connected to the machine? There must be something
I am missing out on. What would be the best way to accomplish what I am 
looking for? Your help is greatly needed/appreciated.
	
	Ed Jones
	Wright State University
	Dept. of Psychology
	ejones@desire.wright.edu 

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jul 1992 21:16:39 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Terminology for firewalls (was Re: Firewall usage)

kbridge@magnus.acs.ohio-state.edu (Doug Karl) writes:
>Folks,  I have recently released for annonymous ftp an IP, DECNET, AppleTalk,
>etc firwall.  It is in the form a bridge similar to PCBRIDGE called
>KarlBridge.

	I don't want to start a war, but I'd like to propose that we try
to agree on some terminology. What exactly is a "firewall"? I believe that
a firewall addresses more than just routing and IP connectivity. These
are my rough definitions:

Simple gateway - a node which is reachable on two networks, but has routing
	disabled, making it a termination point on both. This is typically
	a host with TCP/IP forwarding disabled.

Screening router - a router that can contain some degree of logic to perform
	host or service-based access control. Screening routers include some
	commercial routers, as well as host-based routers with screening
	services. (E.g.: KarlBridge, ULTRIX nodes with screend)

Screened network - a private network that is connected to an untrusted
	network via a screening router. It is important to note that a
	screened network is a matter of degree, and that in order to
	work a screened network must share routes with the untrusted
	network.

Screened subnet - a subnet which sits between a private network and an
	untrusted network, with a screening router mediating access between
	them. In some configurations, screened subnets are configured such
	that routes are not given between the private network and the
	untrusted network. Often a simple gateway node is installed on the
	screened subnet, to act as a network access point.

Trusted application gateway - a software gateway for a given application,
	such as a telnet "forwarder", or relay. Sendmail is a trusted
	(or at least some versions) application gateway.

Firewall - a combination of a security policy with some of the components
	above. Specifically, an implementation of the given policy that
	is enforced by a combination of screening and/or routing.


	I like to think of access (routing and connectivity) in terms of
Direct - routes and traffic are shared between the private network and
	the untrusted network.
Indirect - routes and traffic are passed through some kind of controlling
	mechanism that prevents routes from being shown between the
	private and untrusted networks, and prevents traffic from passing
	directly between the two networks. Communication is accomplished
	by trusted application gateways.

	In other words, in my terminology, a firewall may be made by using
KarlBridge and some policy to build a screened network or screened subnet.
By itself, KarlBridge does not a firewall make; it is a very useful building
block.

	Note that many of the components above can be combined, and I
believe that my terminology retains its clarity in such a case. The kind
of firewall I run can be deemed a "screened subnet with a simple gateway,
hosting a suite of trusted application gateways with indirect access".

	This is not to imply that any one technique is better or worse,
but it's difficult when someone says "I am sheltered by a firewall" to
know if it's a relatively trivial firewall such as a screened network
with fairly wide access for telnet and mail, or if it's something much
more complex, like the AT&T or Digital corporate gateways.

	Comments??

mjr.

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jul 1992 21:36:53 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology for firewalls (was Re: Firewall usage)

>Firewall - a combination of a security policy with some of the components
>	above. Specifically, an implementation of the given policy that
>	is enforced by a combination of screening and/or routing.

	I should have mentioned that I believe that a "policy" needs to be
something coherent and consistent that is more or less regular. I don't
believe that a firewall can be implemented successfully by just plugging
onto the network and disabling a bunch of stuff until it "works". I'm
as far from a theoretical kind of guy as I think you can get, but I really
think it's very important here to have a clear statement of the goals of
the firewall before any connection is undertaken.

	Simply dividing the overall philosophy of the firewall into one
of these two categories or the other will make a huge difference:
"everything not expressly forbidden is permitted"
"everything not expressly permitted is forbidden"

	Consider that in the latter case, the administrator's life is
(hopefully!) easier - we tilt instinctively towards more security. In
the former case, the user's life is usually easier - they are free to
do anything that they can think of that the administrator has not
identified as a security risk and blocked.

mjr.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 00:47:28 +0000
From:      vadim@cix.compulink.co.uk (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Cc:        vadim@cix.compulink.co.uk
Subject:   No subject


Hello Everybody...

I'm looking for the way to retrieve couple of old Usenet messages,
one is:
 Message-ID: <8807200426.AA01221@helios.ee.lbl.gov> 
        Newsgroup: comp.protocols.tcp-ip
        July 1988

The second one is:
 Message-ID: <881231121.AA19744@helios.ee.lbl.gov> 
        Newsgroup: comp.protocols.tcp-ip
        July 1988
 

Do you have any ideas?

 Vadim.
-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France



-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 07:26:37 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

In article <AJOhJRg8RQ@ntc.togliatti.su> saty@ntc.togliatti.su writes:
>I write some application ( TSR type ) based on Packet Driver
>( Clemson University Engineering Comp Ops Version 9) and I have
>one tragic problem. I can not send ethernet packets while
>my receive handle works. How can I do it correctly?
>My ethernet card is 3C505.

I suppose that you try to send a packet while you are in the receiver
(called by the packet driver)? Well, I vaguely remember a statement from
Russ Nelson that this may not work with 1.09 compliant drivers. The spec
does not say anything about this, but the general consensus is that it is
bad practice.

What you could do is to have the response packet sent at the next timer
interrupt.

Regards,
-Roger


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 10:11:02 GMT
From:      ebc@uis.co.za (Errol Back-Cunningham)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Wang/SCO communications.


Does anyone have experience of connecting a Wang VS100 running
VS 7.21.03 to a SCO UNIX 486 for a remote login session? 

We're using TCP/IP and the SCO login screen keeps scrolling,
making login inpossible.  Are there any other connectivity
products available, or, does anyone know what problem we might
be encountering?

======================================================================
Errol Back-Cunningham                         ebc@uis.co.za
Unix Information Systems (Pty) Ltd (UIS)      Tel +27 21 4194107
Cape Town, South Africa                       Fax +27 21 252828

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Monday, 27 Jul 1992 10:46:10 CET
From:      <MPACE@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Brdcast datagram size problem

Hi netters,

we are currently implementing a library, on top of UDP, which supports
reliable broadcast as well as point-to-point transmission.

The implementation is based on the Berkeley socket under SunOS 4.1.2
and tries to hide to the programmers the socket details, providing a more
user-friendly interface.

The problem we have encountered concerns the size of the datagram one
can send using such interface.

In particular, we discovered that we can send datagrams of up to
16KBytes (setting the send buffer size with the SO_SNDBUF socket
option) when we use point-to-point transmission, but we can send ONLY
MUCH SMALLER DATAGRAMS (less than 2KBytes) when using BROADCAST.

In practice, what happens is that the "sendmsg" primitive we are using
returns (in the case of broadcast) with an "message too long" error.

Does anyone know if this is a limitation of the socket interface (in
case of broadcast) ? Or is some of our assumptions wrong ?

Any help will be appreciated. Cheers.

Marco & Andrea.


   Andrea Baldi
   Bitnet  : abaldi@esoc.bitnet
   Uucp    : unido!esoc.bitnet!abaldi

   European Space Agency (ESA)
   European Space Operations Center (ESOC)

   Robert-Bosch-Str 5
   D-6100 DARMSTADT West-Germany

   Phone 0049-6151-902762
   Fax   0049-6151-90-495  Tlx: 419453



-------------------------------------------------------------------------
Marco Pace, Software Engineer
ESOC, Robert-Bosch-Strasse 5, D-6100 Darmstadt, Germany
E-mail: MPACE@ESOC.BITNET
Voice:  +49 (0)6151 903065
Fax:    +49 (0)6151 904065
-------------------------------------------------------------------------

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Monday, 27 Jul 1992 11:17:48 CET
From:      Karl Keyte <KKEYTE@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   UDP Broadcast - Maximum message size

Does anyone know why (on our Sun 4 systems) UDP point-to-point messages
can be up to around 16KB (by setting the send buffer size), but
broadcast messages under 1KB?  Can we change this?  Are we doing something
wrong or forgetting to do something to allow us to broadcast larger
messages?

Please help!  Reply directly to me please:  KKEYTE@ESOC.BITNET

Thanks,

Karl

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 13:29:44 GMT
From:      fenner@cmf.nrl.navy.mil (William C Fenner)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??

In article <1992Jul22.203200.28669@tridom.com> mwr@tridom.uucp (Mark Reardon) writes:
>In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A. Redmill) writes:
>> [Can I route DECNet using a Sun?]
>
>The four solutions are :
>
>1. Upgrade the vaxes to use tcp/ip.
>2. Upgrade the Sun to route the correct Decnet.
>3. Replace the Sun with either a bridge or router to handle all 
>   protocols.
>4. Place a bridge or router in parallel with the sun and have it
>   handle all non IP traffic.

5. Encapsulate your DECNet packets into IP packets, which the Sun can then
route.  A grad student at PSU wrote some software that runs on a 386 PC that
will create a "virtual ethernet" via IP routing.  It requires one PC on each
seperate routed network that wants to be part of the "virtual ethernet".
It can filter (I think -- it's been a while since I talked to him about it)
based on Ethernet address and/or protocol numbers.

The only disadvantage is that you need a dedicated PC in each location.

  Bill
-- 
Bill Fenner                  fenner@cmf.nrl.navy.mil

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 13:56:44 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.protocols.tcp-ip
Subject:   Digital Pathway ?

From: nrt@watson.ibm.com (Nicholas R. Trio)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Sender: news@watson.ibm.com (NNTP News Poster)
Message-ID: <1992Jul24.203544.28491@watson.ibm.com>
Date: Fri, 24 Jul 1992 20:35:44 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
References: <BrsM1C.36v@cs.columbia.edu> <1992Jul24.045228.11119@decuac.dec.com> <17008@ulysses.att.com>
Nntp-Posting-Host: slapshot.watson.ibm.com
Organization: IBM T.J. Watson Research Center
Lines: 30

 >Authentication is possible (many places are using authenticator
 >"smart cards" like the Digital Pathways' Secure-Net Key which allows
 >for authentication of remote users.  However, for the immediate future,
 >I suspect many organizations worried about who's "driving up to their
 >door" will use firewalls.
 
 >Nick Trio (nrt@watson.ibm.com)
 >IBM T.J. Watson Research Center

Can anyone provide a phone number or address for Digital Pathway?

Thank you.

Paul Hardiman
University of Wisconsin - Milwaukee
hardiman@csd4.csd.uwm.edu





-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 14:17:26 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital Pathway ?

>Can anyone provide a phone number or address for Digital Pathway?

	Digital Pathways, Inc
	201 Ravendale Ave.
	Mountain View, CA 94043

	Tel: 415.964.0707 

mjr.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 1992 02:44:34 -0700
From:      tsudik@pollux.usc.edu (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   Firewall usage

 
In article <1992Jul28.010344.9414@PA.dec.com> mogul@pa.dec.com (Jeffrey Mogul) 
writes:
   
   >In article <JTW.92Jul27142002@pmws.lcs.mit.edu> jtw@lcs.mit.edu 
   >(John Wroclawski) writes:
   >>Dave [Clark's] second point is that perhaps it is time to rethink the core
   >>architecture of the internet (or its follow-on) to specifically
   >>-include- mechanism to separate organizational policy functions (such
   >>as authentication, logging, and access control) from the actual
   >>service functions running on the typical host.
   > 
   >Actually, I think this approach was (in embryonic form, at least)
   >suggested several years ago by Deborah Estrin, who developed the
   >concept of Visa protocols.  In this model, "border" routers pass

Visa protocol addresses only end-to-end (in terms of domains, not hosts) access 
control/authentication issues. Control of transit traffic is also quite 
important and will (may) become more so in the future. Charging for providing
transit services may well become the chief reason for implementing 
transit "hurdles" (the term "firewall" doesn't really apply here). 
For details, see "Secure Control of Transit Internetwork Traffic" (D. Estrin &
G. Tsudik), Computer Networks and ISDN Systems, October 1991.

   >only those packets deemed allowable by an Access Control Server (ACS).
   >Instead of requiring each packet to pass through an ACS on the way
   >in or out of an organization, the end hosts get cryptographically-
   >sealed thingies (visas) to stick onto their packets.  This allows
   >a distributed implementation, but also allows the ACS to set whatever
   >policy is desired.  The downside is that the cryptographic stuff could
   >be rather costly, and the whole model depends on every external-access
   >host implementing the mechanism.   For details, see
   >    Deborah Estrin, Jeffrey C. Mogul, and Gene Tsudik.
   >    Visa Protocols for Controlling Inter-Organization Datagram Flow.
   >    IEEE Journal on Selected Areas in Communication 7(4):486-498, May, 1989.

A more up-to-date Visa protocol description can be obtained via anonymous
FTP from jerico.usc.edu (pub/gene/new-visa.ps.Z). 

   >.... 
   >From time to time, I (hidden behind a firewall) find Digital's policies
   >to be a major pain; I still don't use services such as WAIS because of

Ditto for IBM (imho). 

   >the extra effort involved.  But, I (and my coworkers) no longer spend
   >a significant part of our time either tracking down intruders, or
   >explaining to the corporate security types why they shouldn't shut down
   >our gateway complex.
   > 
-- 
----------------------
Gene Tsudik
Spiritually at the University of Southern Califlower
Physically at the IBM Zurich Research Laboratory

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 15:40:55 GMT
From:      nrt@watson.ibm.com (Nicholas R. Trio)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital Pathway ?

In article <1992Jul27.135644.18760@uwm.edu> hardiman@csd4.csd.uwm.edu (Paul V Hardiman) writes:
>
>Can anyone provide a phone number or address for Digital Pathway?

Digital Pathways
201 Ravendale Drive
Mt. View, CA 94043

Nick Tri (nrt@watson.ibm.com)
IBM T.J. Watson Research Center




-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 16:11:24 GMT
From:      wrl@wdl1.wdl.loral.com (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   ATT 3B2 Hop Counter

Hi,

We have a user with a ATT 3B2 computer. We think we have a problem
with data packets taking more than 16 hops through the NSFNET
T3 network and the MILNET and the 3B2 is ignoring them because >16.

Anyone know how I can increase the hops to a normal 32 or so.

I don't have the computer here so I can't read any manuals so
any help is really appreciated.

Bill

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 16:21:34 GMT
From:      tmd@s1.gov (Tina M. Darmohray)
To:        comp.protocols.tcp-ip
Subject:   traceroute


Where can I get the latest version of traceroute?  Will it involve kernel
mods?  (I'm interested in suns, sgis, Dec Ultrix).  Thanks in advance,

	Tina
	tmd@s1.gov

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 16:51:36 GMT
From:      geray@ecs.umass.edu
To:        comp.protocols.tcp-ip
Subject:   Econfig question

Hello Netters,
Do I have to Econfig a Novell file server if I use ipxodi and odipkt and
PD applications ? Or Does the file server not need to be Econfiged ?
Thank you in advance.

Okan Geray

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 18:51:32 GMT
From:      dmiller@dragon.tricity.wsu.edu (David L. Miller)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc,comp.sys.ibm.pc.net,comp.unix.ultrix
Subject:   Paradox over TCP-IP/NFS

We are attempting to run Paradox on our network, but we are only running
TCP/IP (no Novell, ...).  Specifically, we are running PC/TCP version 2.05
with Interdrive on our PCs.  The server is a DECsystem 5000/200 running
Ultrix 4.2.

Following is a description of the problem from our Database Administrator,
please respond to her directly.

>From brunken@beta.tricity.wsu.edu Mon Jul 27 11:37:17 1992
>Date: Tue, 21 Jul 1992 14:35:02 -0700 (PDT)
>From: Cyndy Brunken <brunken@beta.tricity.wsu.edu>
>To: "David L. Miller" <dmiller@beta.tricity.wsu.edu>
>Subject: Paradox
>
>Paradox has a police file called PARADOX.NET.  When I try to load Paradox
>from the server I get the following error message:
>
>  "Can't start Paradox: unable to record lock/unlock e:\PARADOX.NET.  You
>   may have insufficient access rights to directory e:\"
>
>I have mounted as user root, and I still get this problem.  Paradox will
>run from the server, if I write the PARADOX.NET file onto my PC's hard
>disk.  The Paradox man from BCSR thought that it was a problem between UNIX
>lock/unlock protocols and Paradox.
>
>Do you need more?
 
-- 
*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 19:03:45 GMT
From:      Gary White <gwhite@arco.com>
To:        comp.protocols.tcp-ip
Subject:   satellite link file transfers

Hi-
Between Texas and Alaska via a satellite -linked communications link, we 
find that FTP goes awfully slowly.  Has anybody learned how to tune FTP,
or come up with some other software, to go fast on a satellite link?

Thanks-
Gary White

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 19:20:02 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage


In article <1992Jul24.161006.12786@practic.com> brunner@practic.com (Thomas Eric Brunner) writes:

   >>I wish I had a transcript of Dave Clark's talk at the IETF last week.
   >>He said some great things about firewall gateways and mailbridges, and
   >>how they've essentially destroyed the whole purpose of having an IP
   >>internet, and have forced a lot of us to use mail as a transport-level
   >>protocol.

   Dave is usually correct, but as he thinks quite a bit more than many, and
   says what he thinks, he is frequently not correct. Send him mail and ask
   for a copy, or invite him to write. Perhaps he's been misstated in this
   summary of his remarks.

Dave made two points. The first was that the architecture of the
current internet is end-to-end, and does not have any notion of
firewalls. He argued that because of this, firewalls make some things,
such as introducing new services, much more difficult than they should
be, and as a result people resort to odd things like using mail as a
transport.

Dave's second point is that perhaps it is time to rethink the core
architecture of the internet (or its follow-on) to specifically
-include- mechanism to separate organizational policy functions (such
as authentication, logging, and access control) from the actual
service functions running on the typical host.

His key observation is that if we can provide these "checkpoint"
functions at administrative boundaries as part of a well-designed
architecture, rather than in an ad-hoc manner, we might be able to
achieve two goals at once - provide a network which can -better- meet
the security and usage requirements of a wide range of people, and at
the same time preserve some of the open access which has driven the
incredible growth of the internet so far.

Implicit in this observation is the belief that if we -don't- succeed
in doing something like this, the continuing rapid spread of firewalls
is inevitable, for the simple reason that many people feel they simply
have no choice.

Responding to the same quote, karl@ddsw1.mcs.com (Karl Denninger) writes:

   Hogwash.  If it is that important to an organization, the firewall can 
   provide proxy service for it.  It is >not< that big a deal to provide a
   proxy connection for these kinds of things, >provided< that you have a nice
   clean requirement.  The generic "anyone can do anything" doesn't cut it in
   Corporate America anyway.

I suspect Mr. Denninger will disagree, but I find this to be dangerous
and depressing thinking. A major strength of the Internet is the
ability for new services to come into existance when they're needed,
not several years later when a "nice clean requirement" has been
formulated, written down, approved, standardized, and poked at by a
layer or two of beaurocracy. In other words, the internet is strong
because it can evolve.

Existing firewalls threaten this evolution because they mix up the
notion of enforcing security with the notion of limiting
functionality. This -is- a serious threat. Dave's core argument, that
we should work to develop an architecture which can separate these
functions, seems to offer a useful way out.

John Wroclawski
MIT Lab for Computer Science
jtw@lcs.mit.edu

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 19:29:45 GMT
From:      werme@alliant.com (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <17008@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:

>Let me very strongly second what Marcus Ranum said about the need for
>firewalls.  No, I don't want to run one.  However, given the
>abominable state of host security, I have no choice.  You can blame
>software designers for not paying enough attention to the problem or
>you can blame the current state of software engineering, or you can
>blame lax administration by folks who are more interested in getting
>their own work done.

Hey, no one has mentioned retraining all the local users who use their
initials for a password!  Until we got on the Internet here I was
rather fond of my old password.  A little embarassed that it was on
the Robert T Morris short list, but my coworkers are pretty trustworthy.

I *was* somewhat more embarrassed when I discovered my old password was
on a machine here that did not use the yellow plague, but I think things
are under control now, thank you.
-- 
| A pride of lions               | Eric J Werme                 |
| A gaggle of geese		 | 77 Tater St			|
| An odd lot of programmers      | Mont Vernon NH  03057	|
| A Constitution of Libertarians | Phone: 603-673-3993		|

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 19:36:57 GMT
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

As far as I've seen, much of the problem with firewalls is not that
they exist, but that they are badly configured.  For instance, I've
seen firewalls that would allow "inside" users to telnet out, but they
couldn't rlogin out.  A good firewall should allow everything that is
permitted and nothing that is forbidden, and so improves security
without adding any additional burden to proper usage.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
What do you mean, *you're* a solipsist?

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 19:44:47 GMT
From:      Gary White
To:        comp.protocols.tcp-ip
Subject:   Re: satellite link file transfers

In article <1992Jul27.190345.22868@Arco.COM> Gary White <gwhite@arco.com>
writes:
>Hi-
>Between Texas and Alaska via a satellite -linked communications link, we 
>find that FTP goes awfully slowly.  Has anybody learned how to tune FTP,
>or come up with some other software, to go fast on a satellite link?
>
>Thanks-
>Gary White
>
More information:  this is with a T1 link with two RS/6000 560 machines
both running AIX 3.2;  FTP performance is similar to a 56Kb terrestial
hookup.



-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 92 19:49:43 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet Packets over Sun Router ??


In article <1992Jul24.195035.1@indyvax.iupui.edu>, harvey@indyvax.iupui.edu writes:
|>In article <1992Jul23.193824.15759@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
|>> Or WIN/TCP. The next release (called Pathway for VMS V1.0; don't ask why)
|>> also supports DECnet over IP.
|>
|>Is the method used compatible with the method used by MultiNet?

Yes, it is.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Monday, 27 Jul 1992 19:05:19 CET
From:      Karl Keyte <KKEYTE@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   SMTP mail


The SMTP has recently been removed at our site because of its well-known
security hole.

Does anyone have a mail protocol (IP based) which allows you to integrate
many different systems?  We have Suns, PCs, VAXes, IBM mainframes, all
running TCP/IP.

Any info. (directly to me: KKEYTE@ESOC.BITNET) would be very welcome.

Thanks,

Karl

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 1992 21:12:36 GMT
From:      cliff@garnet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

|>
|> >>I wish I had a transcript of Dave Clark's talk at the IETF last week.
|> >>He said some great things about firewall gateways and mailbridges, and
|> >>how they've essentially destroyed the whole purpose of having an IP
|> >>internet, and have forced a lot of us to use mail as a transport-level
|> >>protocol.
|>
|> Dave is usually correct, but as he thinks quite a bit more than many, and
|> says what he thinks, he is frequently not correct. Send him mail and ask
|> for a copy, or invite him to write. Perhaps he's been misstated in this
|> summary of his remarks.

Yes, I believe Dave Clark's points have been somewhat twisted in this
discussion.

What I thought I heard him say is that good host security is very important
because without it people are forced to use firewalls and mail relays.  It's
hard to argue this point, and Dave Clark most certainly did *not* criticize
anyone for using firewalls or mail relays.

The follow on point (which ji referred to), is that IP (and UDP/TCP and
the support infrastructure) was designed for end-to-end connectivity, so
firewalls and mail relays break the architectural model.  It's pretty hard
to argue with this also.

For a common example of the problems this creates, consider the DNS.
The DNS is designed so that all hosts get the same answer to the same
query.  This is a problem for people who have corporate internets hidden
from The Internet, because they often want the corporate machines to get
one set of info from the DNS and for machines on The Internet to get a
different set of info.  The most common example is MX records, of course.

	Cliff Frost
	UC Berkeley

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 21:51:51 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: satellite link file transfers

In article <1992Jul27.194447.23444@Arco.COM> Gary White writes:
>In article <1992Jul27.190345.22868@Arco.COM> Gary White <gwhite@arco.com>
>writes:
>>Hi-
>>Between Texas and Alaska via a satellite -linked communications link, we 
>>find that FTP goes awfully slowly.  Has anybody learned how to tune FTP,
>>or come up with some other software, to go fast on a satellite link?
>>
>>Thanks-
>>Gary White
>>
>More information:  this is with a T1 link with two RS/6000 560 machines
>both running AIX 3.2;  FTP performance is similar to a 56Kb terrestial
>hookup.

Do you have any idea what the TCP window size is on the RS/6000s?
Assuming a single satellite hop, that's about 1/2 sec. RTT.
This requires a window of 96KB at full T1 (24X64Kbps).  Since the best
you can do with TCP (without the large window option) is 64KB,
the T1 will max around 128KBps.  With a default window size of 4KB,
you should see about 8KBps (64Kbps).  This is close to what you appear
to be getting.

Art

KBps = KiloBytes/sec
Kbps = KiloBits/sec

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 92 22:54:02 GMT
From:      rickk@endeavor18.NoSubdomain.NoDomain (Rick Krull)
To:        comp.protocols.tcp-ip
Subject:   Cheap router S/W

I want to put simulate a poor to bad network for testing network devices.
My current thoughts run toward a router that I can reprogram to do drops,
duplication, etc.  This would leave me with native code on all other
devices, which is what I'm trying to test anyway.

I remember PCroute sometime back, that sounded fine, but I also don't
remember if source was part of the deal.

Rick Krull
Tektronix

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 1992 23:07:21 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <151os4INNm3n@agate.berkeley.edu> cliff@garnet.berkeley.edu (Cliff Frost) writes:
>The follow on point (which ji referred to), is that IP (and UDP/TCP and
>the support infrastructure) was designed for end-to-end connectivity, so
>firewalls and mail relays break the architectural model.  It's pretty hard
>to argue with this also.

I'll argue with it. Firewalls don't have to be designed to prohibit
all forms of end to end connectivity; good firewalls will allow you to
do things like set up outgoing TCP/IP links and not incoming ones. Its
thus possible to set up reasonable end to end communication for
certain services without opening yourself up too badly to the outside
world. Yeah, its possible to shanghai existing connections, but the
damage the bad guy can do is limited for most services.

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 00:38:39 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminology for firewalls (was Re: Firewall usage)

In article <1992Jul26.211639.29453@decuac.dec.com>,
  mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:


>Trusted application gateway - a software gateway for a given application,
>	such as a telnet "forwarder", or relay. Sendmail is a trusted
>	(or at least some versions) application gateway.

  The other terms were OK, but the term "trusted" usually refers to a
component believed not to compromise a multilevel security policy
(e.g. Bell-Lapadula).  The overloading of the meaning that the above
proposes is not helpful because it tends to confuse terms used in the
same community.

  I would suggest just using "application gateway" instead.

Ran
atkinson@itd.nrl.navy.mil

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 92 01:03:44 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

In article <JTW.92Jul27142002@pmws.lcs.mit.edu> jtw@lcs.mit.edu (John Wroclawski) writes:
>Dave [Clark's] second point is that perhaps it is time to rethink the core
>architecture of the internet (or its follow-on) to specifically
>-include- mechanism to separate organizational policy functions (such
>as authentication, logging, and access control) from the actual
>service functions running on the typical host.

Actually, I think this approach was (in embryonic form, at least)
suggested several years ago by Deborah Estrin, who developed the
concept of Visa protocols.  In this model, "border" routers pass
only those packets deemed allowable by an Access Control Server (ACS).
Instead of requiring each packet to pass through an ACS on the way
in or out of an organization, the end hosts get cryptographically-
sealed thingies (visas) to stick onto their packets.  This allows
a distributed implementation, but also allows the ACS to set whatever
policy is desired.  The downside is that the cryptographic stuff could
be rather costly, and the whole model depends on every external-access
host implementing the mechanism.   For details, see
    Deborah Estrin, Jeffrey C. Mogul, and Gene Tsudik.
    Visa Protocols for Controlling Inter-Organization Datagram Flow.
    IEEE Journal on Selected Areas in Communication 7(4):486-498, May, 1989.
I'm sure Dave knows about this stuff; Deborah did her dissertation at MIT.

>I suspect Mr. Denninger will disagree, but I find this to be dangerous
>and depressing thinking. A major strength of the Internet is the
>ability for new services to come into existance when they're needed,
>not several years later when a "nice clean requirement" has been
>formulated, written down, approved, standardized, and poked at by a
>layer or two of beaurocracy. In other words, the internet is strong
>because it can evolve.

Alas, while parts of the Internet can (and should) continue to follow
the "everything not forbidden is permitted" approach, which allows for
evolution, other parts have to follow the "everything not permitted
is forbidden" rule.  The powers-that-be at a company such as Digital
are not going to permit us to run arbitrary experiments across the
boundary between the nasty wide-open Internet and our soft, naive
internal network.  There's nothing intrinsically wrong with this; the
IETF doesn't require that everyone on the Internet experiment with a new
service before blessing it.  Once a new service is properly understood,
we can (if we so choose) cut a hole for it in the firewall.

From time to time, I (hidden behind a firewall) find Digital's policies
to be a major pain; I still don't use services such as WAIS because of
the extra effort involved.  But, I (and my coworkers) no longer spend
a significant part of our time either tracking down intruders, or
explaining to the corporate security types why they shouldn't shut down
our gateway complex.

-Jeff [who accepts the blame for a few of the firewalls out there]

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 01:09:21 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

>Hey, no one has mentioned retraining all the local users who use their
>initials for a password!

	Another excellent case for firewalls. I want those users on the
*in*side of the firewall, where my problem domain becomes simply one of
making sure that the 2 user accounts on my firewall system have good
passwords, rather than having to worry about all the users on 40,000
hosts in Digital.

mjr.

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 02:26:05 GMT
From:      mhw@warlord.UUCP (Michael H. Warfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Help wanted: Interlan Ethernet drivers

In <1992Jul23.161641.12328@bostech.com> weare@bostech.com (Ged Weare) writes:
>Well, I gotta say, in a pathetic attempt at fairness, that I had nothing but
>good service from both Interlan (Ooops, Racal-Datacom), and from NCM.  They
>did try hard to help me.  I talked to three or four different NCM people,
>including a technical guy.  They even called me back!  In fact, a supervisor
>called me back to ask if I'd been treated right.  I have to admit I was.

	Yeah, I heard from them pretty quickly after my first reply here.
I may have caught somebody on a bad day or something when I contacted them
a few months ago.  They had resonable explanations and were quite forthcoming
on details.  Gang, I really hope my second contact with NCM was more
representative of their level of support than my first.  If so, I'm
impressed.  They do seem to be concerned, interested, and helpful.

>As I said, still no unix.  The only un-explored avenue was that one of
>the NCM people said (or implied, or atleast I inferred) that the NP600
>might work in NI6510 (?) mode, as a dumb card.  That should not need
>bus mastering, so I plan to check it out.  

	Anybody figures out how to get that to work, I want to know.  However,
can it be made to support the higher interrupts.  The NI drivers I have
only support the 8 bit interrupts.  Main reason I wanted to use the cards
to begin with is for the interrupts on the 16 bit interface.  The processor
is actually much slower than my host processor, which is not CPU bound at
this time.  As a result, the intellegent NP card would actually slow network
traffic down.  But since I'm not network traffic bound either, that's not
much of a problem.  I just need more interrupts!   :-( ;-( :-(

	Mike Warfield
	mhw@warlord.uucp

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 02:28:42 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Re: Clemson University Packet Driver: I have one problem B-(.

 saty@ntc.togliatti.su writes:

>>I write some application ( TSR type ) based on Packet Driver
>>( Clemson University Engineering Comp Ops Version 9) and I have
>>one tragic problem. I can not send ethernet packets while
>>my receive handle works. How can I do it correctly?

The 'preferred' solution is to not send the packet during the upcall
but to schedule it for later. 

If you find 23 ms average delay acceptable, you can just transmit on
the next timer tick.  

If you want faster response, use the packet driver GET_INFO function
to ask the driver which hardware interrupt it generates.  Then chain
to that interrupt so it looks like this:

	pushf
	call dword  old_irq_handler	; will be the packet driver
	; now safe for us to do things
	jmp our_post_irq_handler

This will invoke your routine immediately after the packet driver
is done processing the interrupt, and you will have extremely small
delays between receipt of packets and your reply.


Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 92 03:32:16 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Clemson University Packet Driver: I have one problem B-(.

In article <AJOhJRg8RQ@ntc.togliatti.su> saty@ntc.togliatti.su writes:

SATY, mail to your return address above bounces.  I suspect that your
site is lacking a MX record for the Internet at large.  I have seen
this before for .su sites.

   I write some application ( TSR type ) based on Packet Driver
   ( Clemson University Engineering Comp Ops Version 9) and I have

You probably mean "Clarkson University", but even that is wrong
because Crynwr Software has purchased the copyright on the packet
driver skeleton.  The code remains freely copyable.

   one tragic problem. I can not send ethernet packets while
   my receive handle works. How can I do it correctly?

Please rephrase this and email it to me (I will summarize if anyone asks).
Your question is ambiguous that I can't tell what problem you're having.

   My ethernet card is 3C505.

Hmmm...  Be advised that the packet driver for that card is rather slow.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice   [ if mail bounces, forward it ]
Potsdam, NY 13676          315-268-9201 FAX     [ to uuadmin@uu.psi.com.      ]

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 12:38:20
From:      backman@ftp.com  (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: Help wanted: Interlan Ethernet drivers

In article <242@warlord.UUCP> mhw@warlord.UUCP (Michael H. Warfield) writes:

 >> >As I said, still no unix.  The only un-explored avenue was that one of
 >> >the NCM people said (or implied, or atleast I inferred) that the NP600
 >> >might work in NI6510 (?) mode, as a dumb card.  That should not need
 >> >bus mastering, so I plan to check it out.  

The NP600A is an intelligent card with a 80186 CPU and a 85286 Ethernet chip.
To talk to the net you need the 586.  Your host CPU cannot reach that 586.
The onboard 186 can make the 586 jump through hoops provided some code to drive
the 186 is downloaded into the on-board RAM.  the host talks to the card
through a rather odd combination of program IO, shared memory, and DMA.

You can make a NP600A act as a "dumb" card; the Netware server driver did that.
However it has a simple dispatch loop down on the card that moves stuff
back and forth between the chip and the host.  You also need a host-side
driver to talk to the board just the right way...

The software you are looking at has an old (1982-3'ish) OS called Comet
which is used to drive a protocol stack.  This allowed a complete
protocol stack to be shoved into the boards RAM and run on the 186 as opposed
to on the host.  As the 186 runs at 8 Mhertz; performance of this stack
will always be an issue.

You need 2-3 spec's out of Racal-Datacomm; the NP600 hardware manual; 
the NCX spec which describes the on-board OS, and the spec. which explains
how to write an NP600 driver.


Larry Backman
FTP Software


-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 09:35:15 GMT
From:      harbirk@ifi.uio.no (Harbir Singh Kohli)
To:        comp.protocols.tcp-ip
Subject:   internet connectivity in France and Germany


I am looking for public access to the internet in Germany and France
as my friend will be working at the French embassy in Bonn, and would 
like to stay in touch. I will be grateful for all leads.

thanks

kohli

Please reply to : singh%cxrl.decnet@thor.xraylith.wisc.edu, as I am 
posting this for her on the net. I will summarize if enough interest 
is there.

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 11:38:47 GMT
From:      eitan@wiscon.weizmann.ac.il (Shternbaum Eitan)
To:        comp.protocols.tcp-ip
Subject:   Help remote service query


I'm writing an application that need to preform a search for a service on a remote host cluster.

since the agent that initiates the call isn't bounded to the host cluster
it can't use YP/NIS.

Is there another way for doing this ?

Thanks in advance

Eitan Shterenbaum

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 13:21:17 GMT
From:      dorl@vms.macc.wisc.edu (Michael (NMI) Dorl)
To:        comp.protocols.tcp-ip
Subject:   wanted, traffic monitor with snmp access

I have a need for a ethernet monitor that would gather
statistics on all traffic to or from a given ethernet
address for IP traffic with a given IP network number. 
Information must be retrievable with snmp. 

What I have in mind would be something like a PC or a
Unix worskstation with an ethernet interface.  The PC
would spy on all traffic on the ethernet and would
select traffic to or from a given set of ethernet
addresses. It would examine the source and destination
IP numbers of this traffic for a set of IP network
numbers (IP addresses anded with a mask would be nice)
and accummulate in/out tarffic stats (bytes plus
packets) for each IP network number.   It would be 
great if the device made this information available via 
snmp router interface mib variables (each network would
be a kind of pseudo interface) but other snmp access 
would be acceptable.

The application is to measure the traffic passing
through a router for a set of IP network numbers. 

Is there such a thing?  If not, is there any software
available in source that might make it's developement 
easier?

Replies by email please.

Michael Dorl              (608) 262-0466  fax (608) 262-4679
dorl@vms.macc.wisc.edu    MACC / University of Wisconsin - Madison
dorl@wiscmacc.bitnet      1210 W. Dayton St. / Madison, WI 53706

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 15:10:37 GMT
From:      alfonso@mtecv2.mty.itesm.mx
To:        comp.protocols.tcp-ip
Subject:   Information about PCRoute


  I'm sending this information cause I received a mail requesting some information about PCRoute, but I lost the address of that person. I hope he read this.

  PCRoute is a public domain software (at the moment I don't remember the node from which I got it), runs on PC's with a localtalk card and an ethernet card. The main problem I see with this product is that does not provide the KIP protocol in order to assign and IP address to the Macintoshes that connect with it.

  Alfonso

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 15:36:14 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <DRW.92Jul27143657@jordan.mit.edu>, drw@jordan.mit.edu (Dale R. Worley) writes:
> As far as I've seen, much of the problem with firewalls is not that
> they exist, but that they are badly configured.  For instance, I've
> seen firewalls that would allow "inside" users to telnet out, but they
> couldn't rlogin out.  A good firewall should allow everything that is
> permitted and nothing that is forbidden, and so improves security
> without adding any additional burden to proper usage.

There are a number of problems with that notion.  For one thing, what
you suggest is often impractical.  To use your example, how can I
characterize, at the router level, a legal rlogin packet?  About all I
can say is that the outside port number in one direction is 513, and
the inside port number is something less than 1024.  But when such a
packet floats by, the router has no way of knowing that that's really
rlogin.  The *real* definition is that the connection was initiated
from the inside.  Otherwise, the packet could be from a connection
initiated *from* port 513 on a dedicated attacker's machine, and to
some service on an inside machine.  But routers don't keep track of
connections, they look at individual packets.

Higher-level gateways, such as the one we run, can do what you say.
We've consciously decided not to support rlogin for two reasons.
First, in general we don't think that address-based or name-based
authentication is secure, and -- as a matter of principle -- we won't
ask people to trust us when we won't trust them in that regard.  The
second problem is the nature of our gateways.  All outbound connections
from AT&T come one of a very few machines (at the moment, exactly two,
I believe).  We can't vouch for the uniqueness of userids -- there
might be another smb, somewhere within the company, who would have the
same privileges as I would when doing an rlogin through the gateway.
That isn't acceptable.  For that matter, we don't keep track of the
trust level of every internal machine; if you saw an rlogin attempt
from us claiming a userid of ``root'', you'd have no way of knowing if
that was root on a great gronking huge UTS machine in one of our comp
centers, or root on an MS/DOS laptop.  I suppose we could munge the
username field on the rlogin messages, to include the inside host name;
however, that would demand more knowledge of the application protocol
than our gateway currently has.  (We run a circuit-level gateawy.  A
true application gateway, such as DEC's, could do that more easily, I'd
guess.)

UDP applications are even more problematic.  We'd love to support
``talk'', or have higher-level access to Archie.  And we haven't
given up; we have a number of ideas on how to improve our gateways.
We *don't* want gateways -- but we're very certain we need to have them.


		--Steve Bellovin

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 15:36:35 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

[[Too many articles to follow up on individually -- I do work instead
of reading news (for a change) and suddently there's a flamewar that
no firewall will stop (I know, bad pun)]]

I'll probably follow the suggestion offered and write a "Firewalls
Considered Harmful" paper. Meanwhile, here  are some points:

* I'm not advocating that companies should allow uncontrolled access
to their networks -- that would be stupid.

* A firewall is no excuse for lax internal security. To wit:

  - In a large organization, there are bound to be "bad guys" (either
    through malice, negligence, or sheer stupidity) inside the
    organization as well. No firewall is going to protect you against
    those. 

  - A firewall only protects you against *known* external threats. 

  - If your internal network is insecure, you are vulnerable to anyone
    who can get physical access to it. Today this involves tapping
    ethernet cables, but tomorrow it may just involve dropping by with
    a laptop with a wireless interface. I have a vested interest in
    seeing wireless LANs  take off -- I don't want t hem stifled
    because of security concerns.

  - Think of the Maginot Line.

* The network should switch bits and enforce routing policies -- not
  cover up for insecure applications.

* It should not be the job of the millions of system administrators to
  patch known holes -- the vendors should be doing that. There is
  simply no excuse for vendors shipping us insecure code. (Is it true
  that SunOS is still distributed with /etc/hosts.equiv containing a
  single '+"? Why do we still have login programs that only accept
  eight-character passwords, password files that are publicly
  readable, things like NIS that allow uncontrolled access to their
  information, etc? At least we don't get sendmail shipped with the
  debug option turned on any more.

* Having firewalls reduces the urgency (that is, the pressure on the
  vendors) of patching those security holes. It's a vicious cycle.

* We've seen analogies such as putting locks on the front door rather
  than each individual room, and that it's perfectly acceptable
  capitalist behavior to put a firewall gateway in front of your
  network. I claim that this is far from being capitalistic; you're
  beeing communist inside, and hiding behind an Iron Curtain.

* The argument "naive users and administrators don't want to deal with
  security" has been kicked around. I say that the systems should be
  secure from the beginning. I hope it's not too late to do that.

* There are a lot of other security concerns in networked systems that
  should be addressed, that have nothing to do with firewalls. If
  those concerns are dealt with, firewalls will stop making. For
  example, I don't want anyone with the root password to be able to
  read my files, or log onto my machine and spy on what I'm doing.
  That includes the head of the security department, as well as the
  guy down the hall that I just had an argument with and wants to kill
  my files in revenge. While the latter is probably unavoidable, the
  former can be dealt with with proper cryptographic techniques. 

Finally,

* Firewalls are an easy solution to a very real and very serious
  problem. My point, if a bit idealistic, is that we should *fix* the
  problem, rather than patch its manifestations.

* Security, like good manners, starts at home. 

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 92 15:43:42 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: ATT 3B2 Hop Counter


In article <1992Jul27.161124.17031@wdl.loral.com>, wrl@wdl1.wdl.loral.com (Bill Lewandowski) writes:
|>We have a user with a ATT 3B2 computer. We think we have a problem
|>with data packets taking more than 16 hops through the NSFNET
|>T3 network and the MILNET and the 3B2 is ignoring them because >16.
|>
|>Anyone know how I can increase the hops to a normal 32 or so.
|>
|>I don't have the computer here so I can't read any manuals so
|>any help is really appreciated.

In the system IP configuration file '/etc/master.d/ip' there is a
definition:

	IP_TTL = 0xf

Change this to whatever hexadecimal value you deem neccesary and
reboot using '/etc/system' to rebuild the kernel.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 16:06:18 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: wanted, traffic monitor with snmp access

In article <1992Jul28.133252.19798@macc.wisc.edu>, dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) writes:
|> I have a need for a ethernet monitor that would gather
|> statistics on all traffic to or from a given ethernet
|> address for IP traffic with a given IP network number. 
|> Information must be retrievable with snmp. 
|> 
|> What I have in mind would be something like a PC or a
|> Unix worskstation with an ethernet interface.  The PC
|> would spy on all traffic on the ethernet and would
|> select traffic to or from a given set of ethernet
|> addresses. It would examine the source and destination
|> IP numbers of this traffic for a set of IP network
|> numbers (IP addresses anded with a mask would be nice)
|> and accummulate in/out tarffic stats (bytes plus
|> packets) for each IP network number.   It would be 
|> great if the device made this information available via 
|> snmp router interface mib variables (each network would
|> be a kind of pseudo interface) but other snmp access 
|> would be acceptable.
|> 
|> The application is to measure the traffic passing
|> through a router for a set of IP network numbers. 
|> 
|> Is there such a thing?  If not, is there any software
|> available in source that might make it's developement 
|> easier?
|> 
|> Replies by email please.
|> 
|> Michael Dorl              (608) 262-0466  fax (608) 262-4679
|> dorl@vms.macc.wisc.edu    MACC / University of Wisconsin - Madison
|> dorl@wiscmacc.bitnet      1210 W. Dayton St. / Madison, WI 53706

How about a box that supports the RMON MIB for SNMP?  RMON, which
stands for Remote Network Monitoring, is detailed in an RFC as a
standard way for an SNMP Agent to present network traffic information
to an SNMP Manager.  This RFC is available in the archie systems and
is quite comprehensive.  I don't think that too many hosts are going
to implement it though.  Remember that a node on a LAN that is doing
a good job of monitoring can be hit with a lot of data.  A PC that
is in promiscuous mode can usually not do anything else.

WARNING!! PRODUCT RECOMMENDATION!!  Hit n if you don't want to see it.



That is why I would recommend you look at something like the NAT
EtherMeter or Remote EtherMeter for $1495 and $1795 respectively
(no, I am not affiliated with NAT nor do I have any relationship
with them).  NAT can be reached at (800)543-8887.  Though I am
sure others are implementing RMON, NAT is the only product I 
know of that is currently available.  They also offered us a 30
day trial if I could get a no cost PO cut to assure return of the
box.  I have not used this box myself but they have a good 
reputation.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 18:05:04 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

In article <Bs3vCz.K13@cs.columbia.edu>, ji@cs.columbia.edu (John Ioannidis) writes:
> ...
> * A firewall is no excuse for lax internal security. To wit:
>   - In a large organization, there are bound to be "bad guys" (either
>     through malice, negligence, or sheer stupidity) inside the
>     organization as well. No firewall is going to protect you against
>     those. 

True, but irrelevant.  The only effective means to protect against bad
insiders are administrative.  Technical solutions to administrative
problems are always less effective.

Most murders and non-sexual assualts are committed by people acquainted
with the victim.  Do you conclude that you need dead bolts on your
bedroom doors?  Must you sleep alone or with an awake, armed guard?
There are far more external network damage and attacks than internal.

Open networks are no fun to break.  A "disgruntled employee" is not
going to "break into" a system to "erase critical files" if those files
are properly achived.  Such a bad guy is not going to use the network
to get even, but will do commit any of the many more familiar, easier
to commit, harder to detect forms of white collar crime.  (You are
talking about criminal acts.)

"Security" does nothing to protect against negligence or stupidity,
because those who who are acting stupid or negilgent almost always have
all of the passwords, keys, and badges.  It is reckless to
unnecessarily run as root, because of the danger of typo's, but that
has nothing to do with "security.'

Fasist internal security systems generally exist for internal political
reasons, to entertain and justify SystemAdministators.  There are
development organizations where the programmers are not allowed to know
the root passwords of their workstations, but all such organizations I
have seen have been less then unproductive.

>   - A firewall only protects you against *known* external threats. 
> 
>   - If your internal network is insecure, you are vulnerable to anyone
>     who can get physical access to it. Today this involves tapping
>     ethernet cables, but tomorrow it may just involve dropping by with
>     a laptop with a wireless interface. I have a vested interest in
>     seeing wireless LANs  take off -- I don't want t hem stifled
>     because of security concerns.

Maybe you should find other vested interest, if your wireless stuff
requires that machines on local networks be protected.

>   - Think of the Maginot Line.
> 
> * The network should switch bits and enforce routing policies -- not
>   cover up for insecure applications.

So, you have locks on your bedroom door, to protect you against your
relatives.

> * It should not be the job of the millions of system administrators to
>   patch known holes -- the vendors should be doing that. There is
>   simply no excuse for vendors shipping us insecure code. (Is it true
>   that SunOS is still distributed with /etc/hosts.equiv containing a
>   single '+"? Why do we still have login programs that only accept
>   eight-character passwords, password files that are publicly
>   readable, things like NIS that allow uncontrolled access to their
>   information, etc? At least we don't get sendmail shipped with the
>   debug option turned on any more.


So you think you can sell an obligatorily secure system?  Like the SCO
C2 UNIX?  Where the customer cannot run with open doors?  Wrong.

Systems should come in the box with a reasonable amount of security.
That does not imply everyone must or should or be required to use it.


> * Having firewalls reduces the urgency (that is, the pressure on the
>   vendors) of patching those security holes. It's a vicious cycle.

Wrong.  We vendors can fix holes since we generally have source for our
products, and we generally feel more pressure to fix holes for
customers than you can imagine, but we run with firewalls.

> * We've seen analogies such as putting locks on the front door rather
>   than each individual room, and that it's perfectly acceptable
>   capitalist behavior to put a firewall gateway in front of your
>   network. I claim that this is far from being capitalistic; you're
>   beeing communist inside, and hiding behind an Iron Curtain.

So, you have locks on your bedroom door, but not on your front door.
Well, from the stories I've read, that makes a certain amount of sense
for New York City.

> ...
> * Firewalls are an easy solution to a very real and very serious
>   problem. My point, if a bit idealistic, is that we should *fix* the
>   problem, rather than patch its manifestations.
> 
> * Security, like good manners, starts at home. 

Having good security available is not the same thing as being required
to use it.  It is good that locks and safes are available for those
who need them.  It would be bad and stupid to expect everyone to
use case-hardened bars on their first floor windows, just because
they are necessary in New York.


Vernon Schryver,  vjs@sgi.com

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 18:58:32 GMT
From:      ridder@zso.dec.com (Hans Ridder)
To:        comp.protocols.tcp-ip
Subject:   Problem with ASCII mode FTP

I have a question regarding the use of CR/NUL sequences in ASCII mode
FTP transfers.  One particular PC implementation of FTP, when sending,
is converting a bare CR (intending to "overprint") into a CR/NUL.  When
received by the ftpd on Ultrix, the NUL is not stripped.  This NUL then
causes a problem when the file is printed, but that's another issue.

Checking the FTP RFC, it says that ASCII mode should use the TELNET NVT
protocol.  The TELNET RFC says that bare CR's should never appear in the
data stream, that when sending they should be converted to CR/NUL, and
back to local format on receive.  The FTP RFC talks quite a bit about
various aspects of CR/LF processing, but never mentions CR/NUL.

From all this reading, I conclude that the Ultrix ftpd (and possibly
ftp) is broken, and should be stripping the NUL.  Checking the source
code revealed there is code to strip the NUL, but it is #ifdef'd out.
Are all BSD derived implementations the same?

Should this ftpd be stripping the NUL following the CR, or not?  I say
yes, however I wanted to check with all you for any folklore and
opinions on the issue.  Thanks!

-hans
-- 
  Hans-Gabriel Ridder				Digital DECwest Engineering
  ridder@rust.zso.dec.com			Bellevue, Washington, USA
  {pacbell,pyramid,uunet}!rust.zso.dec.com!ridder

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 92 19:13:56 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

In article <Bs3vCz.K13@cs.columbia.edu>, ji@cs.columbia.edu (John Ioannidis) writes:
[lots of reasons why firewalls are a bandaid, and how we should fix the
real problem, including getting vendors to ship secure systems]

John is, of course, absolutely right (except where he called firewall
users ``communist'', which may or may not be true (the Internet reaches
lots of places these days...), but is irrelevant and seemed to be
intended as an insult).  Vendors should ship secure systems, internal
security measures are necessary in any event, and users and system
administrators should do a better job.  I strongly suspect that every
firewall developer is fighting all of those battles, and many more.  I
certainly do -- when I worry about TCP/IP security, for example, it's
because AT&T uses it internally, and wants to secure its internal
networks and products.

The problem with John's conclusions are that I have to live in the real
world, which includes people who *must* run old versions of various
operating systems, users who don't pick good passwords, and
administrators who are careless.  I can't do anything about any of
those things, except to exhort people to do better.  In the mean time,
I try to keep the dragons away from their doors, while hoping for a
better world tomorrow.


		--Steve Bellovin

P.S.  It occurs to me that John is also wrong when he says that firewalls
only defend against known problems.  That's precisely wrong.  Fixing holes
only works until some chracker finds a new hole.  A good firewall keeps out
anything but a very few services.  The network behind the firewall can
be attacked, but only through bugs in either those few services or in
the firewall itself.

While host security can -- and should -- be improved, I'm quite dubious
that it can ever be made good enough.  Never mind bad administration --
I don't think the state of the art of software engineering is up to the
task.  I take it as axiomatic that all large programs have bugs, and
that therefore security servers will have security bugs.  Yes, good design
can minimze the odds and/or the impact -- but I doubt that the holes
can ever be eliminated completely.  Looking at it another way, firewalls
are precisely an example of good software engineering practice -- they're
(presumably) small, simple pieces of code, and hence are much less likely
to have bugs.

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 20:22:11 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Stopping only incoming TCP connections (was: Firewall usage)

smb@ulysses.att.com (Steven Bellovin) writes:

>The *real* definition is that the connection was initiated
>from the inside.  Otherwise, the packet could be from a connection
>initiated *from* port 513 on a dedicated attacker's machine, and to
>some service on an inside machine.  But routers don't keep track of
>connections, they look at individual packets.

I was under the impression that if you filter all the SYN packets from
one direction that aren't SYN ACKs, bingo, you can't initiate any
incoming TCP connections.  Nice and stateless. The only flaw is that
implementations that seperately ACK the initiating SYN and then send
their own SYN won't be able to connect, but they are rare. Connections
could still be hijacked by various mechanisms, but they can't be
initiated, and there is a limited amount of damage a hijacker can do.
I was also under the impression that some recent routers will actually
let you do this trick.

Am I egregiously wrong about this?


--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 20:24:48 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: wanted, traffic monitor with snmp access

 dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) writes:
>|> I have a need for a ethernet monitor that would gather
>|> statistics on all traffic to or from a given ethernet
>|> address for IP traffic with a given IP network number. 
>|> Information must be retrievable with snmp. 
>|> 
>|> What I have in mind would be something like a PC or a
>|> Unix worskstation with an ethernet interface.  The PC
>|> would spy on all traffic on the ethernet and would
>|> select traffic to or from a given set of ethernet
>|> addresses. It would examine the source and destination
>|> IP numbers of this traffic for a set of IP network
>|> numbers (IP addresses anded with a mask would be nice)
>|> and accummulate in/out tarffic stats (bytes plus
>|> packets) for each IP network number.   It would be 
>|> great if the device made this information available via 
>|> snmp router interface mib variables (each network would
>|> be a kind of pseudo interface) but other snmp access 
>|> would be acceptable.
>|> 
>|> The application is to measure the traffic passing
>|> through a router for a set of IP network numbers. 
>|> 

Look around dutepp0@et.tudelft.nl [130.161.144.65], some 
excellent work at the Delft University in Holland has
produced some wonderful freeware applications which do
network monitoring and are SNMP queriable.  Some of the
applications run under DOS, others on Unix. 

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 1992 22:36:21 GMT
From:      Gary White <gwhite@arco.com>
To:        comp.protocols.tcp-ip
Subject:   Re: satellite link file transfers

Well, it has turned out that we had two problems.  First, 
some bridge and  router setup problems.  Secondly, the buffer 
size for TCP/IP on the RS/6000 was too low by default.  RS/6000's 
have a command "no" for network options that allows the 
"tcp_sendspace" and "tcp_recvspace" settings to be adjusted;  
changing from the default 16K to 56K improved performance
from 25KBytes/s to 70KB/s.

There are still some things to check for better performance, 
but this is a big step up from yesterday's 5KB/s.

Thanks to all who wrote in!!!

-Gary

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 00:04:00 +0000
From:      vadim@cix.compulink.co.uk (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Cc:        vadim@cix.compulink.co.uk
Subject:   No subject

I want to thank everrybody for helping me to get Van Jacoboson's artcicles
ont TCP/IP optimisations

-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France



-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1992 00:15:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

In article <1992Jul28.010344.9414@PA.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes:
>Alas, while parts of the Internet can (and should) continue to follow
>the "everything not forbidden is permitted" approach, which allows for
>evolution, other parts have to follow the "everything not permitted
>is forbidden" rule.

I'm the maintainer of part of our firewall, and I unfortunately have to
agree that in many circumstances (like ours), the second rule is necessary.

We have developers here implementing new protocols all the time, such as
inter-machine diagnostics and special-purpose file access.  With the first
rule, these would suddenly become accessible to anyone on the Internet, and
crackers could wreak havoc with our development systems (or maybe even
destroy or get access to proprietary data).  The second rule is more
limiting, but it's the only thing that works when the environment on this
side of the firewall is very open.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 01:00:41 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: Econfig question

In article <18162.2a742998@ecs.umass.edu> geray@ecs.umass.edu writes:
>Hello Netters,
>Do I have to Econfig a Novell file server if I use ipxodi and odipkt and
>PD applications ? Or Does the file server not need to be Econfiged ?
>Thank you in advance.
>
>Okan Geray
>
	If the FRAME type in the NET.CFG file is in the form

		Frame ETHERNET_II
		Frame ETHERNET_802.3
		PROTOCOL IPX 0 ETHERNET_802.3

then you don't need to ECONFIG the server. If however you have already ECONFIG
it, just change the PROTOCOL statement to: PROTCOL IPX 8137 ETHERNET_II

- Carl Beame
beame@bws.com
 

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 02:15:34 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <92209.190519KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET> writes:
>
>The SMTP has recently been removed at our site because of its well-known
>security hole.

  Would you like to enlighten us as to the nature of this "well known
security hole".

  It is well known that email can be forged.  Most people don't consider
this a security problem, although it may present an identification
problem.  If you consider email forgery a security hole, then I presume
you have also shut off all paper mail, which can just as easily be
forged.


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 29 Jul 1992 09:25:48 CET
From:      Karl Keyte <KKEYTE@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

  14rticle <1992Jul29.021534.6708@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil
Rickert) says:
>
>In article <92209.190519KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET>
>writes:
>>
>>The SMTP has recently been removed at our site because of its well-known
>>security hole.
>
>  Would you like to enlighten us as to the nature of this "well known
>security hole".
>
>  It is well known that email can be forged.  Most people don't consider
>this a security problem, although it may present an identification
>problem.  If you consider email forgery a security hole, then I presume
>you have also shut off all paper mail, which can just as easily be
>forged.
>

& that's not a security hole?  It is if you want to believe mail that you
receive.  Paper mail is usually signed.  The point is, SMTP is stupidly
simple (as we all know) in it's "authentication".  My question still
stands.

Karl

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 11:41:11 GMT
From:      jessea@homecare.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Finding out what machines are on a network.

I'm just starting to program some tcp/ip and I have a question
(actually two).  I once had a program that would go out and tell you
what machines were talking on the network and would give you their
hostnames.  Sort of like ping for the entire network.  My first
question is how is this done?  I'd like to write my own version (just
as an exercise) and I figured it wouldn't be very hard to do.  My
second question is does anyone know where I can get the above program?
I'd like to get it to see how that particular programmer implemented it.
-- 
      Jesse W. Asher                                   Phone: (901)762-6000
                         Varco-Pruden Buildings
	      6000 Poplar Ave., Suite 400, Memphis, TN  38119
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 13:36:10 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

In article <Bs3vCz.K13@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
     - A firewall only protects you against *known* external threats. 

Our firewall is set up conversely: it permits only traffic that's
strongly suspected (notice I didn't say "known") not to be a threat.
It's configured to give our internal users maximal access to the rest
of the world, to give the rest of the world the sort of access to our
net and hosts that we want them to have, and to ease our burden in
managing systems from dozens of vendors.

I'm not a lazy or unconscientious system/network administrator, I'm a
wily one.  This strategy reduces the size of my problem domain, makes
my network manageable with limited staff resources, and lets me go
home at night to my wife and kids when I otherwise spent evenings in
the office, chasing crackers.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 13:56:17 GMT
From:      hontanon@a.cs.wvu.wvnet.edu (Ramon J. Hontanon)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   HELP: TCP/IP Software for an HP9000

Hello All!

I am in charge of an ethernet LAN that includes an HP9000. When it came
time to obtain TCP-IP software for the HP9000, all they could find was
a package called FUSION, from Network Research Corp. It works OK, but
we run PWS 3.1 to accomodate some flow cytometry software that we use,
and Fusion only runs on PWS 3.2.2, so we have to reboot from a Bernoulli
that contains PWS 3.2.2 everytime we wanna use FUSION.
 
My question is the following:

Does anybody know of any other TCP-IP package for the HP9000 that runs
on the old PWS 3.1? I realize this is doing things backwards, but our 
cytometry software only gets upgraded every three hundred years or so.

Both E-mail or posts would be great.

Thanks in advance

Ramon J. Hontanon
hontanon@cs.wvu.wvnet.edu
ramon@fdavax.cber.nih.gov

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 14:36:35 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast - Maximum message size


	The default BSD code prohibits fragmenting broadcast packets. You
can disable that (with kernel sources) by just #ifdef'ing out the check;
we've run it that way here for years with no noticeable performance problem.
	Diffs below for 4.3 Tahoe sources; replace "PUCC" with a symbol
defined for your site, or change the name to something more descriptive.

*** NEW ip_output.c	Wed Jul 29 09:33:06 1992
--- OLD ip_output.c	Mon Jun 12 23:08:33 1989
***************
*** 156,166 ****
--- 156,170 ----
  			error = EACCES;
  			goto bad;
  		}
+ 
+ #ifndef	PUCC
  		/* don't allow broadcast messages to be fragmented */
  		if (ip->ip_len > ifp->if_mtu) {
  			error = EMSGSIZE;
  			goto bad;
  		}
+ #endif	/* NOT PUCC */
+ 
  	}
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 14:54:11 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   The Protocol


Evolution dictates:
SGMP (simple gateway management protocol)
SNMP (simple network management protocol)
SMP (simple management protocol)
SP (simple protocol)
P (protocol)

but then what?
:-)

jon 
p.s. of course, we should expect divergent species, such as
MP (managment protocol)
and
M (management)

but since these are neither simple, nor necessarily protocols, they
serve no useful function.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 15:10:14 GMT
From:      G.Pavlou@cs.ucl.ac.uk (George Pavlou)
To:        comp.protocols.tcp-ip
Subject:   Re: The Protocol


> Evolution dictates:
> SGMP (simple gateway management protocol)
> SNMP (simple network management protocol)
> SMP (simple management protocol)
> SP (simple protocol)
> P (protocol)
>
> but then what?

Then you realise all these evolutions were only simple with regard to their
name: complexity was added in each evolution cycle as is definitely the case
with the SGMP -> SNMP -> SMP transition.

So you start from CMIP which is where you are aiming at even if you don't want
to admit and add complexity accordingly:

CMIP (complex management information protocol)
(O)CMIP ((overly) complex management information protocol)
...


George

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 15:11:21 GMT
From:      zonjic@plains.NoDak.edu (Radivoje Zonjic (CE))
To:        comp.protocols.tcp-ip
Subject:   Looking For a Package (posting for a friend)



Dear Netters,

I have just received a request for help from a friend at Belgrade
University (YU) who is currently not hooked up on any net. I would
really appreciate any useful hint.

Rade



-------------------------------------------------------[forw. message]--
Dear networkers,
 
 
     I am interesting in PD TCP/IP for Unix. I would like to connect our 
old unix machines to rest of a local network using SLIP. I have some 
experience with Unix variants of ka9q TCP/IP. They are very pretty, but 
intended only for multitasking, without multiuser capability. I have 
heard something about CMU TCP/IP, but I find it only for VAX/VMS. 
     Now I am still looking for TCP/IP that would satisfy the following 
requirements: 
 
- Public Domain TCP/IP for Unix sysV 3.1 (sysV is important)
- full multiuser support of a telnet and ftp consumers
- telnet, FTP and finger servers
- elementary routing support
 
     I will very appreciate any information related to the software 
name, authors, capabilities, availability and experience in 
exploitation. 
 
 
Sincerely
 
Dr.Bozidar Radenkovic,
Department of information systems, University of Belgrade.
 

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 15:23:51 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <92211.092548KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET> writes:
>
>& that's not a security hole?  It is if you want to believe mail that you
>receive.  Paper mail is usually signed.

And you are enough of an expert on handwriting that you can check the
signatures of all the mail you get and know its really from the
person, eh? Keep reference signatures for everyone you correspond
with, too, I assume. Good trick. I can forge most people's signatures
with about 2 minutes of practice, not significantly more effort than
it takes to forge SMTP mail. Paper mail is just as insecure as EMail,
if not more so because almost anyone can forge paper mail but it takes
someone who groks SMTP to forge email.

>The point is, SMTP is stupidly simple (as we all know) in it's
>"authentication".

Relying on paper signatures is also stupidly simple. Signatures are
not there on legal documents as an identity verification, you know,
but as proof of concent; if you sign (and its shown that you indeed
were the one who signed) its taken to mean that you understood you
were entering in to a contract. If you want identity verification you
are supposed to go to a notary public.

>My question still stands.

Look, if you want real authentication, you need to go to public key
cryptography. You won't find any other technique that really works,
and you aren't going to find PEM implementations that interoperate on
your platforms. Fine, shut off SMTP and deprive your users of a
valuable service if you like, but you aren't doing them any favors.
--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 16:30:24 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <92211.092548KKEYTE@ESOC.BITNET>, KKEYTE@ESOC.BITNET (Karl Keyte) writes:
> 
>   14rticle <1992Jul29.021534.6708@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil
> Rickert) says:
>>
>>In article <92209.190519KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET>
>>writes:
>>>
>>>The SMTP has recently been removed at our site because of its well-known
>>>security hole.
>>
>>  Would you like to enlighten us as to the nature of this "well known
>>security hole".
>>
>>  It is well known that email can be forged.  Most people don't consider
>>this a security problem, although it may present an identification
>>problem.  If you consider email forgery a security hole, then I presume
>>you have also shut off all paper mail, which can just as easily be
>>forged.
>>
> 
> & that's not a security hole?  It is if you want to believe mail that you
> receive.  Paper mail is usually signed.  The point is, SMTP is stupidly
> simple (as we all know) in it's "authentication".  My question still
> stands.

It's hardly a security hole in SMTP. It is a nearly universal problem in
networking and common to virtually all protocols. This INCLUDES paper mail. I
get at least a dozen letters and "official memos" a day of which probably one a
week is signed.

SMTP is rapidly becoming the lingua franca of electronic mail. With the
deployment of MIME, it is likely to displace X.400 in short order. To remove
SMTP because of the possibility of forgery is cutting off ones node to spite
ones face. It's not going away and it doesn't look like anything will replace
it in the next several years. And, because it works so well, noone is even
looking at a replacement (except OSI folk who are pushing X.400).

Now, lets try to look at fixing the problem instead of shooting the messenger!
The only real way to do this is PEM. There are a number of RFCs on the subject
(1113, 1114, and 1115. PEM allows mail to be "signed" digitally to preclude
forgery. It also allows encryption to gaurantee privacy. PEM is available
commercially from at least one source, Trusted Information Systems. While this
is not exportable, I know there are foreign sources which eliminate the
silliness of the US Government.

Please note that all of this still uses SMTP.

And, since the vast volume of mail requires neither privacy or authentication,
I doubt that most E-Mail will use privacy options for some time to come. So
cutting off SMTP merely cuts off your users from 99% of the world. If my sysop
did this in the name of security, I'd wring his neck. (No possibility of this
since I am the sysop.) It's simply stupid.

And, while you're at it, ban paper mail too. After all, it works when it's not
signed, so it may be forged!

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

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

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 16:55:46 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <92211.092548KKEYTE@ESOC.BITNET> Karl Keyte
<KKEYTE@ESOC.BITNET> writes:
>& that's not a security hole?

No.  It is an authentication hole.  It's not as if it give anybody
unauthorized access to your machine, or prevent others from accessing
your machine.

>It is if you want to believe mail that you receive.
>Paper mail is usually signed.  The point is, SMTP is stupidly
>simple (as we all know) in it's "authentication".  My question still
>stands.

SMTP is does not provide any authentication.  Neither does paper mail.
It is quite easy to forge both, but they are the best that we have
right now.  How do you know that the signature in paper mail is cool
or not?  Some people that you communicate with all the time maybe, but
just a random piece of mail?  SMTP is the same way.  Its message have
a weak "signature" on them in the form of Received: lines.

You might want to investigate using an RFC931 server.  It will make it
harder to forge the mail.

You might also want to see what the state of the art in PEM is these
days.  PEM doesn't prevent forgeries, but it does have a much stronger
digitial signature coded into the message itself.

There is absolutely NOTHING that you can do that will prevent all
kinds of forgeries.  There are things that you can do to make it
harder to forge mail, but NOTHING is 100% secure.

Warner
-- 
Warner Losh		imp@Solbourne.COM
Interview Horror Story #882: "It's pretty informal around here.
Thursdays are clothing optional.."

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 17:32:35 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

Karl> == Karl Keyte <KKEYTE@ESOC.BITNET>

 Karl> The SMTP has recently been removed at our site because of its
 Karl> well-known security hole.

 Karl> Does anyone have a mail protocol (IP based) which allows you to
 Karl> integrate many different systems?  We have Suns, PCs, VAXes, IBM
 Karl> mainframes, all running TCP/IP.

This is rather silly, since you have single-user machines; IP isn't
going to be secure anyway, unless you have something fairly strong for
authentication/encryption (Kerberos or the like).  SMTP mail can be
forged; there are some measures to detect (not prevent) forgeries, and
(eventually) there will be PEM.  Until then, teach people to be wary,
and take sociopolitical sanctions against people you catch forging
email.

Technical solutions to political problems are generally not solutions...
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
   ``The First Amendment is often inconvenient.  But that is besides the
  point.  Inconvenience does not absolve the government of its obligation
         to tolerate speech.'' --Justice Anthony Kennedy, in 91-155

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 92 17:52:38 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

I'd like to jump in here and ask a couple of questions:

What is MIME?

Secondly, I fail to see why forgery is not considered a breach of security.

Next, saying that mail doesn't require privacy is just caving in to the fact that
I can't get it with SMTP.

A good mail system should include authentication, privacy, arbitrary file 
attachments, acknowledgement, directory look-ups, and mailing lists just to 
name a few features.  

Now, SMTP doesn't preclude any of this:  the user interfaces for SMTP
are just crude.  The only part that SMTP really interferes with is that
everything (as far as I know and correct me if I'm wrong) must be transmitted in a
text format.  That puts undue stress on the mailers to encode everything.

What has been people's experience with the NYSERnet X.500 trial and did they 
come up with any decent user interfaces with, for example, an integrated
directory look up?

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 18:53:02 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <92211.092548KKEYTE@ESOC.BITNET>, KKEYTE@ESOC.BITNET (Karl Keyte) writes:
> >>
> >>The SMTP has recently been removed at our site because of its well-known
> >>security hole.
> >
> >  It is well known that email can be forged.  Most people don't consider
> >this a security problem, although it may present an identification
> >problem.  If you consider email forgery a security hole, then I presume
> >you have also shut off all paper mail, which can just as easily be
> >forged.
> >
> 
> & that's not a security hole?  It is if you want to believe mail that you
> receive.  Paper mail is usually signed.  The point is, SMTP is stupidly
> simple (as we all know) in it's "authentication".  My question still
> stands.


If you do not use SMTP, you will not get a lot of mail.

If you require the other end of TCP/IP or UDP/IP connections over the
Internet to be really authenticated, you can get by with a very low
speed link.

There is PEM, Privacy Enhanced Mail, which involves digital signatures
to authenticate mail.  It is based on SMTP, so you might find it
unacceptible.


Vernon Schryver,  vjs@sgi.com

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 19:18:29 GMT
From:      smj@beta.lanl.gov (Stephen M. Johnson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Addressing in Large Networks

I work for a large Department of Energy facility (325 square miles, 23,000 
people) with a large IP population. Most of the machines running IP are
personal computers, split evenly between IBM PCs and Macs. We have a great 
deal of trouble maintaining an accurate host database because PCs are easily
moved, etc. We are struggling internally with how to manage IP addresses
so that we maintain an accurate database and consume minimal people resources
doing so. We have discussed dynamic allocation of addresses and server-based
allocation using RARP or BOOTP. What are other organizations with large
IP populations doing to solve this problem? 

If there seems to be sufficient interest I'll summarize to the net.

thanks

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
 smj@lanl.gov			| Aiken, South Carolina
-- 

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
smj@lanl.gov			| Aiken, South Carolina

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 1992 08:00:59 -0700
From:      tsudik@pollux.usc.edu (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   Firewall usage

In article <Bs3vCz.K13@cs.columbia.edu> ji@cs.columbia.edu
(John Ioannidis) writes:
 
  >* A firewall is no excuse for lax internal security. To wit:
  >  - In a large organization, there are bound to be "bad guys" (either
  >    through malice, negligence, or sheer stupidity) inside the
  >    organization as well. No firewall is going to protect you against
  >    those.

True. But it is safe to assume that there is a much larger and much more
"varied" population of "bad guys" outside than in. 

  >  - A firewall only protects you against *known* external threats.

This is not a convincing point. Any security measure whether implemented in
a firewall gateway or in an end-system is going to protect you only against
*known* attacks.

  >* The network should switch bits and enforce routing policies -- not
  >  cover up for insecure applications.
  > 
  >* Having firewalls reduces the urgency (that is, the pressure on the
  >  vendors) of patching those security holes. It's a vicious cycle.
  > 
  >* We've seen analogies such as putting locks on the front door rather
  >  than each individual room, and that it's perfectly acceptable
  >  capitalist behavior to put a firewall gateway in front of your
  >  network. I claim that this is far from being capitalistic; you're
  >  being communist inside, and hiding behind an Iron Curtain.

I see. So, to be a true capitalist I would have to padlock the doors to
individual rooms (end-systems or hosts) and let the sh*t fly in the corridors,
right? 

I'm afraid that no matter how secure you make the hosts, the problem of 
securing internal links will remain. You are assuming that the only purpose of
firewalls is to protect otherwise vulnerable hosts. 
What about the rest of internal network resources: links, bridges and even 
the network interfaces of the very same hosts? 

Without firewalls, no matter how secure the OS, 
your workstation can be bombarded and flooded with meaningless garbage
traffic from outside of your organization. This can render your 
workstation unusable. Moreover, valuable communication resources, e.g., 
critical internal links, can be similarly flooded with trash from the outside 
thus denying service to legitimate internal users.

I don't think many people (me included) believe that firewalls are elegant. 
They constitute an ugly solution to an even uglier problem.

Cheers,

Gene

gts@zurich.ibm.com

-- 
----------------------
Gene Tsudik, Member FDIC

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 20:26:00 GMT
From:      elee@nssdca.gsfc.nasa.gov (Erik Lee)
To:        comp.protocols.tcp-ip
Subject:   Wanted: source code of internetworking with TCP/IP by comer


Hi! Fellows,

    Does anybody know where can I get source code of Internetworking 
    with TCP/IP Volume II, written by Douglas E.Comer and 
    David L.Stevens.

    Your help will be much appreciated.

Erik Lee


-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 20:44:20 GMT
From:      nqueipo@euler.Berkeley.EDU (Nestor Queipo)
To:        Pnews,comp.protocols.tcp-ip
Subject:   Network programming problem!




I would like to hear suggestions about how to solve the following 
problem.

	A local process has a list of machines in Internet at
	its disposal. The local process should be able to execute
	processes remotely and monitor their execution. The remote
	processes should be able to interrupt the local process
	under different circumstances (e.g termination, error,etc).
	Finally, when any of the remote processes is finished it
	should provide the local process with data result of its 
	execution through files or any other convenient way.

In short, I am looking for a strategy that would allow me to asynchronously
control the execution of remote processes. What do you think would be the
simplest way of doing this? I do not need real-time interaction over TCP/IP.

Thanks in advance,

Nestor

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 21:10:35 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail


In article <1992Jul29.175238.20719@mmm.serc.3m.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:

>I'd like to jump in here and ask a couple of questions:
 
>What is MIME?

A multimedia mail standard that uses SMTP transport.

>Secondly, I fail to see why forgery is not considered a breach of security.

A breech of security is when someone can gain unauthorized access to
your host; the sendmail debug verb that the Morris worm took advantage
of was a security hole. A breech of authentication is what forgery
permits, in which you cannot know who sent you a message. As has been
pointed out repeatedly, this is also a problem with paper letters. As
has also been pointed out, PEM and similar systems are the proper way
to address this problem.

>Next, saying that mail doesn't require privacy is just caving in to
>the fact that I can't get it with SMTP.

Privacy is a third issue entirely, different from host security and
authentication. To assure privacy, no method will work other than
cryptography, period. The internet is not and cannot be secure in its
transmitions; with hundreds of thousands of miles of line, its
impossible to keep people from tapping some of it. This is NOT an SMTP
failing.

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 21:30:07 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <1992Jul29.175238.20719@mmm.serc.3m.com> ccg@tcdsp1.mmm.com
("Charles Ganzhorn") writes:
>Secondly, I fail to see why forgery is not considered a breach of
>security.

It all hinges on how you define security.  It is an authentication
issue, not a security one, in my opinion.

>Next, saying that mail doesn't require privacy is just caving in to
>the fact that I can't get it with SMTP.

I never said that mail doesn't require privacy.  I just said that it
was easy to forge and that you shouldn't expect e-mail to be private.

>A good mail system should include authentication, privacy, arbitrary file 
>attachments, acknowledgement, directory look-ups, and mailing lists just to 
>name a few features.

All of these features can be had with the underlying SMTP transport.
You get authentiation and some privacy from PEM.  You can attach
arbitrary files with things like MIME or mailtool.  Acknowledgement
has been hacked into sendmail, even though there are many serious
"security" problems with it.  The VRFY and EXPN commands in the SMTP
can be used for directory lookup.  There are tons of mailing lists out
there, so that point is easy.

Warner
-- 
Warner Losh		imp@Solbourne.COM
Interview Horror Story #882: "It's pretty informal around here.
Thursdays are clothing optional.."

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 21:53:33 GMT
From:      chrisc@ramrod.lmt.mn.org (Chris Cox)
To:        comp.protocols.tcp-ip
Subject:   Re: Stopping only incoming TCP connections (was: Firewall usage)

In article <1992Jul28.202211.14029@shearson.com> pmetzger@snark.shearson.com (Perry E. Metzger) writes:

>I was under the impression that if you filter all the SYN packets from
>one direction that aren't SYN ACKs, bingo, you can't initiate any
>incoming TCP connections.  Nice and stateless. The only flaw is that
>implementations that seperately ACK the initiating SYN and then send
>their own SYN won't be able to connect, but they are rare. Connections

That would eliminate your users from starting ftp data sessions (wouldn't 
it?).

Chris

   Chris Cox  W0/G4JEC                               chrisc@ramrod.lmt.mn.org
   LaserMaster Technologies                          Tel: (612) 944-6069
   7156 Shady Oak Road                               Fax: (612) 944-5544
   Eden Prairie, MN  55344

           ----- For mail of a more social nature, please use -----

     chrisc@moron.vware.mn.org  -or- chrisc@biggus.g4jec.tcman.ampr.org


-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 92 21:58:52 GMT
From:      dricejb@drilex.dri.mgh.com (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   How to control permissions on incoming FTP?

Is there any way, using the standard ftpd which one might receive with
Ultrix or SunOS, for example, to control the permissions on incoming files?
I just did a sample put (from a PC), and the file was stored with
permisions of rw-rw-rw- (wide open).

We're developing an application where we need to accept files via ftp.
(Not anonymous; they're merely coming from another computer with limited
TCP capabilities.)  I'd like these files not to be world-readable.  I
know I can limit permissions on their directory, but can I limit
the permissions on the files themselves?

I can't find anything in any manual that describes how this might be done.

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 22:23:19 GMT
From:      miller@tgv.com (Vagrant)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?


In article <1992Jul24.142554.12716@emr1.emr.ca>, fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:
#
#In article <CKD.92Jul20140814@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
#>David> == David Barr <barr@darwin.psu.edu> 
#>
#> David> And I thought it was sick when the College of Engineering
#> David> decided to use DECNET to encapsulate IP packets so they could
#> David> have one virtual ethernet spanning buildings.  (It was
#> David> apparently the only solution.  I still can't believe it)
#>
#>Sickest of all was the "proposal" to put IP packets in MIME-format
#>multimedia messages.  That gives you IP over UUCP, even over a
#>multiple-hop UUCP path.
#>
#
#How about IP-over-SLIP-over-DECNETsethost-over-X.25?
#Somebody here is actually using that in a production network!

I once set up an IP-over-X.25-over-DECNET-over-IP link.  The X.25
router was located in Melbourne and we are in Santa Cruz, California.
Round-trip-time was something like 2 seconds on a good day.  Sometimes
it took up to three minutes.  I would have been faster to call up
and have someone read the datagram to you.

Currently we are working on IP-over-email using the MIME standard.
Thank god for the slow-start algorithm.  The thing should be useable
with batch FTP.  Telnet's right out.  The three-way handshake is a
royal pain.  This is defintely a back-burner project.

-bruce


-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jul 1992 23:32:56 GMT
From:      leb@Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

dricejb@drilex.dri.mgh.com (Craig Jackson drilex1) writes:
>Is there any way, using the standard ftpd which one might receive with
>Ultrix or SunOS, for example, to control the permissions on incoming files?
>I just did a sample put (from a PC), and the file was stored with
>permisions of rw-rw-rw- (wide open).

I don't know about Ultrix or SunOS, but on our Silicon Graphics running IRIX,
ftpd has a "-u" switch for specifying the default umask for files.  It defaults
to 022 (group and worls-readable), but it can be changed in the
/usr/etc/inetd.conf entry for ftpd.

You may also want to check out the ftpd program available from 
wuarchive.wustl.edu.  I haven't used it myself but I hear it has a lot of 
whiz-bang features.
--
-- Lee E. Brotzman                    Internet:  leb@hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB@GIBBS
-- NASA Goddard Space Flight Center

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 00:57:16 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail

In article <1992Jul29.175238.20719@mmm.serc.3m.com>, ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
> I'd like to jump in here and ask a couple of questions:
> 
> What is MIME?

If memory serves it is Multimedia Internet Mail Extensions.

It's the new multi-media mail proposal. It provides the capability to include
non-textual material in a mail message in a standardized way so that it may be
properly handled. This includes sound, images, and a variety of other things.

> Secondly, I fail to see why forgery is not considered a breach of security.

It depends on your definition of "breach of security". It does not provide any
access to your operating system of files to unauthorized users nor can it
allow the compromise of data on your system. In government terms (and I suspect
others), that is what a breach of security is. Mail, itself, cannot breach
security. It can do other things like embarrass people who believe everything
they read, though. And, in doing so might cause a LOT of trouble.

> Next, saying that mail doesn't require privacy is just caving in to the fact that
> I can't get it with SMTP.

Once again, this is NOT a function of SMTP! That's like saying that you will
not allow the postman to deliver mail because some of it may be forged.
 
> A good mail system should include authentication, privacy, arbitrary file 
> attachments, acknowledgement, directory look-ups, and mailing lists just to 
> name a few features.  

Would be nice. So why don't you sit down and write it?
 
> Now, SMTP doesn't preclude any of this:  the user interfaces for SMTP
> are just crude.  The only part that SMTP really interferes with is that
> everything (as far as I know and correct me if I'm wrong) must be transmitted in a
> text format.  That puts undue stress on the mailers to encode everything.

MIME takes care of this.
 
> What has been people's experience with the NYSERnet X.500 trial and did they 
> come up with any decent user interfaces with, for example, an integrated
> directory look up?

Works quite well. We use QUIPU here.

And, on a side note, while RFC931 identification is not a bad thing, it's of
limited value on E-Mail due to gatewaying. I refuse to call it an
authentication server because it is NOT. It's trivial to fool...if you know
it's there. It works fairly well for the moment because it's still unusual and
forgers are not expecting it.

This does not mean I am opposed to 931 and its descendents, but it should not be
though of as a real security measure, only a tool.

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

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

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 01:46:14 GMT
From:      hak@alf.cooper.edu (Jeff Hakner)
To:        comp.protocols.tcp-ip
Subject:   Re: ATT 3B2 Hop Counter

in article <1992Jul28.154342.17716@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) says:
> Sender: reece@crash.eco.twg.com (Reece R. Pollack)
> Nntp-Posting-Host: eco.twg.com
> Reply-To: reece@eco.twg.com (Reece R. Pollack)
> Organization: The Wollongong Group (East Coast Operations)
> References:  <1992Jul27.161124.17031@wdl.loral.com>
> Date: Tue, 28 Jul 92 15:43:42 GMT
> Lines: 23
> 
> 
> In article <1992Jul27.161124.17031@wdl.loral.com>, wrl@wdl1.wdl.loral.com (Bill Lewandowski) writes:
> |>We have a user with a ATT 3B2 computer. We think we have a problem
> |>with data packets taking more than 16 hops through the NSFNET
> |>T3 network and the MILNET and the 3B2 is ignoring them because >16.
> |>
> |>Anyone know how I can increase the hops to a normal 32 or so.
> |>
> |>I don't have the computer here so I can't read any manuals so
> |>any help is really appreciated.
> 
> In the system IP configuration file '/etc/master.d/ip' there is a
> definition:
> 
> 	IP_TTL = 0xf
> 
> Change this to whatever hexadecimal value you deem neccesary and
> reboot using '/etc/system' to rebuild the kernel.

You also need to run mkboot.  I suggest this procedure:

1) cp /unix /unix.sav   #or some other meaningful name
2) edit /etc/master.d/ip
3) mkboot /boot/IP
4) shutdown -i5 -g0 -y
5) when you reach firmware mode, enter the firmware password
6) when asked which program to run, type /etc/system
7) hit return for the device number prompt
8) The system will come up.  A new /unix will be generated.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 10:05:16
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

barmar@think.com (Barry Margolin) writes:
>Others have already suggested getting public ftpd source and adding a
>umask() call.
>
>Another solution is to run ftpd via a script that first sets the umask and
>then execs the real ftpd.  I believe the standard BSD telnet just inherits
>its umask from its parent.

We have been using a "umask 022" as one of the first lines in /etc/rc on
our Suns for quite a while. Works like a charm.

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

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 05:23:40 GMT
From:      dyer@spdcc.com (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

In article <51690@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson drilex1) writes:
>Is there any way, using the standard ftpd which one might receive with
>Ultrix or SunOS, for example, to control the permissions on incoming files?
>I just did a sample put (from a PC), and the file was stored with
>permisions of rw-rw-rw- (wide open).
>
>I can't find anything in any manual that describes how this might be done.

Use the source, Luke.  FTP source is available everywhere, and
the change is trivial (a judiciously placed umask call).

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 30 Jul 1992 09:28:50 EDT
From:      <PVJQC@CUNYVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Using SLIP on Sparcstn

I recently downloaded `slipware' from one of the archives.  It includes
Slip for different Sun OS releases, tip with slip option, and some patches.
I was able to configure Slip as per the instructions for Sun Sparcstn2
running 4.1.1 but do not have any further info. on making proper use of it.
I basically have a `sliplogin' program which has a syntax of
`sliplogin <dest. addr> <local Addr>' .  I understand that Slip is
meant for point to point communication over serial lines.  I am not
sure how I exactly use this?  What I wish to do is to configure this Sparc2
for dial-in on /dev/ttya with slip, and then to configure other Suns, PCs
at remote sites (like faculty homes) for dialing out using slip so
that telnet/ftp would be possible from the home PCs (running CUTCP), and
Suns to the Sparc2 in the Dept.
Any suggestions or any documentation you can refer me to?
Thanks a lot.
Prashant Joshi

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 06:10:16 GMT
From:      martillo@stars.clearpoint.com (Joachim Martillo)
To:        comp.protocols.tcp-ip
Subject:   IP Directed Broadcast

On reading RFC 1009 Requirements for Internet Gateways, one finds in
section 4.4 on page 34.  An Internet gateway is permitted, but not
required, to filter out directed broadcasts destined for any of its
locally-connected networks.

If a networks gateways do not filter IP broadcasts and that network
has active loops in its subnet topology, and if someone extern to the
network sends a directed broadcast to that network with a TTL of 255,
the target network could easily suffer a major broadcast storm.

Such a storm would seem a bad thing.  Maybe I am missing something,
but perhaps filterning directed broadcasts should be obligatory rather
than optional.

Joachim Carlo Santos Martillo Ajami

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 06:22:42 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Addressing in Large Networks

In article <1992Jul29.191829.13780@newshost.lanl.gov>
   smj@beta.lanl.gov (Stephen M. Johnson) writes:
>I work for a large Department of Energy facility (325 square miles, 23,000 
>people) with a large IP population.         ...             We have a great 
>deal of trouble maintaining an accurate host database because PCs are easily
>moved, etc. We are struggling internally with how to manage IP addresses
>so that we maintain an accurate database and consume minimal people resources
>doing so.

Our facility is much smaller; about 150 people, 200 nodes. Still enough
to be a hassle to keep the host maps and name server files current.

We run a promiscuous monitor program for an hour each morning and again
in the afternoon and evening. This maintains a list of all IP addresses
and ethernet addresses that have been seen on our backbone. It then
proceeds to supplement this with information from DNS whenever
available.

Here is a sample of the database:

# Host Tracker Database hostdata updated 29-Jul-92 19.26 on spectrum
#
02-CF-1F-40-06-40 : 131.143.16.20  :29-Jul-92 19.23 :
	CMCVAX.CMC.COM : VAX-11/750:Unix 4.3BSD:MIS - In Computer Room:Ip:
08-00-20-00-77-C0 : 131.143.16.30  :29-Jul-92 19.23 :
	Amos.CMC.COM : Sun-3/280:SunOS 4.1.1:Brian Fanning:LmIp:
AA-00-04-00-03-04 : 131.143.16.39  :29-Jul-92 19.23 :
	THUMPER.CMC.COM : MicroVAX 3800:VMS:Carol Boyce:Ip:
08-00-86-00-08-E7 : 131.143.16.40  :23-Jul-92 16.40 :
	ILP.CMC.COM : Imagen-5320:?:Brian Fanning:Ip:
02-CF-1F-50-06-14 : 131.143.16.80  :29-Jul-92 09.49 :
	THUMPER.CMC.COM : MicroVAX 3800:VMS:Carol Boyce:Ip:
02-CF-1F-90-51-40 : 131.143.16.200 :29-Jul-92 16.09 :
	CIRRUS.CMC.COM : TranServer:TranServer:M Kunz:IpBtp:

Etheraddress : IPaddress : last-seen :
	DNSname : Hardware : Software : Owner : Flags

Separate files track local hosts (i.e. the ethernet address is real) and
remote hosts (i.e. they are behind IP routers). The program also logs
usage statistics and some exceptions:

29-Jul-92 19.00 My name is spectrum - IP address 131.143.16.1
Loaded hostdata    216 (0 remote, 216 local) 303 TRIE entries
Loaded host.mac    297 (3 remote, 294 local) 320 TRIE entries
Loaded host.rmt   2265 (1971 remote, 294 local) 2343 TRIE entries
Initializing translation tables, please wait... done
open(/dev/nit) returned 3, errno=0
+++19.00 Saw new remote host 128.111.246.4   via gateway HINGE.CMC.COM
---19.01   4701 frames  4873920 bytes (40/2558 M/B) 6.59% saturation
---19.02    778 frames   144645 bytes (44/3242 M/B) 0.21% saturation
+++19.05 Saw new remote host 128.2.209.227   via gateway HINGE.CMC.COM
---19.11   1483 frames   325784 bytes (45/3284 M/B) 0.46% saturation
---19.17   1318 frames   306619 bytes (48/3772 M/B) 0.44% saturation
***19.24 Exiting: No new stations seen in  5 minutes
Total frames:  44344 - Total bytes =  22552620 - Max saturation = 6.59
B/M-c frames:   1000 - B/M-c bytes =     67696 - Max b/m-c bytes =  3772
Total hosts   2267 (1973 remote, 294 local) 2352 TRIE entries
Identified IP 128.2.209.227   name TEZUKA.REST.RI.CMU.EDU
Major traffic from 128.2.209.227   (null) (21.0%)
Identified IP 128.93.8.8      name chenas.inria.fr
Identified IP 128.111.246.4   name IRIS4.metiu.ucsb.edu
Identified IP 128.117.140.3   name unidata.ucar.edu
Identified IP 128.174.5.98    name vmd.cso.uiuc.edu
Major traffic from 129.192.64.25   FENNEL.ACC.COM (17.4%)
Major traffic from 131.143.16.39   THUMPER.CMC.COM (20.3%)
Major traffic from 131.143.18.40   TANAFIEL.CMC.COM (9.5%)
Major traffic from 131.143.23.16   JAMMER.CMC.COM (6.5%)
Major traffic from 131.143.23.90   bigsky.CMC.COM (26.4%)
*** 29-Jul-92 19.26 All done!! (Pmon3 rev 1.26)

The log file is reviewed periodically. This provides a good sanity check
on the network. The cumulative database is used to generate /etc/host
files as well as forward and reverse DNS zone files, complete with
HINFO data. When adding new hosts, we generally assign them an IP
address, plug them in, harvest their MAC address and manually add the
HINFO fields. We then regenerate the DNS zones, using perl scripsts that
parse the database.

The remote host file gives us a rough idea of who we exchange mail with;
it is also good for browsing ... I know there's an FTP server at IBM,
but I can't remember its name ... when users have questions.

Finally, the timestamp helps us periodically harvest IP addresses that
have fallen into disuse as labs have been reconfigured.

If I had your size of network, I would expand this with some modules to
collect the information remotely via RMON devices, and tag each host
with the ethernet segment number it lives on, rather than a local/remote
bit. This is of course a monumental task.

their ethernet address
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC (Rockwell Digital Systems)	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-5503		TeleFAX:   +1-805-968-8256

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 1992 06:32:53 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

In article <51690@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson drilex1) writes:
>Is there any way, using the standard ftpd which one might receive with
>Ultrix or SunOS, for example, to control the permissions on incoming files?
>I just did a sample put (from a PC), and the file was stored with
>permisions of rw-rw-rw- (wide open).

Others have already suggested getting public ftpd source and adding a
umask() call.

Another solution is to run ftpd via a script that first sets the umask and
then execs the real ftpd.  I believe the standard BSD telnet just inherits
its umask from its parent.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 07:09:25 GMT
From:      dyer@spdcc.com (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

In article <1582elINN9mf@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>Others have already suggested getting public ftpd source and adding a
>umask() call.
>
>Another solution is to run ftpd via a script that first sets the umask and
>then execs the real ftpd.  I believe the standard BSD telnet just inherits
>its umask from its parent.

That's fine, but it affects all incoming FTP tasks.  Some of your
users might not like such a decision being made for them.  I wanted
a version of anonymous FTP which allowed deposition of files into
a writable 'incoming' directory, but the resulting files would not
be generally accessible to anonymous FTP browsers.  I didn't want
to affect anyone other users of ftp.

Until I made the (simple) change to ftpd, I maintained a writable
directory accessible via anonymous FTP.  One day I was amused (surprised
is too strong a word) to discover that said directory was being used as
a world-wide rendezvous point for porno GIF seekers and providers: there
was even a convention for creating hidden directories in the incoming
directory, one for requests and one for replies.  Files named like
I_want_wandanude.gif in the requests directory would cause wandanude.gif
to appear in the reply directory, and so on.  Ingenious, but not on
my bandwidth...

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 15:55:26 GMT
From:      gmarzot@mitre.org (G. S. Marzot)
To:        comp.protocols.tcp-ip
Subject:   Re: satellite link file transfers

In article <1992Jul28.223621.12550@Arco.COM>, Gary White <gwhite@arco.com>
writes:
> 
> Well, it has turned out that we had two problems.  First, 
> some bridge and  router setup problems.  Secondly, the buffer 
> size for TCP/IP on the RS/6000 was too low by default.  RS/6000's 
> have a command "no" for network options that allows the 
> "tcp_sendspace" and "tcp_recvspace" settings to be adjusted;  
> changing from the default 16K to 56K improved performance
> from 25KBytes/s to 70KB/s.
> 
> There are still some things to check for better performance, 
> but this is a big step up from yesterday's 5KB/s.
> 
> Thanks to all who wrote in!!!
> 
> -Gary
> 

This discussion has been very helpful. I do have one follow-up question.

Is there a simple ROM way to calculate TCP/IP throughput given say
bit rate = 256Kb/s, transmit/receive delay = 250 msec and varying buffer
size.
This would assume a fairly solid link and no other traffic. Thanks for any
help. -GSM


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 16:12:14 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Directed Broadcast

In article <11132@crackers.clearpoint.com> martillo@stars.clearpoint.com (Joachim Martillo) writes:
>On reading RFC 1009 Requirements for Internet Gateways, one finds in
>section 4.4 on page 34.  An Internet gateway is permitted, but not
>required, to filter out directed broadcasts destined for any of its
>locally-connected networks.
>
>If a networks gateways do not filter IP broadcasts and that network
>has active loops in its subnet topology, and if someone extern to the
>network sends a directed broadcast to that network with a TTL of 255,
>the target network could easily suffer a major broadcast storm.
>
>Such a storm would seem a bad thing.  Maybe I am missing something,
>but perhaps filterning directed broadcasts should be obligatory rather
>than optional.
>
>Joachim Carlo Santos Martillo Ajami

Get the latest Router Requirements Draft from any internet-drafts server.
This will eventually replace RFC1009.

"All Subnets" broadcasts have been "deprecated" and multicasts encouraged.
The rule has become: if an IP packet arrives via media broadcast, it is
never forwarded (ignoring IP Multicast for the moment).  Thus if an All
Subnets broadcast is forwarded until it reaches the first subnet of the
target network, it may be exploaded there, but will not propagate to the
remaining subnets.  This is especially important with new routing protocols
which allow discontiguous subnets.

Art

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 16:57:26 GMT
From:      wls@cray.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Re: How to control permissions on incoming FTP?

In article <1992Jul30.070925.23754@spdcc.com>, dyer@spdcc.com (Steve Dyer) writes:
> Until I made the (simple) change to ftpd, I maintained a writable
> directory accessible via anonymous FTP.  One day I was amused (surprised
> is too strong a word) to discover that said directory was being used as
> a world-wide rendezvous point for porno GIF seekers and providers: there

We've also had this problem.  There's a way to restrict this usage by using
directory permissions.  We have an incoming directoy that's writeable by
anonymous ftp only, but readable by everybody except anonymous ftp.  We also
have the usual pub directory, readable by everyone and writeable by everyone
except anonymous ftp.  An "ls -l" looks like this:

-rw-r--r--  1 root         1592 Mar 23 17:44 Policy
dr-xr-xr-x  2 root          512 Oct 24  1991 bin
dr-xr-xr-x  2 root          512 May 13 20:12 etc
d-wxr-xr-x  2 ftp           512 Jul 17 14:54 incoming
dr-xrwxrwt 20 ftp          1024 Jul 28 09:11 pub

So, an anonymous ftp user can drop something off in "incoming" that everyone
on our system can read, but other anonymous users can't see it.  They can
only see the things that our users place in the "pub" directory.

This worked fine until one of our vendors (I won't mention Convex by name :-)
changed "ftpd" permissions taking away world read on newly written anonymous
files.  This "security" change makes anonymous ftp pretty useless, except as a
dumping ground described above, since nobody on our system can read the files.
Thanks guys.  :-)

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 18:16:09 GMT
From:      wohlenbe@inter-tel.com (Greg Wohlenberg)
To:        comp.protocols.tcp-ip
Subject:   SLIP


Does anyone know of a public-domain implementation of SLIP that
is available somewhere?

Please send e-mail since I don't normally read this newsgroup.
I will post a summary of responses.

Thanks,

Greg Wohlenberg          ||  Voice: (602) 961-9000
Inter-tel, Inc.          ||    Fax: (602) 961-1370
6505 W. Chandler Blvd.   || E-mail: wohlenbe@inter-tel.com
Chandler, Arizona, 85226 ||         wohlenbe%intertel.uucp@asuvax.eas.asu.edu

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 1992 19:54:39 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Directed Broadcast

In article <11132@crackers.clearpoint.com> martillo@stars.clearpoint.com (Joachim Martillo) writes:
>If a networks gateways do not filter IP broadcasts and that network
>has active loops in its subnet topology, and if someone extern to the
>network sends a directed broadcast to that network with a TTL of 255,
>the target network could easily suffer a major broadcast storm.
>
>Such a storm would seem a bad thing.  Maybe I am missing something,
>but perhaps filterning directed broadcasts should be obligatory rather
>than optional.

This is why they are allowed to filter them out.  They aren't required to
filter them because they don't cause a problem on non-subnetted networks
(e.g. directed broadcasts to a subnet of a subnetted network), networks
without active loops, or networks where the routers compute a spanning tree
to prevent broadcast loops (cisco Brouters have this option).  Why actively
prohibit something when there are reasonable ways of making use of it?

Routers that support forwarding of directed broadcasts should have a way to
disable it, so that networks where it will cause storms will not be
susceptible to this.  It should probably even be off by default.  But
network administrators should be able to enable it if they want.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 1992 20:03:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage

In article <l7g11bINNlib@pollux.usc.edu> tsudik@pollux.usc.edu (Gene Tsudik) writes:
>I see. So, to be a true capitalist I would have to padlock the doors to
>individual rooms (end-systems or hosts) and let the sh*t fly in the corridors,
>right? 

I think this analogy to a home and rooms is very poor.  The same people
live in a home and the rooms, so it's usually reasonable to have the locks
just on the main doors.  Then again, my parents did have a lock on their
bedroom door.

But I think better analogies would be to apartment buildings, dormitories,
or hotels.  It's usual to have locks on the individual apartments or rooms.
But whether there's a lock on the main entrance, or perhaps a doorman
screening visitors, is a matter of policy.  Some people prefer
high-security apartment buildings with a doorman.  Hotels, on the other
hand, often don't have much entrance security, so you should lock your
door if you want any expectation of privacy.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 20:34:27 GMT
From:      drw@euclid.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <17011@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
   About all I can say is that the outside port number in one
   direction is 513, and the inside port number is something less than
   1024.  But when such a packet floats by, the router has no way of
   knowing that that's really rlogin.  The *real* definition is that
   the connection was initiated from the inside.  Otherwise, the
   packet could be from a connection initiated *from* port 513 on a
   dedicated attacker's machine, and to some service on an inside
   machine.  But routers don't keep track of connections, they look at
   individual packets.

I haven't studied the matter, but I believe that the more
sophisticated firewalling routers actually *do* track connections.  At
least, I've heard claims about what some routers could do that I
couldn't figure out how to do without tracking connections.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Anything that's not nailed down is mine.  Anything I can pry loose is not
nailed down.

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 21:19:32 +0000
From:      mt@kram.demon.co.uk (Mark Turner)
To:        comp.protocols.tcp-ip
Subject:   Null packet driver?

Is there such thing as a null packet driver?

I have a PC running Windows. ka9q lives in a DOS window and quite
happily answers the phone to recive incoming PPP sessions from my office.

How do I access an IP based process in another DOS session? I can telnet
into the ka9q session and could go through this session to a packet driver,
but I can't use a conventional packet driver from the same end twice.

One (horrible) solution is to go out of a serial port and back into another
one, having separate SLIP drivers on different interrupts for each serial port.

There must be a better way. I'd appreciate any ideas. What I'd really
like is for someone to say "Oh, just use the XYZ null packet driver, which
is available for ftp from...." but I s'pose that's just a dream. :-(

Here's hoping...

Mark.

/\/\ark Turner                               Demon Systems / Demon Internet
Office: mark@demon.co.uk (+44 81 349 0063)       42 Hendon Lane, London
Home: mt@kram.demon.co.uk (+44 831 823 212)         N3 1TT, England

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 92 21:40:26 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP mail


In article <92209.190519KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET>
writes:
>
>The SMTP has recently been removed at our site because of its well-known
>security hole.

In article <1992Jul29.021534.6708@mp.cs.niu.edu>,
	rickert@mp.cs.niu.edu (Neil Rickert) says: 
% Would you like to enlighten us as to the nature of this "well known
% security hole".
%
%  It is well known that email can be forged.  Most people don't consider
% this a security problem, although it may present an identification
% problem.  If you consider email forgery a security hole, then I presume
% you have also shut off all paper mail, which can just as easily be
% forged.

In article <92211.092548KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes:
>& that's not a security hole?  It is if you want to believe mail that you
>receive.  Paper mail is usually signed.  The point is, SMTP is stupidly
>simple (as we all know) in it's "authentication".  My question still
>stands.

Karl,
  It is MUCH EASIER to forge BITNET mail than SMTP, so SMTP is not any
worse than what you all apparently continue to use.  Use the Privacy
Enhanced Mail (PEM) specifications and build a mail envelope that
provides the security properties you need outside of the SMTP issue.
SMTP is probably not a problem per se, so the PEM approach makes
sense.  The RFCs are online at the usual archive sites.

  Ran
  atkinson@itd.nrl.navy.mil

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 1992 21:47:33 GMT
From:      gmarzot@mitre.org (G. S. Marzot)
To:        comp.protocols.tcp-ip
Subject:   Sun HSI/S card

Just a query to see if anyone has used the Sun HSI/S high speed serial
interface S-Bus card. any comments, sample code, rumors, anything.
Thanks in advance,
GSM

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 00:05:43 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Firewall analogies (was Re: Firewall usage)

>I think this analogy to a home and rooms is very poor.

	I really don't think there *IS* a particularly good analogy.

	Part of the problem is that firewalls and their implementation
is not merely a technical problem. There is a whole set of "management"
issues that usually need to be addressed. There are whole sets of CYA
issues that need to be addressed, which don't necessarily improve the
security of the network, but definitely improve the network manager's
claim to showing diligence in securing the network.

	In the consulting work I've done for DEC (setting up firewalls)
I've run across various combinations of these issues. Compared to them,
the actual details of locking things down tight are real simple. Every
time I run into these discussions, I try to come up with an analogy for
Internet security - it's pretty hard. Part of the problem is that unlike
a house, you don't always know that you've been robbed; people don't
break into your house and steal a *COPY* of your gun collection, and
vanish after shaving (or somehow magically cleaning) all the rugs to
hide their footprints. This makes the whole thing harder to understand,
especially for someone who is not used to modern networked computing.
You get strange policies like: "it must be impossible to export data
out over the network"  - never mind that a fistful of DATs is easier
to hide.

mjr.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 00:09:24 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

drw@euclid.mit.edu (Dale R. Worley) writes:

>I haven't studied the matter, but I believe that the more
>sophisticated firewalling routers actually *do* track connections.

	I prefer to use a somewhat different approach in general. First
you determine the services that your users have a clear business need
for. Then you develop an application gateway that "knows" that protocol
and can give you decent access control, logging, and piggy-back blocking.
This is much more secure (in my opinion) since you preserve the "that which
is not expressly permitted is prohibited" doctrine and you can incorporate
appropriate per-protocol authentication or authorization as needed.

mjr.

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 00:11:41 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: Stopping only incoming TCP connections (was: Firewall usage)

In article <chrisc.21.712446813@ramrod.lmt.mn.org> chrisc@ramrod.lmt.mn.org (Chris Cox) writes:
>In article <1992Jul28.202211.14029@shearson.com> pmetzger@snark.shearson.com (Perry E. Metzger) writes:
>
>>I was under the impression that if you filter all the SYN packets from
>>one direction that aren't SYN ACKs, bingo, you can't initiate any
>>incoming TCP connections.  Nice and stateless. The only flaw is that
>>implementations that seperately ACK the initiating SYN and then send
>>their own SYN won't be able to connect, but they are rare. Connections
>
>That would eliminate your users from starting ftp data sessions (wouldn't 
>it?).
>

	If your Firewall stopped all remote TCP packets with SYNs which are
for ports < 1024 except Domainname and SMTP, you could still FTP out and
receive mail and possibly domainname requests. For UDP you might want
to inhibit port 111 (portnampper) and 2049 (nfs) and possibly TFTP. 

	A properly configured Firewall Router can allow access from the
local net onto the Internet and even allow Internet access to specific
services or servers on the local net. For Example: If you want to provide 
anonymous FTP from a single host on your local net, just configure the 
router to pass FTP SYN requests only to the specific host.

- Carl Beame
Beame & Whiteside Software Ltd.

P.S: I don't know of any comercial router which can do all this, but public
domain ones could be modified.


-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 03:08:54 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.sys.att,comp.protocol.tcp-ip
Subject:   reset problem with WIN/TCP on 3B2

we are using NCSA and CUTCP to access our 3B2's from our PC's.

occasionally, all sessions on a given 3b2 will be tossed via a "remote reset"
or some such error.

the messages i see in NCSA indicated that the 3b is shutting the session
down.

oddly enough, the processes running on the pty continue to hang around for
a bit and eventually go away.

anyone else seen this?

any solutions would be appreciated.

email to jim@lsuc.on.ca will be summarized.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 05:11:55 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

In article <1992Jul31.000924.7528@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
> drw@euclid.mit.edu (Dale R. Worley) writes:
> 
> >I haven't studied the matter, but I believe that the more
> >sophisticated firewalling routers actually *do* track connections.
> 
> 	I prefer to use a somewhat different approach in general. First
> you determine the services that your users have a clear business need
> for. Then you develop an application gateway that "knows" that protocol
> and can give you decent access control, logging, and piggy-back blocking.
> This is much more secure (in my opinion) since you preserve the "that which
> is not expressly permitted is prohibited" doctrine and you can incorporate
> appropriate per-protocol authentication or authorization as needed.


The meaning I infer for "piggy-back blockin" seems formally
impossible.  Does it mean preventing people from using permitted
facilities for impermissible things?  Such as piggy-backing a full
featured "gateway" on top of rlogin?

Consider the recent talk of running SLIP over email over UUCP over
DECNET over x.25 over mirrors, or some such.


There is code floating around that does what its name, "gateway,"
implies with an rlogin or telnet session through a firewall.  We
recently encountered a version with a different name (it's trivial to
write from scratch) that a "security expert" (sic) from a major network
provided had "helped" a naive, trusting, related employee install.  The
thing let people from that network provider's network by pass the
sgi.com firewall.  The turkey could not understand why we considered
him no different from any other bad guy who had tried to punch a hole
through the firewall.  He only admitted guilt in having his code
go crazy and eat up all of the processes allowed "guest".

Who will guard the guardians?


Vernon Schryver,  vjs@sgi.com

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 05:22:42 GMT
From:      scott@dsg.tandem.com (Scott Hazen Mueller)
To:        comp.protocols.tcp-ip
Subject:   Confusing SLIP problem

I'm having a rather confusing SLIP-related problem, and I'm hoping that
I've just missed something obvious...  The problem is that when I bring
up my SLIP link, I can do ICMP stuff (e.g. ping, or traceroute from a
nearby Sun) just fine, but TCP-based apps (telnet, ftp) just say that they've
connected to the remote, and then hang.

At one end I have Zorch, a 4.3BSD-based system with a fairly antique kernel
SLIP driver.  At the other end is a Xylogics Annex III.  I'm using a T1600
modem at the Zorch end, and a T3000 at the Annex.  The T3000/Annex part is
probably working, as a colleague of mine can SLIP into it with no problems,
so I assume that the problem is in the Zorch end.

Here's where things start getting confusing:

1)  The SLIP driver on Zorch *seems* OK, though I suppose I could be having
a header-compression problem, since I don't think Zorch is doing that...
I can make a loopback connection to myself from port to port and bring up
SLIP over that wire, and it works just fine.  It even trims some 200ms of
latency off of pings...

2)  If I watch what's happening from aforementioned nearby Sun, using
etherfind, and try to telnet into another nearby Sun, I can see the SYNs
and acks fly by, and some data packets and whatnot.  If I then terminate
the telnet I can see FINs and RESETs go by, and netstat indicates that
the connection goes into FIN_WAIT_2 and then disappears properly.

3)  I thought it was a data transparency problem.  So, I discovered that
ping has this nice facility of padding out packets with byte sequences,
and if you ping with large enough packets it will go from 0x00 to 0xff
in increasing order.  Just lovely, only problem is that it showed pretty
conclusively that nothing was munging bytes...

My best guess is that it's a TCP header compression issue.  I think that
the Annex supports VJ compression, and from the 84-86 timeframe of the
dates on my if_sl.c, I gather that Zorch doesn't.  I thought that this
was an optionally negotiated type of thing, and if one end didn't know
about it things would still work OK, though less than optimally.  Am I
wrong?  If so, how do I go about finding the right modules to update my
driver and possibly associated header files?

Thanks for any assistance.

-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin
-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 07:41:54 GMT
From:      rh0083b@medtronic.COM (Roger-Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Stopping only incoming TCP connections (was: Firewall usage)

In article <chrisc.21.712446813@ramrod.lmt.mn.org> chrisc@ramrod.lmt.mn.org (Chris Cox) writes:
>>I was under the impression that if you filter all the SYN packets from
>>one direction that aren't SYN ACKs, bingo, you can't initiate any
>>incoming TCP connections.  Nice and stateless. The only flaw is that
>>implementations that seperately ACK the initiating SYN and then send
>>their own SYN won't be able to connect, but they are rare. Connections
>
>That would eliminate your users from starting ftp data sessions (wouldn't 
>it?).

So what you really want is application level proxies in the firewall for
TELNET, FTP, MAIL etc. Of course this defaults to the 'everything is
forbidden unless permitted' approach.

Regards,
-Roger


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 13:26:08 GMT
From:      stehman@sutekh.cs.clemson.edu (Jeff Stehman)
To:        comp.protocols.tcp-ip
Subject:   interactive vs. redirected port 25 connections


If I telnet to port 25 (on a Sun), type a command, then quit, the
connection is shown by a netstat for over a minute.  Once I quit, the
status of the connection is TIME_WAIT.  If I telnet again, this time
redirecting input from a file that contains the same commands, the
connection opens and closes in about a second.  Why?  Ever since I was
a little Unix tyke I was told that redirecting input from a file was
the same as typing.  I feel so... so lost. ;-)  Anyway, if someone
could explain, I'd appreciate it.

--
Jeff Stehman			Systems Staff, G-18A Jordan
stehman@cs.clemson.edu		Dept. of Computer Science
(803)656-2639			Clemson University

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 13:39:11 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Is someone gatewaying this to a mailing list??


	Is someone gatewaying this news group into a mailing list? I keep
getting mail from certain clueless individuals' vacation programs every
time I post here.
	Whoever you are: the world at large doesn't *CARE* if you are
on vacation right now. Either make your software work right, or don't
use it.

mjr.

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 14:00:39 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)

>The meaning I infer for "piggy-back blockin" seems formally
>impossible.  Does it mean preventing people from using permitted
>facilities for impermissible things?  Such as piggy-backing a full
>featured "gateway" on top of rlogin?

	Right. I was referring to using one service to piggy-back another
one. Such as running an interactive login session over an FTP command
stream. ;) Or tunnelling X-windows packets in a telnet session. In general
one may need to block that kind of thing, especially in the case where
the piggy-backing is being done to make an unsecure protocol (like X)
available.

	I'm not a theorist of any type, so I can't say anything about
formalisms. ;) On the other hand, I do know that ad hack methods can
go a long way towards preventing these kinds of things, *if it is necessary*.
Not all sites will *care* about preventing people from tunnelling X over
telnet, for example. At that point the problem ceases to be a technical
one, and becomes a policy matter - and many of the gateway admins I know
don't set the policy; they are just stuck with enforcing it.

	My telnet application gateway, for example, has a rate limiter
in it that will adjust the baud rate of an outgoing telnet session to
a (low) settable value. That way you can run an interactive session nicely,
but if you try to run kermit over it, it'll be unacceptably slow. My
FTP application gateway has rate limiting on the command stream, and also
fires off warnings if commands are sent over the command stream that are
not recognizable telnet commands. Yes, one could encode X packets in the
pathnames of "GET" commands, but then the rate limiter will choke you.
All these interesting events are logged.

	The main thing here is not to subscribe to some (imho useless)
formal model of security, but to just try to be reasonable and to make
sure that if someone does Something Bad to your gateway, it leaves
tracks that you can follow. Gateway admins are often in a really nasty
spot - they have to enforce sets of rules that sometimes don't make
a whole lot of sense. I try to enforce them sensibly, and to do anything
I can to make sure that if someone launches a *real* attack on my gateway,
I'll have a chance of catching them, or at least I'll have enough
information about what happened that I can deduce what they were
trying to do, and check for holes.

mjr.

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 92 14:55:37 GMT
From:      adams@kodak.kodak.com (Robert E. Adams)
To:        vmsnet.networks.tcp-ip.misc,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Transferring Multiple files using FTP


I need some help resolving an FTP problem with PC/NFS
Version 3.5. I log into a VMS machine using PC/NFS FTP
from an IBM PC. The VMS machine is running Wollogong's
FTP software Version 5.1. I am trying to download multiple
files from the VMS machine over Ethernet to my PC using
"MGET". When I issue the "ftp mget *.*" command from the
appropriate directory on the VMS machine, I get the
following error message:

	ftp: can't open local file : no such file or directory

I believe what is happening is that ftp is trying to
expand the complete VMS file name literally including the
semi-colon and the VMS file version number. When it trys 
to convert it to a DOS file name, it chokes with the above
error message. Can anyone help me get around this problem.
Single file transfers using the following command work fine:

	ftp> get vmsfilename dosfilename

There are approximately 82 files I need to transfer on a weekly 
basis. Any help would greatly be appreciated. Thanks.

Bob Adams


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 17:02:03 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: Stopping only incoming TCP connections (was: Firewall usage)


In article <1992Jul31.074154.4081@medtron.medtronic.com> rh0083b@medtronic.COM (Roger-Hunen) writes:

>From: rh0083b@medtronic.COM (Roger-Hunen)
 
>So what you really want is application level proxies in the firewall for
>TELNET, FTP, MAIL etc. Of course this defaults to the 'everything is
>forbidden unless permitted' approach.

Ah, but this is a real pain in the posterior, and breaks the semantics
of many applications. By using intelligent filtering of SYN packets,
socket numbers, etc, you can allow easy addition of new services (such
as WAIS) without needing to write new code or break security.

For extra security, I'm considering building a firewall in which
requests to change filtering can come in on a kerberized TCP service,
and then restricting everything. Users wanting to go through the
gateway would have to explicitly open a "narrow hole" through the
firewall in order to get out, thus eliminating any "random"
connections; the holes would time out after a while if no packets of
the appropriate kind had gone through.
--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 92 17:37:00 GMT
From:      t9014149@phillip.edu.au
To:        comp.protocols.tcp-ip
Subject:   books on TCP/IP

I am looking for introductory book on TCP/IP
that covers theory and practical programming
	thanks
		joseph.

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 17:58:41 GMT
From:      femenia@power.ci.uv.es (Jose M. Femenia Herrero)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans.eth
Subject:   Re: Packet driver for BICC card?

michel@neptunus.rivm.nl (Michel van Best) writes:
: Does anybody know where to find a packet driver for a bicc
: isolan card (4110 or 4110-2)?
:
: Thanks Michel
: --

Yes, you can find it in the Clarkson PD package available from
grape.ecs.clarkson.edu (/pub/ka9q) or in others archives.
The drivers name are ISOLAN.COM for the 9.1 PD version.
We have a oldest version (MBICCPD v.1.0) that seem work fine with NCSA tn3270
and with PC/TCP Software.
--
Jose Miguel Femenia Herrero      º  Internet: femenia@graf.ci.uv.es
Servei d'Informatica             º  EARN:     FEMENIA at EVALUN11
Universitat de Valencia          º  X400:   S=femenia;OU=vm;OU=ci;O=uv;P=iris;
46100 Burjassot (Valencia) SPAIN º          A=mensatex;C=es

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 92 18:04:18 GMT
From:      gorham@IRO.UMontreal.CA (Daniel Gorham)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.ethernet
Subject:   Powerhub from Alantec

Concerning Alantec's Powerhub:

I've read their literature and even tested a 3100. 
The Powerhub is fast and only routes IP but it can also
bridge at the same time on the same port!  Has anyone had
any bad experiences dealing with Atlantec or their product? 

The things I'm interested in are

        1)      Quality of Support and timeliness of response
        2)      Network performance, bugs, throughput, etc...


I would appreciate any comments you have regarding this product.

Please respond via email to gorham@crim.ca and I will summarize if 
there is sufficient interest.

Thanks in advance,

~

-- 
this is a .signature file

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 1992 19:01:33 GMT
From:      scott@DSG.Tandem.COM (Scott Hazen Mueller)
To:        comp.protocols.tcp-ip
Subject:   Re: Confusing SLIP problem


In article <1992Jul31.052242.19984@dsg.tandem.com>, I wrote:
>[...]
>My best guess is that it's a TCP header compression issue.  I think that
>the Annex supports VJ compression, and from the 84-86 timeframe of the
>dates on my if_sl.c, I gather that Zorch doesn't.

This was indeed the problem; when I turned header compression off in the
Annex and brought the link back up, telnet came to life.  Thanks to Ehud
Gavron for pointing out the clues I had missed.

>If so, how do I go about finding the right modules to update my
>driver and possibly associated header files?

This question still stands, with some elaboration:  Anyone have any idea if
I could use the relevant modules from (say) BSD NET-2?

Thanks again,


-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 92 20:15:08 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Multiple Subnets and Non-byte boundary netmasks

In article <1992Jul31.170907.23562@nstn.ns.ca> daniel@nstn.ns.ca (Daniel MacKay) writes:
>In <1992Jul24.160634.5645@acc.com> art@acc.com (Art Berggreen) writes:
>>The only problem I can think of right now with non octet aligned masks,
>>is that some older host TCP/IP implementations would only take octet
>>sized chuncks on netmasks.
>
>That's what everyone *says*.  Does anyone have a list of these noncompliant
>entities?  or is it just one of those net.legends that will be with us
>forever?  I have worked with my share of devices in the past couple of
>years, and a lot with 27 and 28 bit subnet masks, and haven't found
>anything out of sorts.

I do seem to recall an implementation that only allowed assigning netmasks
of Class A, B or C formats (but don't remember what system).

This could well be more of an urban legend that a real problem.  I don't
recall having any problems with netmasks in the past couple of years.
But I still do occasionly see very limited implementations of TCP/IP.

I'm willing to declare it a non issue unless someone can produce a system
with the problem.

Art

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 92 13:50:19 +0400
From:      saty@ntc.togliatti.su (Sergey A. TsYbanov)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet
Subject:   Problem remain the same ( about Clemson University Packet Driver )?

Hi !

rh0083b@medtronic.COM (Roger-Hunen)  writes :
		
>        I suppose that you try to send a packet while you are in the receiver
>       (called by the packet driver)? Well, I vaguely remember a statement from
>        Russ Nelson that this may not work with 1.09 compliant drivers. The spec
>       does not say anything about this, but the general consensus is that it is
>        bad practice.

I don't understand why it is BAD practice.  "DE200PD.SYS" for DE-200 card
has not this bug.

>       What you could do is to have the response packet sent at the next timer
>        interrupt.
	
I think that it is not a solution B-(.
Priority of IRQ0 ( timer device ) greater than priority of IRQ
of ethernet card  and timer interrupt may be occured while receiver
of packet driver works.  Problem remain the same ?

! iH
-- 
 ******************* Is There Anybody Out There ? **********************
 *                   SATY ( Sergey A. TsYbanov ).                      *
 *  E-mail : saty@ntc.togliatti.su Phone : number +7 (8482) 378-17-53. *
 ***********************************************************************




-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 92 21:42:17 GMT
From:      shm@syl.syl.nj.nec.com (Shailendra Majmundar)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   rlogin complains "rcmd: socket: Permission denied"

Excuse me if this is a FAQ. rlogin works fine as root, but as any other
user, it gives this error msg. I had similar problem for rsh, which 
turned out to be setting of su bit on rsh. I checked it for rlogin,
things look normal. Any suggestion??
TIA,
Sam (shm@syl.nj.nec.com)

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 92 23:25:17 GMT
From:      schemers@leland.Stanford.EDU (Roland Schemers)
To:        comp.protocols.tcp-ip,comp.lang.perl
Subject:   Re: ping + perl problem


In article <AeS6ltG00VQwELzJEx@andrew.cmu.edu> "Eric A. Anderson" <ea08+@andrew.cmu.edu> writes:
>I've got a pretty curious problem with a combination of ping and perl.
>I've written a program which will ping a whole bunch of sites in
>parallel and will summarize the information from the pings.  I start
>the pings by opening a perl pipe, e.g. 
>open(FOO,"nping -c <count> ...|");  although I use separate
>filehandles for each of the pings.  I then read in from the

I think your running into a open filehandle limit. I think on Ultrix
systems the default is 64 files per process (from limits.h). 

You could always try my new "fping" program :-) Its available via anonymous
ftp from stanford.edu, and I posted it to alt.sources a few days ago 
(version 1.17 is the latest).

It allows you specify a number of hosts on the command line, or read a list
of hosts from stdin, a file, etc.  For example:

 $hosts_to_backup = `fping -ad < /etc/hosts`;

Will ping all the hosts in /etc/hosts, and return a list of those that
are alive (reachable). The man page even has a Perl example with open2. :-)

The nice things about fping:

  1. very QUCK
  2. can read list of hosts from file/stdin/command line
  3. sets exit status
  4. can read /etc/hosts type files
  5. lots of command line options 

Using the default options, you can give fping a list of 100 hosts, and it
will tell you within 10 seconds if they are reachable or not. fping takes
about 400 milliseconds to check 31 routers, and you can make it faster
by changing the defaults. The defaults are set such that you can ping
12,000 hosts and not have fping show up as generating noticable 
traffic (it sends out a max of 100 packets per second).

Roland
-- 
Roland J. Schemers III              |            Networking Systems
Systems Programmer                  |            168 Pine Hall   (415)-723-6740
Distributed Computing Group         |            Stanford, CA 94305-4122
Stanford University                 |            schemers@Slapshot.Stanford.EDU

END OF DOCUMENT