The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 01:18:24 GMT
From:      kishor@mirage.nsc.com (Kishor Padmanabhan)
To:        comp.protocols.tcp-ip
Subject:   FTP site for TCP/IP for Windows


Hi everybody,
I missed a similar thread couple of days back. Could someone please post once 
again the ftp site for TCP/IP on windows.
Thanks a lot,
kishor

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 15:12:32 -0800
From:      wittm@chip.ee.pdx.edu (Michael Witt)
To:        comp.protocols.tcp-ip
Subject:   Looking for "Omnicom"

I'm trying to locate a phone number of a company named "Omnicom" that
used to be run by (I think) Hal Folts.  They put out a newsletter and were
a source of various standards documents.  If anyone knows how to reach them could
you please email me.

-Mike


-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 01:55:01 GMT
From:      bsmith@rahul.net (Bob Smith)
To:        comp.protocols.tcp-ip
Subject:   A poll:  If I had 20,000 TCP connections and ...

If an application on a high-end Sun has 20,000 TCP 
connections over a T-1 line to a high bandwidth network
with 20,000 hosts and the Sun goes down, how long would
it take to reestablish the connections?  Assume the Sun
has lots of memeory and has been reconfigured to support
that many connections.

If possible, I would prefer practical, not theoretical,
numbers.  Any anecdotes about real experiences would be
appreciated.

Thanks,
-- 
Bob Smith <bsmith@rahul.net>

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 17:03:50 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for "Omnicom"

In article <2imnl0$79q@chip.ee.pdx.edu> wittm@chip.ee.pdx.edu (Michael Witt) writes:
>
>I'm trying to locate a phone number of a company named "Omnicom" that
>used to be run by (I think) Hal Folts.  They put out a newsletter and were
>a source of various standards documents. 


  Dunno if this is still current:

  OMNICOM
  115 Park St. SE
  Vienna, VA 22180

  703-281-1135



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 94 05:12:42 GMT
From:      alan@kether.intellint.com (Alan M. Friedman)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Need help w/ Versaterm SLIP, MacTCP, etc.

In Article <2h1ecg$de6@news.u.washington.edu>, msbat@u.washington.edu
(Autumn Blanchard) wrote:
>
>I need some help getting MacTCP and Versaterm Adminslip, and my 
>SLIP account working.  I just bought The Internet Start Kit for 
>Mac (TISK) and I'm having problems with my new SLIP account at NW 
>Nexus.
>
>....
>
>So next, I tested the SLIP connection with MacTCP Watcher 1.1.0 
>and these are the overall results:
>
>          IP ADDRESS TESTED (entered in MacTCP Watcher's Dialog Box)    
>TEST      198.137.231.151 (their computer)    198.137.231.???* (mine)
>----      --------------------------------    -----------------------
>ICMP PING    successful test                    no response
>UDP ECHO     no response                        successful test
>TCP ECHO     no response                        successful test
>DNS          no response                        no response
>                                         *??? means I entered the IP
>                                         address assigned by the server
>
>...
>
>Thanks in advance for any help,
>Autumn Blanchard (and Walter Clinton)
>msbat@u.washington.edu

    I posted this once before, but I'm not sure the post worked.  If so
pardon my repeat. :-)
    It sounds like your default gateway might not be set.  You should
have "198.137.231.151" (their computer) in the Gateway Address under
Routing Information in the MacTCP CDEV.  That would explain being able
ping addresses, but not getting domain name service or UDP/TCP response.

Hope This helps,
alan
_____________________________________________________________________________
 \_\_\_                                       | Alan M. Friedman
    \_  \_\_\_        Artificial Intelligence | Intelligent Interfaces, Inc.
     \_    \_  \_\_\_         and             | (301) 299-6631|(301) 983-2211
    \_\_\_  \_    \_    Neural Netification   | alan@kether.intellint.com
           \_\_\_  \_                         | AppleLink:    D5620
                  \_\_\_                      | Compuserve:   72120,564
_____________________________________________________________________________

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 10:41:05
From:      loss@husky.bloomu.edu (Doug Loss)
To:        comp.protocols.tcp-ip,comp.sys.unisys
Subject:   file permissions during ftp transfers

   In a project I'm working on, we have to transfer a file using ftp to our 
Unisys 2200 mainframe computer running NFS 2200.  Everything transfers OK, but 
the file permissions on the transferred file are -rx-r-----.  What determines 
the permissions for an ftped file?  I've tried changing the umask in the 
.profile file for the ID used, with no success.  Is there an ftp protocol 
command that will do the equivalent of chmod on a newly uploaded file?  I'd 
appreciate any help anyone can give.


Doug Loss                        Americans will accept your idea
Data Network Coordinator         much more readily if you tell them
Bloomsburg University            Benjamin Franklin said it first.
loss@husky.bloomu.edu
Voice (717) 389-4797

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 94 10:51:55
From:      jconno03@cps.plnin.gmeds.com (John Connolly)
To:        comp.protocols.tcp-ip
Subject:   Dialup router recommendations

I am looking for suggestions for packages to support dialup access
to a Unix network for up to 14 clients.  I'm aware of the Telebit's 
Netblazer product.  Are there other options?
--
				John Connolly, EDS
				jconno03@cps.plnin.gmeds.com

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 07:29:07 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: listen(s, SOMAXCONN)

rstevens@noao.edu (W. Richard Stevens) writes:

>> For as long as I can remember, the value of SOMAXCONN (the backlog of
>> pending connections listen() is prepared to cope with) has been 5, at
>> least on BSD derived systems.  I hear that OSF/1 on Alphas can set the 8.
 
>Traditional BSD systems give you a small fudge factor over the backlog
>argument specified to listen().  (Check out Figure 18.23 of my recent
>book "TCP/IP Illustrated" for the details and some examples.)  When
>you say listen(fd,5) you really get 8 queued connections.  When you
>say listen(fd,0) you really get 1 queued connection.  But sure enough
>OSF/1 does set SOMAXCONN to 8, which if they've copied the Berkeley
>logic should give 13 queued connections.  I haven't tried this to see
>if that's the case, however.
 
>> Under SunOS 5.3, the include file lists SOMAXCONN as 5, but the
>> documentation states (in the NOTES section):
>>
>>	There is currently no backlog limit.
>>
>> Does anyone know if this is just another documentation bug?
>> Or is SOMAXCONN set to the wrong value in <sys/socket.h> ?
 
>This is wrong documentation.  I remember running tests on 5.2 and
>there definitely was a limit.  In fact, the SunOS 5.x logic is not
>the same as Berkeley's, and if you say listen(fd,5) you only get 5
>queued connections, with no fudge factor.  Some people were complaining
>about this a few months back because listen(fd,0) under SunOS 5.x gives
>you *no* pending connections ...


HP-UX defines SOMAXCONN as 20.  Dunno what the limit really is, but I'm sure
its more than 5.


Doug Siebert || dsiebert@isca.uiowa.edu   ||  Defeat Usenet spool grepping!
Kibo Turkey Greece Macedonia Perl Watcom Mason Clinton Illuminati Fnord Hastur

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 08:32:57 GMT
From:      tardiff@halcyon.com (Michael J. Tardiff)
To:        comp.os.msdos.mail-news,comp.protocols.tcp-ip,comp.protocol.tcp-ip.ibmpc,alt.winsock
Subject:   Re: WinTrumpet NNTP problems....

In article <2iac37$d9u@hdxu03.telecom.ptt.nl> janss002@telecom.ptt.nl (Richard Jansen) writes:

>I have a copy of the Trumpet WINSOCK dll and WinTrumpet. I have been trying of and on
>to install and configure everything, but I couldn't get WinTrumpet to work.
 
>The first problem is that the "TCP manager" application with Trumpet Winsock
> keeps saying: "Cannot load TCP". Seems to me that this is to be regarded
> as an error message.

Put a dummy IP address in TCPMAN's Setup dialog.  0.0.0.0 will do.
Of course, if you have a *permanent* IP address, put that there.

+ Michael
 ___________________________________________________________________________  Michael J. Tardiff             206.528.8102             tardiff@halcyon.com
 Seattle, Washington USA       "On the Internet, nobody knows you're a dog."
 Western Star Consulting helps small business use computers and the Internet 
 

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 10:02:49 GMT
From:      bturlinx@vub.ac.be (Tuerlinckx Benoit)
To:        comp.protocols.tcp-ip
Subject:   TCP implementation question

Hi.

I'm new to this forum, and this is my first post, so please excuse any bad
etiquette, silly questions and the like...

Due to a defective fddi interface, some ethernet stations on my network happen
to see the very same frame twice in a row. 
That frame is usually just a TCP ACK.

When it happens, the station that receives the double ack seems to go mad.

It times out, and the resulting TCP throughput is ten times less than 
normally.

The question is: 
how should a well-behaved TCP react upon receipt of a duplicate
ack ? My naive assumption is that it simply should ignore it, shouldn't it ?

Benoit Tuerlinckx (bturlinx@is1.ulb.ac.be)
  aka 100020.1437@compuserve.com            


-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 15:58:16
From:      ace@ics.forth.gr (Andreas C. Enotiadis)
To:        comp.protocols.tcp-ip
Subject:   AARGH-5131 emulator???

Hi Guys,
This might seem an odd request but has anyone seen/heard of an IBM 5131 
emulator over the telnet protocol? I have this odd request and I am vainly 
trying to fulfil it.
BTW, Ideally it should support winsock....Sounds like too much.
Andreas

--------------------------------------------------------------------------
Andreas C. Enotiadis
Internetwork Ltd
"Just screwing around - for a living"
ace@ics.forth.gr
ace@iesl.forth.gr
ace@praxis.forth.gr
Snail-Mail : 1 Louki Akrita Str, 15237 Athens, Greece
--------------------------------------------------------------------------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 12:14:44 GMT
From:      chris@marge.mikom.csir.co.za (Chris zwanepoel)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   NFS authentication non-existent ??

HI ALL NFS programmers and users.

I have heard that it is actually very easy to by-pass the /etc/mount command and write your own 
RPC calls to download data from any "exported" file-system.
Apparently some universities now refrain from using NFS on campus, because of students drawing
off any data they want, even from not-so-widely-exported volumes, just by writing the necessary
RPC calls, and not doing the mount call first, thus by-passing the initial authentication.


I may have this all wrong, but could anybody maybe help with info on where to find out or
maybe what to read, which newsgroups to post to, cert advisories, RFC's etc.

{even flame me if you like, at least i learn through mistakes.........} 

chris@marge.mikom.csir.co.za

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 10:31:46 UNDEFINED
From:      karih@relatech.fi (Kari Hakkinen)
To:        comp.protocols.tcp-ip
Subject:   Re: Gateway Ethernet cards

In article <hans.1.2D47BC05@lu.se> hans@lu.se (Hans Rosenlund) writes:

>I have some computers with Gateway ethernet cards for IBM-PS/2 in a Novell 
>network. Our new connection to the wide world demands TCP/IP protocol. When 
>I configure these cards with the GEMCTCP they automatically get the 
>interrupt address 0x60, which is in conflict with other routines.
 
>Does anyone have a solution on how to configure to, e g  0x70? Or is it 
>impossible?

Here is an excerpt of the Gateway driver manual. Hope this helps.

---- begin ------ begin -----
2-11 Using the GETHER Environment Variable

   If none of the predefined configuration combinations are acceptable and
   you do not wish to permanently change the driver, or a change must be
   made to the TCP/IP interrupt, the GETHER environment variable may be used
   in conjunction with the DOS SET command. This method is available for any
   DOS IPX workstation.

   The "SET" command can be issued at the operating system prompt or placed
   in the AUTOEXEC.BAT file.  In either case it must precede the IPX
   statement when loading the workstation.

   There are two configuration options:

   1. Select an option from the configuration table as follows:

            SET GETHER=x

         where

            x is option 0 through 2 in Table 2-1 or 2-2


   2. Enter specific adapter requirements as follows:

            SET GETHER=I:x,A:yyy,T:zz

         where

            x is the IRQ

            yyy is the device I/O address

            zz is the software interrupt vector used for TCP/IP.

         Refer to Table 2-3 for available IRQ, I/O address, and TCP/IP
         interrupt combinations.

         You can specify one, two, or all three of the variables. Any
         variable not specified will remain at its default or currently
         specified value.

         This selection may also be used with stand-alone TCP/IP drivers.

----end---end---

Regards,
Kari

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 12:33:34 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: listen(s, SOMAXCONN)

rstevens@noao.edu (W. Richard Stevens) writes:

>This is wrong documentation.  I remember running tests on 5.2 and
>there definitely was a limit.  In fact, the SunOS 5.x logic is not
>the same as Berkeley's, and if you say listen(fd,5) you only get 5
>queued connections, with no fudge factor.  Some people were complaining
>about this a few months back because listen(fd,0) under SunOS 5.x gives
>you *no* pending connections ...

Which is what the documentation of listen implies.  The fudge factor,
if I remember correctly, is:  backlog' = backlog * 3 / 2 + 1.

Casper

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 13:53:57 GMT
From:      rince@dcs.warwick.ac.uk (James Bonfield)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

In <2ilh3k$cfe@wabe.csir.co.za> chris@marge.mikom.csir.co.za (Chris zwanepoel) writes:

> ... writing the necessary RPC calls, and not doing the mount call first,
> thus by-passing the initial authentication.

This used to be the case, but as I recall Sun added some magic cookie style of
thing to prevent 'guessing' of nfs packets. However, firstly I often find NFS
file handles listed in var/adm/messages - so this kind of defeats that object.
And secondly, is there any further checks once you have got a valid handle?
Also, mount does the same authentification checks as NFS and so it is possible
to get the root file handle. Has this changed at all?

It's been a while since I played with NFS so I'm not up to date with the
'cookie' extensions (am I right in my understanding here? I stopped
after realising (the hard way - sorry Rob!) that NFS does very little checks.
It's possible to change a directory into a file (or an unknown inode type)
with invalid data.

Secure RPC solves these problems, although I haven't investigated this much.

	James

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 14:22:30 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

rince@dcs.warwick.ac.uk (James Bonfield) writes:

>This used to be the case, but as I recall Sun added some magic cookie style of
>thing to prevent 'guessing' of nfs packets. However, firstly I often find NFS
>file handles listed in var/adm/messages - so this kind of defeats that object.
>And secondly, is there any further checks once you have got a valid handle?
>Also, mount does the same authentification checks as NFS and so it is possible
>to get the root file handle. Has this changed at all?

Once you have a valid handle, there are only three checks:

On all access:
	- root access check
On write access:
	- is filesystem exported read-only - no writes
	- if filesystem expoted -read-mostly, check write access for
	  IP in access list.

There is an optional check in Sun's implementation that requires reserved
ports as origin for NFS or mount requests.  This helps some what, because
they first need to have access to a PC (not on my net)
or become root on a workstation (when they can already su to any user and
access all files).

>It's been a while since I played with NFS so I'm not up to date with the
>'cookie' extensions (am I right in my understanding here? I stopped
>after realising (the hard way - sorry Rob!) that NFS does very little checks.
>It's possible to change a directory into a file (or an unknown inode type)
>with invalid data.

I think cookies have been part of filehandles from the (almost) very
beginning.  It is needed for one reason from the start: make sure that
a inode that is reused on the server isn't used by a client under its
previous name. For that purpose you only need a counter that gets
incremented each reuse.  These ``generation numbers'' now start of at
a random number.  NFS originally didn't check much at all, it assumed it
was below the pathname interpretation phase and other parts of a
``sensible'' kernel.  We all know that that is not true, especially
with all the Mac and PC NFS clients out there.

>Secure RPC solves these problems, although I haven't investigated this much.

There is a number of mechanisms used to remedy this problem.  Secure RPC
is one of them, Kerberized NFS an other.

Casper

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 14:41:53 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP questions

In article <2i99gj$9j8@olivaw.apanix.apana.org.au> hart@apanix.apana.org.au (Leigh Hart) writes:
   mksho@uno.edu writes:
      Is it possible to have one of these [UNIX] machines function as
      a SLIP server for connections from the terminal server?

   In short, no you cannot use a host on the other side of a terminal
   server as a SLIP host.  The network pty's just don't support SLIP
   line discipline.

As has already been pointed out, this is incorrect.  Many SLIP
implementations will work over a pty.  Your biggest difficulty will be
in making the rlogin or telnet data stream transparent enough to carry
SLIP, since SLIP has no general character escaping capability.  You
might get away with using SLIP, or you might find it necessary to use
PPP instead, depending at least in part upon the rest of your school's
datacomm infrastructure.

   Your best bet lies with hoping that your admins can turn on SLIP on
   your terminal server, but I have to admit, this is not really a
   secure thing to do in a school environment.  It's as bad as
   allowing any student to plug into the ethernet and go for it.

Lots of schools do it.

      Would PPP be a better idea from a security standpoint?  

   as far as I know ppp isn't any more secure than slip, but I don't
   know that much about it so I could be wrong.

PPP can be made more secure that slip, because you can use a
link-level peer authentication protocol (CHAP, per RFC 1334) to be
sure that the system on the other end of the call is who she says she
is.  That won't help you police the activities of the machine's users,
but at least you can track responsibility for the machine and its
connection to the Internet.

      Also I believe that these connections are non-error corrected,
      non-compressed.

   The error correction is handled by the TCP/IP protocol.  A 14.4k
   modem can also be useful to prevent full retransmission of packets
   by enabling error correction on the modems.

A V.32bis (14.4K) modem give you more speed than a slower modem.  Most
V.32bis modems also incorporate V.42 error correction and V.42bis data
compression.

   Compression is also an issue of the modem, if your server doesn't
   support CSLIP (compressed SLIP) then it's definately all up to the
   modem.

V.42bis compresses all the data passing through the modem.  It's
generally a good idea for SLIP and PPP links.  RFC-1144 "VJ" TCP
header compression turns "SLIP" into "CSLIP", and turns "PPP" into
"PPP with VJ".  It reduces the amount of data that tries to pass
through the modem, to improve responsiveness by reducing latency.  Use
all the compression techniques you can.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 14:47:28 -0000
From:      cs2ev@herts.ac.uk (Mas)
To:        comp.protocols.tcp-ip
Subject:   writing / reading

  Dear all

   I am wanting to send an integer from a client so server using the
write and read functions, but keep on recieving rubbish, is there a
reason for this, and is there a solution?
   Also does anybody have a algorithm, or code using the read and write
functions that would enable me to send and recieve a file?

  Any help appreciated - Thanks

   Andre-John MAS

 P.S. Please mail the response to me via Email

================================    /\    ===============================
 Andre-John MAS                    /  \    InfoSci Department
 Email : A.Mas@herts.ac.uk         \  /    University of Hertfordshire
--------------------------------    \/    -------------------------------
Mail : 33 Avenue du Castel, 1200 Brussels, Belgium
Fax  : (32) (02) 770.89.05

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 94 23:19:09 PST
From:      jeh@cmkrnl.com (Jamie Hanrahan, Kernel Mode Systems)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   RMT protocol description?

Is there any documentation on the RMT protocol outside of rmt.8, rmt.c, and 
so on (from the NetUCB distribution)?

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
Internet:  jeh@cmkrnl.com (JH645)  Uucp: uunet!cmkrnl!jeh  CIS: 74140,2055

Whatever you can do, or dream you can, begin it.  
Boldness has genius, power, and magic in it.  -  Goethe

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 15:31:12 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP implementation question

In article <2il9c9$dgk@rc1.vub.ac.be> bturlinx@vub.ac.be (Tuerlinckx Benoit) writes:
> ...
>Due to a defective fddi interface, some ethernet stations on my network happen
>to see the very same frame twice in a row. 
>That frame is usually just a TCP ACK.
>
>When it happens, the station that receives the double ack seems to go mad.
>
>It times out, and the resulting TCP throughput is ten times less than 
>normally.
>
>The question is: 
>how should a well-behaved TCP react upon receipt of a duplicate
>ack ? My naive assumption is that it simply should ignore it, shouldn't it ?

I bet that is not at all what is happening.  Duplicate TCP/IP ACK's usually
indicate that data packets in the opposite direction are being lost.  Lost
data packets cause subsequent data packets to appear to be out-of-order.
Out of order packets generate extra ACKs for various reasons and purposes.
I bet that the "retransmitted data packets" and "duplicate acks" counts
from `netstat` on the sending machine will show a large number, as will
the "out-of-order packets" count on the receiving machine.

Please re-read the recently posted description of the fast-retransmission
mechanism posted here, wherein duplicate ACKs are used to trigger
retransmissions.  Note what Van Jacobson wrote happens when the loss rate
is too high.


Vernon Schryver    vjs@rhyolite.com

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 16:38:48 GMT
From:      rince@dcs.warwick.ac.uk (James Bonfield)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

In <2iloj6$n93@mail.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
> On write access:
> 	- is filesystem exported read-only - no writes

This check I am sure I once bipassed (without realising). I did some
experiments involving creation/deletion of files, and only later found out
that the disk was mounted read only. It's such a long time ago that I cannot
remember whether or not I was on the machine that 'owned' the disk or not.
Presumably this shouldn't make any difference though.

> incremented each reuse.  These ``generation numbers'' now start of at
> a random number.  NFS originally didn't check much at all, it assumed it

This is presumably Sun's patch to make file handle less guessable. However,
especially with nfsd logging failed file handles to syslog I would assume it
is still fairly easy to generate your own handles without resorting to
remounting.

> >Secure RPC solves these problems, although I haven't investigated this much.
> 
> There is a number of mechanisms used to remedy this problem.  Secure RPC
> is one of them, Kerberized NFS an other.

Do either of these cause major slowdown of data transfer. Is the privilaged
port check standard in most NFS implementations now? (I'm loathesome to dig up
my NFS programs to actually check these things.)

I found Secure RPC worth using on Solaris systems if only to secure such
utilities as Admintool.

	James

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 17:16:36 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

rince@dcs.warwick.ac.uk (James Bonfield) writes:

>In <2iloj6$n93@mail.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>> On write access:
>> 	- is filesystem exported read-only - no writes
 
>This check I am sure I once bipassed (without realising). I did some
>experiments involving creation/deletion of files, and only later found out
>that the disk was mounted read only. It's such a long time ago that I cannot
>remember whether or not I was on the machine that 'owned' the disk or not.
>Presumably this shouldn't make any difference though.

On each write, the ``read-only'' flag is checked.  This may not have
been true in older implementations.

>> incremented each reuse.  These ``generation numbers'' now start of at
>> a random number.  NFS originally didn't check much at all, it assumed it
 
>This is presumably Sun's patch to make file handle less guessable. However,
>especially with nfsd logging failed file handles to syslog I would assume it
>is still fairly easy to generate your own handles without resorting to
>remounting.

AH, this was actually a silly bug: they used a random number generator
that wasn't seeded properly.  (They didn't initialize one variable)

>Do either of these cause major slowdown of data transfer. Is the privilaged
>port check standard in most NFS implementations now? (I'm loathesome to dig up
>my NFS programs to actually check these things.)

A small overhead.  I'm not sure about the port check.  Most clients
support it (i.e., they use reserved ports).  Most servers are shipped
w/o such checks, I think.

>I found Secure RPC worth using on Solaris systems if only to secure such
>utilities as Admintool.

I'm not convinced that secure rpc is secure enough.  But we've switched
admind to using secure RPC.

Casper

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 19:02:17 GMT
From:      newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

In article <2ilh3k$cfe@wabe.csir.co.za> chris@marge.mikom.csir.co.za (Chris zwanepoel) writes:
>HI ALL NFS programmers and users.
>
>I have heard that it is actually very easy to by-pass the /etc/mount command and write your own 
>RPC calls to download data from any "exported" file-system.

yes, this is true.  Anything a program can do, you could write another
program to do.

>Apparently some universities now refrain from using NFS on campus, because of students drawing
>off any data they want, even from not-so-widely-exported volumes, just by writing the necessary
>RPC calls, and not doing the mount call first, thus by-passing the initial authentication.

Good, glad to hear of people taking charge of their security.

>I may have this all wrong, but could anybody maybe help with info on where to find out or
>maybe what to read, which newsgroups to post to, cert advisories, RFC's etc.
>
>{even flame me if you like, at least i learn through mistakes.........} 

No, this is true.  NFS uses RPC's (usually UDP packets) to do its
many operations.  You can with a little effort write an NFS client
that resides entirely in userspace (instead of it being in the
kernel).  Now this part isnt so bad, what is bad is that you
can do this as non-root against many nfs servers.  This means
you can look at NFS volumes as any uid (that NFS allows) even
though you are just a normal user.  All you need is an account
on a machine that can mount the volume from another machine
and source+compiler or a binary.

>chris@marge.mikom.csir.co.za



-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 19:24:27 GMT
From:      alanb@sf.logica.com (Alan Bram)
To:        comp.protocols.tcp-ip
Subject:   RFC1006 implementation questions

I am implementing RFC 1006 in the Tandem/Guardian environment as an enhancement to Tandem's OSI 
Transport Service product.  There are a couple of points from the RFC document that seem unclear to me.

Has anyone done or seen an RFC 1006 implementation that could answer these questions for me?  Any 
assistance would be most appreciated.


1. The default TPDU size is to be 65531 octets.  RFC 1006 says: "In order to negotiate a smaller 
(standard) TPDU size, the negotiation mechanism specified in [ISO8073] is used (e.g., setting the desired 
bit in the 'TPDU Size' variable part)."  ISO8073 allows the TPDU size to be a power of 2 between 128 and 
2048 for class 0 (or 4096 or 8192 for other classes).  So it seems to me that a strict reading of RFC1006 
might imply that we're restricted to these sizes.  On the other hand, it seems natural to allow any power of 
2 that is less than 65531.  Thus there seem to be three possibilities for allowable sets of TPDU sizes:

a) 65531, 128, 256, 512, 1024, 2048

b) 65531, 128, 256, 512, 1024, 2048, 4096, 8192

c) 65531, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768

Also, the coding of these values in the CR TPDU is the base-2 logarithm of the size.  In other words, 128-
8192 correspond to 7-13.  Can 65531 be represented in a CR TPDU with a coding of '16'?  Is it proper 
explicitly to specify 65531 in the CR TPDU when it is already the default?


2. Expedited Data is to be supported.  Should the network expedited variant (which I presume would be 
TCP/IP's "Out-of-Band" data capability) be used?  If so, should the use of network expedited data be 
dependent upon the setting in the "Additional Option Selection" variable part of the CR TPDU, as for 
transport expedited data?

If transport expedited data is in use, do all the usual elements of procedure apply?  In particular, should 
the EA (Expedited Data Acknowledgement) TPDU be used?  Since the RFC1006 ED TPDU doesn't 
contain an ED TPDU-NR (TPDU identification number), the YR-EDTU-NR (identification of TPDU 
being acknowledged) would seem to be useless.


I can be reached via e-mail at:
   bram_alan@tandem.com
or
   alanb@sf.logica.com

Thanks!

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1994 21:04:43 GMT
From:      dennis@cauchy.math.nwu.edu (Dennis Director)
To:        comp.os.linux.misc,nwu.unix.linux,comp.protocols.tcp-ip
Subject:   Help! Upgrade kernel for SLIP and Mosaic.


Well, I had SLIP working on Linux version 0.99.13.
My only problem was that Mosiac wouldn't access the
network, even though I could ping the machine that
Mosaic failed to retrieve a document from.

So, I have built a new system (99.14) as recommended and
installed all of the NET-2 software as suggested in
the Linux HOWTO file.

I can now establish a SLIP connection which allows me to
ping the SLIP server but no other machines.  Any other
attempt get me the now annoying "Network is unreachable".

What have I done wrong? Oh yeah, P.S. I compiled in the
Mitsumi support on the new kernel but it does not seem
to want to access my CD drive.  It says,
/dev/mitsumi_cd is not a valid block device
but it is if I go back to the old kernel.

Thanks for any help.


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 21:10:08 GMT
From:      Debby Koren <deb@radmail.rad.co.il>
To:        comp.unix.aix,comp.protocols.tcp-ip,comp.mail.misc
Subject:   need POP client for RS6000


I have an all-PC (except for one SUN server) based network running POP (and
other clients) and suddenly one guy needs to use an RS6000!  He would like to
run POP to read his mail from our central server, like everyone else does.  Can
anyone point me to a public domain POP client, preferably with a nice user
interface, for an RS6000 running AIX 3.2 (with the Power PC Processor, in case
there is any compatibility issue)?  I appreciate any information.

Thanks!

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Feb 1994 21:31:29 GMT
From:      consol@world.std.com (CSI ContractSolutions)
To:        comp.protocols.tcp-ip
Subject:   Ifconfig and slattach  ????


Hello,
I'm fairly new to TCP/IP.  What is Ifconfig and slattach?  Can anyone 
explain to me better the manual does??????

Also, can anyone recommand me a TCP/IP book?

Thank you in advance.

Y.K.

consol@world.std.com

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 01:23:05 GMT
From:      jonathan@leland.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP questions

>As has already been pointed out, this is incorrect.  Many SLIP
>implementations will work over a pty.  Your biggest difficulty will be
>in making the rlogin or telnet data stream transparent enough to carry
>SLIP, since SLIP has no general character escaping capability.

But if the SLIP packets are sent as a Telnet data stream, they
don't *NEED* encapsulating.  Are there really terminal servers
that have an escape character or inband flow control (XON/XOFF)
that cannot be disabled?


It's somewhat perverse, but there's no reason why one cannot
set up a SLIP or PP stack on top of a pty that is on the "upstream"
side of a Telnet connection.

I have code, somwhere on an Exabyte that does just this for 4.3BSD-Reno,
for the truly desperate...


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 01:42:30 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   ICMP destination unreachable on the loopback??


Last night I picked up an interesting tool that was mentioned in the
comp.unix.security group in the ICMP bombs thread.  (It is called icmpinfo
and is available via anon ftp from hplyot.opspm.circe.fr)  What it does is
show all the ICMP traffic on your machine, in particular the ICMPs for
destination unreachable.  The theory is that you can check up on the ICMP
destination unreachables reaching your machine and see if you are being
"bombed".  (The latest HP-UX kernel patches should fix this problem, BTW,
if it is happening or has happened to you)

I noticed a fair number of ICMP destination unreachables coming from 127.0.0.1
to 127.0.0.1 on my machine.  What is happening is that applications running
on this machine communicate via UDP sockets bound to the loopback interface,
and when one process exits when another is composing a message to be sent
to it an ICMP destination unreachable results.  Is this supposed to happen
from merely attempting to send a UDP packet to a port that is currently not
bound by any process?  I don't know if this is a bug or not, but it seems
odd to me.  I wish I could get this information on the return status from the
sendto() call, it would avoid the need to have it time out, but this could
probably only work for local sockets.

This is on an HP 9000/710, running HP-UX 9.01 with all the latest patches.


Doug Siebert || dsiebert@isca.uiowa.edu   ||  Defeat Usenet spool grepping!
Kibo Turkey Greece Macedonia Perl Watcom Mason Clinton Illuminati Fnord Hastur

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 16:50:16 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: ?? Hostname, Localhost, Internet_Address ????

In article <CKM674.8FG@world.std.com> consol@world.std.com (CSI ContractSolutions) writes:
>
>I'm fairly new to TCP/IP and believe it or not I'm installing one.
>I have few questions if anyone like to help me out.
>I'm installing TCP/IP to run PPP to get connected to INternet.

  I'll refrain from referring you to the system's documentation or
  "TCP/IP Network Administration" from O'Reilly.  Ooops I just did,
  didn't I?  >:-)


  I'd post the name of the package and system you are installing,
  someone can likely give you exact answers.

>
>1. What is a hostname(is this a provider's name or address for internet) ?
    A hostname is the name of a host that you want to speak to on
    the internet.  It could be your host or any other host.

    If that host is not on your same Internet network (literally the
    network portion of your internet address) you'll also need to
    worry about configuring a gateway or networks file to tell it how
    to get there.  


>
>2.  What is a Localhost(is this my server?)?

    Localhost usually means the "host" in which you are running that
    particular copy of the tcp/ip stack.  

>
>3.  What is INternet_address(is this address from me or the provider)?
>
   It is your address at the network layer....if this is a private
   system you can make it up, within the rules of netmask.  If this
   is connected anywhere near a larger network, get an address from
   whoever you are connecting to.  

   While you are getting your internet address, get your netmask in
   the event your package allows you to set it.          


>4.  When I run "tcp start" at the # prompt, I get "ifconfig: localhost: 
>bad value" message.  is this normal or what am I doing wrong?
>
    It just means you haven't configured the host address...most
    likely your own machine's.



-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 04:47:47 GMT
From:      dekard@garnet.msen.com (Eric McGlohon)
To:        comp.protocols.tcp-ip,mi.misc,mi.wanted
Subject:   DLPI spec needed

I'm looking for the DLPI Specification for TCP/IP.  Does anyone know
where I can find this?  I doubt that Borders carries it....

Thanks,

--
Eric J. McGlohon      | eric@dekard.com | "I'm not in the business... 
Dekard Software, Inc. | Ann Arbor, MI   |  I am the business."  --Rachael, BR
--

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Feb 94 14:02:53 -0500
From:      "Jeff Milloy" <p00633@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   IPX Spoofing

I realize that this might not be the right newsgroup for this, but I 
figured that some people in this group are knowledgeable in this area.

I am interested in implementing IPX Spoofing (for Novell clients over 
WAN links).  Is there a standard set of messages that need to be 
spoofed (SAP, ???).  Can anyone direct me to some literature, algoritm, 
or code that would help me implement the spoofing?

In addition, if there is a more appropriate newsgroup for this 
question, please enlighten me!

Thanks in advance!!


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 11:11:54
From:      mscarton@mudshark.sunquest.com (Mark A. Scarton)
To:        comp.protocols.tcp-ip
Subject:   Macintosh stack

Is there a TCP/IP stack for the mac similar to the trumpet stack?  In 
particular, we have a guy that wants to be able to use gopher, mail,
ftp, and telnet services from a mac in an educational setting.  He
can't get funding to look for commercial products and so is looking
for any shareware or PD implementation of the stack and applets
(coming significantly out of pocket would be a real burden).

Thanks!
========================================================================
Mark A. Scarton, ABD                 | Sunquest Information Systems
801/278-7597, fax 278-0192           | 4525 S. Wasatch Blvd Suite 335
mscarton@mudshark.sunquest.com       | Salt Lake City, Utah  84124
========================================================================
"Ski Utah...The greatest snow on Earth!"

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 09:11:20 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) writes:

>No, this is true.  NFS uses RPC's (usually UDP packets) to do its
>many operations.  You can with a little effort write an NFS client
>that resides entirely in userspace (instead of it being in the
>kernel).  Now this part isnt so bad, what is bad is that you
>can do this as non-root against many nfs servers.  This means
>you can look at NFS volumes as any uid (that NFS allows) even
>though you are just a normal user.  All you need is an account
>on a machine that can mount the volume from another machine
>and source+compiler or a binary.

At least you can prevent against this on some servers,

	on Suns running SunOS 4.1.x:

		adb -w -k /vmunix /dev/mem
		nfs_portmon?W1
		nfs_portmon/W1

	on Suns running Solaris 2.x

		add to /etc/system

		set nfs:nfs_portmon = 1

(Now you need to be root on a client or have a ethernetworked
PC)

Casper

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 15:49:08
From:      loss@husky.bloomu.edu (Doug Loss)
To:        comp.protocols.tcp-ip,comp.sys.unisys
Subject:   Thanks for the FTP help

   Thanks to Damiano Bolla, Dan Wing, and Barry Margolin for their help with 
our file permissions problem with ftp transfers.  As it turns out, we're lucky 
in that we have an easy way of solving the problem.

   ftpd in NFS 2200 for a Unisys 2200 mainframe implements a non-standard ftp 
command that allows us to change the umask for a session.  To do so, we type: 
"quote SITE UMASK 000" after establishing the session but before doing any 
transfers.  I hope that may help someone else.  Again, thanks for the help.


Doug Loss                        Americans will accept your idea
Data Network Coordinator         much more readily if you tell them
Bloomsburg University            Benjamin Franklin said it first.
loss@husky.bloomu.edu
Voice (717) 389-4797

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 12:48:48 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip,mi.misc,mi.wanted
Subject:   Re: DLPI spec needed

> I'm looking for the DLPI Specification for TCP/IP.  Does anyone know
> where I can find this?  I doubt that Borders carries it....

I don't know what you mean by the "DLPI spec for TCP/IP"; UI's DLPI
spec for SVR4 is available from ftp.ui.org in the pub/osi directory
as a PostScript file.

	Rich Stevens  (rstevens@noao.edu)

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 15:05:57 GMT
From:      uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz)
To:        alt.security,comp.security.misc,comp.protocols.tcp-ip
Subject:   Both ACK and ICMP UNREACH (Re: icmp (bombs))

In article <CKK75G.FC7@news.hawaii.edu>,
Tim Newsham <newsham@uhunix.uhcc.Hawaii.Edu> wrote:
> is included in the icmp packet.  Also, an ICMP UNREACH should come
> in before any ACK came in (would you ever receive both an ACK and
> an ICMP error for the same packet?  even if you did?  shouldnt
> you believe the ACK over the ICMP?).  So at this point you still

This is disputable. If you trust the ACK over the ICMP, you're
vulnerable to spoofing of the other host when in fact it is really
unreachable - just the other way round than with ICMP bombing. You
can't have it both ways.

Getting both an ACK and an ICMP UNREACH can indicate at least these
four situations:
- the ICMP is spoofed (ICMP bomb)
- the ACK is spoofed
- the software on the peer host is broken
- a temporary routing problem (yes, this *should* not happen)

So what is the correct way of dealing with this problem, if any? Of
course, any ICMP UNREACH should be verified, but what if it matches
the ACK?

Olaf
-- 
        olaf titz     o       olaf@bigred.ka.sub.org          praetorius@irc
  comp.sc.student    _>\ _         s_titz@ira.uka.de      LINUX - the choice
karlsruhe germany   (_)<(_)      uknf@dkauni2.bitnet     of a GNU generation
what good is a photograph of you? everytime i look at it it makes me feel blue

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Feb 94 22:15:47 MST
From:      dude@traider.ersys.edmonton.ab.ca (Adam Pearse)
To:        comp.protocols.tcp-ip
Subject:   Evaluating a TCP/IP product - HELP!!!!

Hi, I need the Net's vast experience in choosing a TCP/IP product.   
Presently, Wollongong, FTP, Netmanage, Beame & Whiteside, and SUN PC-NFS
are the companies I am evaluating. Here is the criteria:
1) tcp/ip from Dos and in Windows
2) FTP from Windows (to unix and IBM Mainframe)
3) NFS from Dos and in Windows
4) Sybase NetLib compatibility
5) Telnet VT220
6) Telnet 3270 (Mainframe Terminal Emulation)
7) LPR/LPD (local printer used as a networked unix printer)
Any advice would be appreciate. I do not subscribe to this newsgroup so
please send e-mail to me directly. TIA

---
dude@traider.ersys.edmonton.ab.ca (Adam Pearse)
Traiders of the Lost .ARC! - Edmonton, Alberta, Canada

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1994 06:08:52 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating a TCP/IP product - HELP!!!!

Adam Pearse (dude@traider.ersys.edmonton.ab.ca) wrote:
: Hi, I need the Net's vast experience in choosing a TCP/IP product.   
: Presently, Wollongong, FTP, Netmanage, Beame & Whiteside, and SUN PC-NFS
: are the companies I am evaluating. Here is the criteria:
: 1) tcp/ip from Dos and in Windows
: 2) FTP from Windows (to unix and IBM Mainframe)
: 3) NFS from Dos and in Windows
: 4) Sybase NetLib compatibility
: 5) Telnet VT220
: 6) Telnet 3270 (Mainframe Terminal Emulation)
: 7) LPR/LPD (local printer used as a networked unix printer)
: Any advice would be appreciate. I do not subscribe to this newsgroup so
: please send e-mail to me directly. TIA

I did a market search some time ago, based on the recent magazine shoot outs and
what company litterature said: Wollongong had the highest performance, smallest TSR's or what ever and the most expensive product.  There literature was impresive and they've been the buisness for along time.  I've had 2nd party bad
experience with FTP and their TFTP source code for Borland/DOS was low
quality and difficult to work with.

No actual useage of any of these products to report.


: ---
: dude@traider.ersys.edmonton.ab.ca (Adam Pearse)
: Traiders of the Lost .ARC! - Edmonton, Alberta, Canada

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1994 06:09:49 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   AF_UNIX VS pipes your inputs



I've developed a TCP/UDP/IP library for IPC that provides 
box transparency, something standard Unix IPC facilities
don't provide (that is inter-box communication transparently).

But when the client and server are on the same box there's
a significant performance difference between AF_INET, AF_UNIX
and just using simple packet framing through a named pipe!!!

Here's some numbers:

486/66Mhz SVR4.2 Unixware: one way pkts from client to server (stop)

UDP/IP (66 byte pkts)	(between two machines)	666 Pkts/sec
			(local machine)		714 Pkts/sec

TCP/IP (66 byte pkts)	(between two machines)	434 Pkts/sec
			(local machine)		400 Pkts/sec
			
			(not sure if this local # is good?)

Named Pipes (66 byte pkts)(local machine)	1162 Pkts/sec

And FYI using the RPC facility on Unixware:

RPC Via UDP/IP (66 byte pkts)	(between two machines)	185 Pkts/sec
				(local machine)		303 Pkts/sec

RPC Via TCP/IP (66 byte pkts)	(between two machines)	129 Pkts/sec
				(local machine)		238 Pkts/sec
			

You can clearly see that if your tasks are on the local machine a library
that packaged and hid the internals of IPC should test if target machine
== localhost etc..  and use a native Unix IPC facility instead of AF_INET.

My question is: what am I sacrificing or loosing when I use
simple packet framing via a named pipe and read/write for IPC 
VS AF_UNIX and using the Berleley sockets API.

Obviously alot of operating system over head of AF_UNIX vs
native read/write to your own named pipe, but what else??



-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 16:51:53 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.sys.unisys
Subject:   Re: file permissions during ftp transfers

In article <loss.78.000AAFA2@husky.bloomu.edu> loss@husky.bloomu.edu (Doug Loss) writes:
>   In a project I'm working on, we have to transfer a file using ftp to our 
>Unisys 2200 mainframe computer running NFS 2200.  Everything transfers OK, but 
>the file permissions on the transferred file are -rx-r-----.  What determines 
>the permissions for an ftped file?  I've tried changing the umask in the 
>.profile file for the ID used, with no success.  Is there an ftp protocol 
>command that will do the equivalent of chmod on a newly uploaded file?  I'd 
>appreciate any help anyone can give.

Since the FTP daemon doesn't start a shell, the .profile can't possibly
have any effect.

The permissions on files created by FTP are normally determined by the
umask of the ftpd process, which just inherits it from the shell that runs
/etc/rc, etc.  A simple way to fix this is to replace ftpd in your
/etc/inetd.conf with a shell script that sets the umask and then invokes
ftpd.

I think the wustl version of ftpd provides the ability to configure the
umask dynamically.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 17:30:28 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip,mi.misc,mi.wanted
Subject:   Re: DLPI spec needed

Eric McGlohon (dekard@garnet.msen.com) wrote:
: I'm looking for the DLPI Specification for TCP/IP.  Does anyone know
: where I can find this?  I doubt that Borders carries it....

There's details about it in the Solaris FAQ, which points to a paper
by Neal Nuckolls of Sun Internet Engineering.  See
	file://opcom.sun.ca/pub/drivers/dlpi/*
which includes a spec, also
	file://ftp.ui.org/pub/osi/*
which has more details of some sort on dlpi, 'npi', and 'tpi', and
also
	file://gatekeeper.dec.com/pub/net/ip/nfs
which has sample code as a part of 'netwatch'.

--Ed


  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)
 msen info addresses:   info@msen.com - $20/mo public access Internet
 			occ-info@msen.com - Online Career Center jobs database

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 17:38:23 GMT
From:      evansmp@mb4803.aston.ac.uk (Mark Evans)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

Tim Newsham (newsham@uhunix.uhcc.Hawaii.Edu) wrote:

: No, this is true.  NFS uses RPC's (usually UDP packets) to do its
: many operations.  You can with a little effort write an NFS client
: that resides entirely in userspace (instead of it being in the
: kernel).  Now this part isnt so bad, what is bad is that you
: can do this as non-root against many nfs servers.  This means

Ignoring the (trivial) check of is the originating port number
less than 1024

: you can look at NFS volumes as any uid (that NFS allows) even
: though you are just a normal user.  All you need is an account
: on a machine that can mount the volume from another machine
: and source+compiler or a binary.


-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 17:44:55 GMT
From:      evansmp@mb4803.aston.ac.uk (Mark Evans)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: ICMP destination unreachable on the loopback??

Doug Siebert (dsiebert@icaen.uiowa.edu) wrote:

: Last night I picked up an interesting tool that was mentioned in the
: comp.unix.security group in the ICMP bombs thread.  (It is called icmpinfo
: and is available via anon ftp from hplyot.opspm.circe.fr)  What it does is
: show all the ICMP traffic on your machine, in particular the ICMPs for
: destination unreachable.  The theory is that you can check up on the ICMP
: destination unreachables reaching your machine and see if you are being
: "bombed".  (The latest HP-UX kernel patches should fix this problem, BTW,
: if it is happening or has happened to you)

Quite a simple program is needed to do this.

: I noticed a fair number of ICMP destination unreachables coming from 127.0.0.1
: to 127.0.0.1 on my machine.  What is happening is that applications running
: on this machine communicate via UDP sockets bound to the loopback interface,
: and when one process exits when another is composing a message to be sent
: to it an ICMP destination unreachable results.  Is this supposed to happen
: from merely attempting to send a UDP packet to a port that is currently not
: bound by any process?  I don't know if this is a bug or not, but it seems
: odd to me.  I wish I could get this information on the return status from the
: sendto() call, it would avoid the need to have it time out, but this could
: probably only work for local sockets.

The only time it is illegal to generate an ICMP destination unreachable
is when sending to a broadcast or multicast address.

It is perfectly valid to send a destination unreactable in response to
a unicast datagram. Otherwise the sender would not know that it had
nowhere to send to.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 18:10:54 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   TLI programming

I am trying to learn to program using the TLI interface.  I had a few questions
and I am hoping somebody could help me in this regards or point me to
some good source that I could use for examples.  The questions are as follows:

1.  How does one change the service type using the TLI interface?  How can
one request for Connection Oriented service without orderly release?

2.  How does set options such as SO_LINGER, SO_KEEPALIVE, SO_BROADCAST etc?

3.  How can one set IP options?


My email address is brama@ncratl.atlantaga.ncr.com.
-- 

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1994 19:36:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: ICMP destination unreachable on the loopback??

In article <1994Feb2.014230.6729@icaen.uiowa.edu> dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
>I noticed a fair number of ICMP destination unreachables coming from 127.0.0.1
>to 127.0.0.1 on my machine.  What is happening is that applications running
>on this machine communicate via UDP sockets bound to the loopback interface,
>and when one process exits when another is composing a message to be sent
>to it an ICMP destination unreachable results.  Is this supposed to happen
>from merely attempting to send a UDP packet to a port that is currently not
>bound by any process?  I don't know if this is a bug or not, but it seems
>odd to me.  

Yes, it's normal.  If a UDP packet is received for an unbound port, the
destination host sends an ICMP Destination Unreachable back, with the
subtype set to Port Unreachable.  This is the UDP equivalent to TCP's RST
reply; since UDP doesn't have packet type flags, it uses ICMP for this.

>	     I wish I could get this information on the return status from the
>sendto() call, it would avoid the need to have it time out, but this could
>probably only work for local sockets.

Sendto() is asynchronous, so it returns immediately without waiting for a
reply from the remote host.  However, if you use a connected datagram
socket, the Port Unreachable will cause the socket to be marked with an
error state, and the next use of it will return an error.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 20:20:15 GMT
From:      cawilco@afterlife.ncsc.mil (Chris A. Wilcox)
To:        comp.protocols.tcp-ip
Subject:   Van Jacobsons TCP modifications

Sorry if this is a FAQ (I couldn't find the FAQ for this group), but I have
a couple of questions regarding Van Jacobson's mods to TCP:

1) Are they available to the masses? If so, where?
2) Do you need to have BSD source to take advantage of them?

I'd like to take a look at the changes he has made, and see if it makes any
performance difference on our machines, but I don't have access to BSD
source. Am I hosed? Thanks in advance for any info...
-- 
Chris Wilcox                |"You've been demoted from First Tiger to Tiger
Dept. of Defense            | bulk rate!"
cawilco@afterlife.ncsc.mil  |                                        Calvin
  The views represented here probably aren't held by the DoD. Get over it.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 20:28:15 GMT
From:      consol@world.std.com (CSI ContractSolutions)
To:        comp.protocols.tcp-ip
Subject:   ?? Hostname, Localhost, Internet_Address ????

I'm fairly new to TCP/IP and believe it or not I'm installing one.
I have few questions if anyone like to help me out.
I'm installing TCP/IP to run PPP to get connected to INternet.

1. What is a hostname(is this a provider's name or address for internet) ?

2.  What is a Localhost(is this my server?)?

3.  What is INternet_address(is this address from me or the provider)?

4.  When I run "tcp start" at the # prompt, I get "ifconfig: localhost: 
bad value" message.  is this normal or what am I doing wrong?

Thanks much.

Young Kim
consol@world.std.com 


-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 21:36:48 GMT
From:      911288c@dragon.acadiau.ca (EDwin Chung)
To:        comp.protocols.tcp-ip
Subject:   question on ftp & telnet


Dear friends,

	
	I am a student study in university. I would like to ask
	u some question about novell netware.  How FTP & TELNET
	implemented in the top-down layed protocols?
	I didn't find anything saying about the protocol in
	netware.... is it using OSI or ???
	I know that actually ftp & telnet are the same thing
	; but why implemented in a different way ?
	If u can, pls suggest me some info; is there on the
	network ?? or some book which is good for me ...

	Thank you !!
						edwin

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Feb 1994 21:56:32 GMT
From:      bob@monster.apd.saic.com (Bob Price)
To:        comp.protocols.tcp-ip
Subject:   kill a socket?

Does anyone know a way to kill (ie, erase all knowledge of) a
listening socket after the process that was listening has died?

I have some processes on Unix (SysVR4) that listen for connections
from DOS clients running PC/TCP and if things don't terminate just
right the listening socket stays around, sometimes for a few minutes,
sometimes until the next reboot.  This is a pain because I can't
restart the application when this happens without making everyone
change to use a different port number.

Any suggestions?

Thanks,
bob@brigand.apd.saic.com


-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 94 23:47:16 GMT
From:      efb@spc2ed0.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Vendor.ethers


 looking for the list of current vendor codes part of ethernet addresses ..

Used to be on vax.ftp.com .. cant find it .. Is there an ftp / gopher / Web
server which has them ??? 

Thnx /Ev/

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

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 00:33:32 GMT
From:      brian@dn.itg.telecom.com.au (Brian Miller)
To:        comp.protocols.tcp-ip
Subject:   Checking returned data in a PING

Hi,

I have just come accross a problem that had a few people in our networking area
stumped for some time.  We are running TCP/IP for MVS on our IBM mainframe, and
were unable to PING from the mainframe to one particular IBM PC.  We were able
to ping to other PC's on the same subnet as the PC, and routers and other hosts
were able to ping the offending PC.

What the problem eventually turned out to be was the PC was responding to the
ping, but the data returned in the ping was different.  The PC is running
PC-NFS.  This problem only occures if the amount of data in the ping was
greater than 222 bytes, and as the IBM mainframe defaults to 256 bytes, we
always saw the problem until we over rode the default with a smaller number.

What I am interested in finding out, is why we could sucessfully ping this PC
from our SUN SPARC with a packet length of 500 bytes OK, even though the PC
didn't return the correct bytes in the ping packet?  Is the SUN being
a bit slack in its checking of the ping response, or is the IBM mainframe
being to millitant?

Brian
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brian Miller                            Telstra  (Telecom Australia)
CDN Product Group                       30/242 Exhibition Street
ITG Data Networks                       Melbourne, VIC 3000
brian@netboss.dn.itg.telecom.com.au     Australia
Tel: +61-3-632-3883                     FAX: +61-3-632-3857
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1994 10:41:40 -0500
From:      aem@symbiosis.ahp.com (a.e.mossberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating a TCP/IP product - HELP!!!!

cgi@crl.com (Paul Smith) writes:

>I did a market search some time ago, based on the recent magazine shoot outs and
>what company litterature said: Wollongong had the highest performance, smallest TSR's or what ever and the most expensive product.  There literature was impresive and they've been the buisness for along time.  I've had 2nd party bad
>experience with FTP and their TFTP source code for Borland/DOS was low
>quality and difficult to work with.
 
>No actual useage of any of these products to report.

I have evaluated all of the products except Wollongong and found FTP's
PC/TCP to be the most robust and feature-rich.  I recommend it as the
continued leader in TCP/IP for PC's.  B&W and NetManage's Chameleon were
suitable products if you only need TCP/IP from inside of Windows, but if
you need a mutli-universe implementation, go with PC/TCP.  

Wollongong, BTW, I had a bad experience with: can you say 3B2?

aem 
-- 
andrew mossberg * symbiosis corporation * miami florida * 305-597-4110
fax: (305) 597-4002 * MD5OfPublicKey: 15784D117CC103912AEC427A3A99BA83

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 94 02:30:23 GMT
From:      krishna@pongo (Kurapati SriKrishna)
To:        comp.protocols.tcp-ip
Subject:   Looking for Public domain C++ implementaion of TCP/IP

Hi!

	I am looking for a ftp liocation for C++ TCP/IP implemetation.
	
	Thanks for the help.

	Please mail the response to

	krishna@anubis.network.com


-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 03:57:19 GMT
From:      dac@hcsaust.com.au
To:        comp.sys.unisys,comp.protocols.tcp-ip
Subject:   Re: Lpr needed for Unisys A Series TCP/IP

In article <grimes.759578125@access1> grimes@access1.digex.net (Seth Grimes) writes:
>A colleague asked my to post the following inquiry:
>
>Given that Unisys has neither released lpd/lpr for TCP/IP, nor 
>admitted to having scheduled development for this "product", I would 
>like to find out if there's anybody in the world who has developped / 
>adapted lpd/ lpr for the A Series TCP/IP?  We are (at this stage) 
>interested in any product, commercial, academic, or private.
>
>Thanks for any and all help.
I think a company called optimation here in Aust has done some work on it - they may
even have seen your post FAx is 6135211733

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 10:11:53 +0000
From:      alistair@ichthya.demon.co.uk (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   FTP of password-protected datasets

Having read the RFC on FTP, I noticed that '331' (i.e. password required) wasn't
a legal response to a GET or PUT. This seems odd given that many systems (I'm
thinking about MVS at least) have password protection on individual files. Do
FTP clients in general accept 331 in practice at this stage? Has this issue been
resolved another way?

-- 
Alistair Bell,
Brown's Operating System Services Ltd.,
St. Agnes House,
Cresswell Park,
Blackheath,
London
SE3 9RD.
Tel. 081-852 3299.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1994 11:43:58 GMT
From:      jonathan@leland.Stanford.EDU (Jonathan Stone)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: ICMP destination unreachable on the loopback??

In article <2iovcaINNbk8@early-bird.think.com>, barmar@think.com
 (Barry Margolin) writes:
|> In article <1994Feb2.014230.6729@icaen.uiowa.edu>
|> dsiebert@icaen.uiowa.edu (Doug Siebert) writes:

[elided]

|> >	     I wish I could get this information on the return status from the
|> >sendto() call, it would avoid the need to have it time out, but this could
|> >probably only work for local sockets.
|> 
|> Sendto() is asynchronous, so it returns immediately without waiting for a
|> reply from the remote host.  However, if you use a connected datagram
|> socket, the Port Unreachable will cause the socket to be marked with an
|> error state, and the next use of it will return an error.

Well, mostly.

In BSD netinet code, icmp_input handles a PORT_UNREACHABLE message by
calling the IP protocol control input routine with a struct sockaddr_in
constructed from the ICMP message:

	icmpsrc.sin_addr = icp->icmp_ip.ip_dst;
	icmpsrc.sin_port = ((struct udpiphdr *)&(icp->icmp_ip))->ui_dport;
	if (ctlfunc = inetsw[ip_protox[icp->icmp_ip.ip_p]].pr_ctlinput)

If the offending packet was a UDP packet, this calls udp_ctlinput(),
which calls in_pcbnotify().  in_pcbnotify is an iterator; it applies
a notify function to all "affected" pcbs -- i.e., to local
sockets affected by the UDP close.


In 4bsd through 4.3-Tahoe, inclusive, the BSD  code didn't
check *PORT* numbers at all; just host addreses.
All PCBs with addresses matching the IP address of the unreachable
port were notified with an error. I guess this is why Sendmail with
identd support doesn't work on Ultrix. It still has the old in_pcbnotify()
code, which is also used for TCP connections; and so a "PORT UNREACHABLE"
ICMP message  from a host, in response to an attempt to open
a TCP connection to an identd on the SMTP client, also closes
the SMTP session's TCP connection...

The behaviour Barry describes is shown by SunOS 4.1.x systems.
Sun apparently "fixed" the code to get this case right for
connected sockets; but breaks PORT_UNREACHABLE messages
to non-connected (UDP) sockets. 4.3BSD-Reno's in_pcbnotify() has 
a more correct fix, which explicitly tests for unbound local
ports or addresses[*], and doesn't require that they match;
but vendors don't seem to have caught that yet.

[*] Actually, non-zero ports or addreses; which is much the same.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 13:13:35 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobsons TCP modifications

> Sorry if this is a FAQ (I couldn't find the FAQ for this group), but I have
> a couple of questions regarding Van Jacobson's mods to TCP:
>
> 1) Are they available to the masses? If so, where?
> 2) Do you need to have BSD source to take advantage of them?
>
> I'd like to take a look at the changes he has made, and see if it makes any
> performance difference on our machines, but I don't have access to BSD
> source. Am I hosed? Thanks in advance for any info...

What *exact* changes are you referring to?  If it's congestion avoidance
and slow start, that code is in the publcily-available Net/2 sources
(ftp.uu.net is one site, in the systems/unix/bsd-sources directory; there
are probably other ftp sites worldwide).  If it's header prediciton, then
that's also in the Net/2 sources.  If it's fast-retransmit, fast-recovery,
then the description and code modifications were posted to this Newsgroup
just days ago by myself.  That code is also in the Net/2 sources.

	Rich Stevens  (rstevens@noao.edu)

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1994 14:10:45 GMT
From:      kapson@rtsg.mot.com (John D Kapson)
To:        comp.lang.c++,comp.client-server,comp.protocols.tcp-ip,misc.jobs.offered
Subject:   Re: *** Client/server C++/C/UNIX Programmer Nationwide ***


    Now why would I want to work for anyone who isn't bright enough
    to post his job offers to misc.jobs.* groups instead of the comp.*
    hierarchy?  Was the last email I sent explaining which groups
    are which too confusing for him?

    Followups.


In article <2ioqfp$4ju@news.cerf.net>,
Brady Hartman <bhartman@nic.cerf.net> wrote:
>NOTE: WE DONT HIRE RECENT GRADS.
>
>Feel free to send your resume for Nationwide openings.
>----------------------------------------------------------------
>(*) Position:	  C++/C/UNIX Client/Server Software Engineer  
>     Location(s): Nationwide
>                  Programmer with a minimum of three years industry 
>                  experience is required. This individual will
>                  implement key system components of a
>                  state-of-the art client/server system. 
>                  Knowledge of C++ or object-oriented techniques
>                  is a plus.
>
>PLEASE NOTE: THERE ARE NO ENTRY-LEVEL POSITIONS OPEN. YOU MUST HAVE 
>AT LEAST TWO (2) YEARS RELEVANT INDUSTRY EXPERIENCE IN C/UNIX .
>THE MAJORITY OF YOUR EXPERIENCE MUST HAVE BEEN IN COMMERCIAL 
>ENVIRONMENTS.  PLEASE NOTE: E-MAIL RESUMES ARE ENCOURAGED. 
>ASCII ONLY PLEASE.  
>
>All resumes will be held in strict confidence. We will not release 
>your resume to the client, unless we first contact you and have 
>your permission. 
>
>Ategra Systems
>Southeastern Regional Office
>478 E. Altamonte Drive
>Suite 108-A
>Altamonte Springs, FL. 32701
>EMAIL: bhartman@cerf.net  
>-- 



-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 Feb 94 10:51:07 RSA
From:      030NEILV@Witsvma.wits.ac.za (Neil van der Merwe)
To:        comp.protocols.tcp-ip
Subject:   Networking a COMPAQ (help)

Hi,
I have been up until now successfully networking a 386 COMPAQ PC on
an ethernet Novell 3.11 lan using the external Zircon adaptor and
the supplied software.  I have been using the IPXEE and NETX drivers.
I now however need to load the packet drivers supplied and this I
can do, but then the manual tells me to load the ethernet kernel,
ie ethdrv.com.  This is not supplied with the Zircon adaptor, but
according to the manual is available with TC/TCP.  We are however
running CU/TCP.
 
Is there a way to get around this problem, or are there kernal drivers
for CU/TCP available.  I need this machine to be able to talk IPX
(for on the lan) and IP numbers.  On my other workstations I don't
have these problems, as I simply load IPXODI and ODIPKT.
Any suggestions?
 
Cheers for now,
Neil
 

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 14:26:39 GMT
From:      beeler@tech.ascom.ch (Reto Beeler)
To:        comp.protocols.tcp-ip
Subject:   How to access raw TCP/IP information on a SUN ?


I would like to write a specific IP-tunnel application.
Therefore I am looking for a driver for SUNs, which takes packets 
from the IP i/f and hands them over to a user process.
Where is such a thing to be found ?

Thanks
   Reto

---------------------------------------------------------------------- 
 Reto Beeler tel:+41 31 999 4267  EMail: beeler@tech.ascom.ch
 ASCOM TECH  fax:+41 31 999 3607  Morgenstr.129,3018 Bern,Switzerland
----------------------------------------------------------------------


-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 94 14:59:58 GMT
From:      mcla@btzp16 (CLAEYS Marc)
To:        comp.protocols.tcp-ip
Subject:   IP broadcast on ISC V.3.2



--
An optimist is a colleague that is not well informed.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 15:03:16 GMT
From:      peter@devvax.twgeur.com (Peter Cox)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses

In article <2g9sm2$s7g@crchh463.bnr.ca> baji@bnr.ca (Baji Edupuganty) writes:
>From: baji@bnr.ca (Baji Edupuganty)
>Subject: Hashing of IP addresses
>Date: 3 Jan 1994 13:46:10 -0600
>Keywords: TCP/IP, CLNP


>I'm working on an application that will key off of IP addresses; therefore
>I'm looking for a hash alg. that will hash IP addresses to something in the
>range 2000. Anyone, know of any PD algs, or code that I can leverage? Any 
>help will be appreciated. My e-mail addr is "baji@bnr.ca". Thank you.


As IP addresses are (on most systems) internally represented as 32 bit values,
you could use any hashing alrogithm on those values.

Alternatively just use the host part of the IP address, on a class C net you
than have 256 unique values without the need for any hashing. This won't work 
on Class Bs and As but may be a good enough approach.



+-------------------------+-----------------------------------------------+
| Peter Cox               | European Network Engineering                  |
| peter@devvax.twgeur.com | Wokingham, Berks, UK                          |
|                         | 44-734-772944                                 |
 +-------------------------+-----------------------------------------------+ 

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 15:23:09 +0000
From:      dherdman@osil.demon.co.uk (Dave G Herdman)
To:        comp.protocols.tcp-ip
Subject:   TCP socket SO_KEEPALIVE problem

I have developed an application that is used to communicate between 
windows 3.1 apps and a UNIX host. One problem I have is that users
sometimes just turn off their PCs and the UNIX end doesnt know that
they are gone.This causes a problem as the UNIX end should do some tidying
up when a PC goes or dies. I was thinking of implementing a timed poll
message between client and server when I came across the SO_KEEPALIVE option
for STREAM sockets.This seemed to be just whate I needed so I thought
I would try it out. I set the option up at the UNIX end with

  ret = setsockopt(sock,SOL_SOCKET,SO_KEEPALIVE,&kaflag,sizeof(kaflag));
  if (ret == -1)
  {
	....


 Later on the UNIX server code spends most of its time sitting in a 
 select call. I thought the select would return with an execption 
 condition on the socket that Keepalive had failed on. However it
 seems to do nothing ?

   FD_ZERO(&rd_sock_set);
   FD_ZERO(&wrt_sock_set);
   FD_ZERO(&excp_sock_set);

   FD_SET(sock,&rd_sock_set);
   FD_SET(sock,&wrt_sock_set);
   FD_SET(sock,&excp_sock_set);

   ret = select(getdtablesize(),&rd_sock_set,&wrt_sock_set,
			&excp_sock_set,NULL);


 (BTW I reboot the PC at the other end to
 try to cause a failure) What am I doing wrong ??

+--------------------------------------------------------------+
|  Dave G Herdman OSIL    inet email dherdman@osil.demon.co.uk |
|             phone UK  (44) 494 765716                        |
+--------------------------------------------------------------+

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 15:24:04 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: ICMP destination unreachable on the loopback??

> The behaviour Barry describes is shown by SunOS 4.1.x systems.
> Sun apparently "fixed" the code to get this case right for
> connected sockets; but breaks PORT_UNREACHABLE messages
> to non-connected (UDP) sockets. 4.3BSD-Reno's in_pcbnotify() has 
> a more correct fix, which explicitly tests for unbound local
> ports or addresses[*], and doesn't require that they match;
> but vendors don't seem to have caught that yet.
>
> [*] Actually, non-zero ports or addreses; which is much the same.

If you're implying that Reno and later will deliver an asynchronous error
(such as port unreachable) to an unconnected UDP socket, I don't think
that's the case.  In fact, I'm not aware of any BSD-derived system that
delivers asynchronous errors to an unconnected UDP socket.

First, the third argument to in_pcbnotify(), fport, is set by udp_ctlinput()
to be the actual destination port number from the UDP header in the offending
UDP datagram.  This means that the test

	(fport && inp->inp_fport != fport)) {

will be true, and the PCB is skipped.  (Actually, if the socket is not
connected, the earlier tests of the foreign address and local address
will stop the if-tests sooner.)  This is from Net/2, which is based on
Reno, and 4.4 has the same test.

Second, I just ran this test under Net/2 and 4.4BSD and on both systems
the port unreachable is *not* delivered to an unconnected UDP socket.
It is, of course, delivered to a connected UDP socket.

What I also found out in my tests is that Solaris 2.3 doesn't deliver the
port unreachable even to a connected UDP socket.  Figure that one out.
Something else that changes from 4.x to 5.x, or is this a bug?

	Rich Stevens  (rstevens@noao.edu)

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 16:33:52 GMT
From:      consol@world.std.com (CSI ContractSolutions)
To:        comp.protocols.tcp-ip
Subject:   ALTOS UNIX SYSTEM V5000 --> Internet ???????


I have Altos Unix System v5000(OS is based on SCO Unix).  I'm trying to 
install TPC/IP(Altos) and PPP(MorningStar) so I can get connected to 
internet.  I'm running in to some problems.

1.  When I run "tcp start", I get an error message like "ifconfig: 
localhost: bad value".  I can't figure out what I can do.

/etc/hosts contains 200.0.0.1 unix  (unix is my servername)
/etc/networks contains unix.corico.com 132.147.160.1 (corico is my 
company name and 132.147.160.1 is given when I ran "mkdev en0")

2.  My modem is attached on ser1(tty1A).  I can't activate it with TCP/IP 
and PPP.  What am I doing??

3.  Has any one out there configured Altos Unix before??  If you did 
PLEASE help me.

Thank you goes out to people who gave me answers to the stupid questions 
I posted and Thank you in advance to people whos willing to help.

Young Kim

consol@world.std.com
1.800.998.2741 (Voice)

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 18:11:53 +0000
From:      alistair@ichthya.demon.co.uk (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: Evaluating a TCP/IP product - HELP!!!!

In article <2ir5vkINNhdr@symbi1.symbiosis.ahp.com> aem@symbiosis.ahp.com writes:

>I have evaluated all of the products except Wollongong and found FTP's
>PC/TCP to be the most robust and feature-rich.  I recommend it as the
>continued leader in TCP/IP for PC's.  B&W and NetManage's Chameleon were
>suitable products if you only need TCP/IP from inside of Windows, but if
>you need a mutli-universe implementation, go with PC/TCP.  

We use PC/TCP 2.2 and find it to be anything but robust (We've had a problem
open with FTP for about six months now...), especially in the Windows and NFS
sides of it. 2.3 might be better though.

-- 
Alistair Bell,
Brown's Operating System Services Ltd.,
St. Agnes House,
Cresswell Park,
Blackheath,
London
SE3 9RD.
Tel. 081-852 3299.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Feb 1994 19:08:19 GMT
From:      allegro@vnet.net (Stephen Durfee)
To:        comp.protocols.tcp-ip
Subject:   << Read Me >>

I'm running IBM TCP/IP 2.0 for OS/2 2.1 while connecting to a commercial
Internet provider via a SLIP 14.4k modem connection.  These are the
elements:

1)   I have a DOS-based BBS package called Wildcat v3.90.

2)   I'm using a third party BBS utility called WildUUCP which converts
      UUCP mail format into a format that Wildcat can understand.  The
      BBS user sees a normal BBS message with no Internet header garbage.

3)   I need to simulate getting Usenet mail and Internet mail into a
      directory for processing by WildUUCP.  This is typically done by
      using a DOS-based UUCICO program such as Waffle and a UUCP
      dial-up account.

4)  This brings us to the solution.  How do I do it with SLIP?  Can I
     FTP and download the Usenet mail from my provider and then place
     the mail into the directory for processing?

Any help would be highly appreciated.  Thanks.

=|-) Steve




-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 94 08:53:34 EST
From:      longm@firnvx.firn.edu
To:        comp.protocols.tcp-ip
Subject:   Source code for Merits PPP Driver???

I am looking for the source code for Merits PPP Packet Driver.  E-mail me if
anyone knows where I can get it from.
-- 
# Michael Long                     ______    __     _____        ____    __
# Fla. Info. Resource Network     |  ____|  |  |   |   _  \     |    \  |  |
# Sr. Systems Programmer          |  |_     |  |   |  |_|  |    |  |\ \ |  |
# Go Seminoles!! Scalp-em!!       |   _|    |  |   |   __ <     |  | \ \|  |
# Florida State University        |  |      |  |   |  |  \ \    |  |  \ \  |
# e-mail : longm@firnvx.firn.edu  |__|    O |__| O |__|  |__| O |__|   \___| O

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 1994 16:40:43 GMT
From:      eks@vki68.aar-vki.dk (Eigil Krogh Sorensen)
To:        comp.protocols.nfs,ieee.pcnfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NFS server to use with PC/TCP ???

Is there a NFS server that can be used on PCs and run together with
PC/TCP so PC disk(partitions) can be exported from the PC and
mounted on other computers ?

We use both DOS and Windows.

If so would you please inform me the name of the product and evt.
where I can get it.


Thank you in advance

Eigil Krogh Sorensen

---------------------------------------------------------------------
        Address:	Water Quality Institute
                        Science Park Aarhus
                        10, Gustav Wieds Vej
                        DK-8000 Aarhus C
                        DENMARK.

        Phone:          +45   86 20 20 00    or
                        +45   86 20 20 11  local  2114

        Fax:            +45   86 19 75 11

	E-mail:		eks@aar-vki.dk
----------------------------------------------------------------------

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 94 18:36:09 GMT
From:      werme@alingo.uucp (Eric Werme USSG)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

chris@marge.mikom.csir.co.za (Chris zwanepoel) writes:

>I have heard that it is actually very easy to by-pass the /etc/mount
>command and write your own RPC calls to download data from any
>"exported" file-system.

In some NFS servers (Sun, DEC, etc.) the /etc/exports information is
saved in the kernel and checked against incoming requests.  I.e. if
mountd refuses you access to a file system, so will NFS.

>Apparently some universities now refrain
>from using NFS on campus, because of students drawing off any data
>they want, even from not-so-widely-exported volumes, just by writing
>the necessary RPC calls, and not doing the mount call first, thus
>by-passing the initial authentication.

You still have the problem of people able to guess the generation number
to come up with a valid file handle, as other poeple have mentioned.

Before you write off NFS as being unsecure, make sure all the other
nodes in your network aren't pretending to be someone else's IP address,
and aren't running packet filter applications to eavesdrop on NFS traffic,
telnet passwords, ftp passwords, or whatnot.  Given that desktop
machines can consume a full Ethernet load these days, guessing generation
numbers hardly seems worth the effort.

-- 
Eric (Ric) Werme		| werme@zk3.dec.com
Digital Equipment Corp.		| This space intentionally left blank.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1994 01:02:16 GMT
From:      lam@mrcnext.cso.uiuc.edu (Ken Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: IPX Spoofing

evansmp@mb48026.aston.ac.uk (Mark Evans) writes:

>Jeff Milloy (p00633@psilink.com) wrote:
 [stuff deleted]
>: I am interested in implementing IPX Spoofing (for Novell clients over 
>: WAN links).  Is there a standard set of messages that need to be 
>: spoofed (SAP, ???).  Can anyone direct me to some literature, algoritm, 
>: or code that would help me implement the spoofing?
>
>comp.sys.novell
>(considering they are the only people to use IPX)

Also consider comp.security.misc

But for sure, prepare yourself for a firestorm.  As for spoofing, there have
been ways to spoof Netware servers, but that avenue was "closed" by using the
packet signatures builtin (usage optional--performance degredation) to 
Netware 3.12 and 4.x as well as an free-fix add-on NLM for 3.11.  I would
assume that if you are routing IPX over a WAN, these same security measures
would provide sufficient protection as they do over a LAN.

-Ken

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      05 Feb 1994 11:16:07 GMT
From:      prep@yarrow.wt.uwa.edu.au (Paul Repacholi)
To:        alt.security,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Both ACK and ICMP UNREACH (Re: icmp (bombs))

In article <2iofgl$c12@nz12.rz.uni-karlsruhe.de> uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz) writes:
> 
> In article <CKK75G.FC7@news.hawaii.edu>,
> Tim Newsham <newsham@uhunix.uhcc.Hawaii.Edu> wrote:
> > is included in the icmp packet.  Also, an ICMP UNREACH should come
> > in before any ACK came in (would you ever receive both an ACK and
> > an ICMP error for the same packet?  even if you did?  shouldnt
> > you believe the ACK over the ICMP?).  So at this point you still
> 
> This is disputable. If you trust the ACK over the ICMP, you're
> vulnerable to spoofing of the other host when in fact it is really
> unreachable - just the other way round than with ICMP bombing. You
> can't have it both ways.
> 
> Getting both an ACK and an ICMP UNREACH can indicate at least these
> four situations:
> - the ICMP is spoofed (ICMP bomb)
> - the ACK is spoofed
> - the software on the peer host is broken
> - a temporary routing problem (yes, this *should* not happen)

Depends on your definition of 'problem'. Ie the ACKing packet could
have hit a dead ( just ) machine, your UNREACH come from a machine
on your side. The ACKing packet is them re-transmitted via another
path and arrives after the ICMP packet.

> So what is the correct way of dealing with this problem, if any? Of
> course, any ICMP UNREACH should be verified, but what if it matches
> the ACK?

The correct way is to wait for the connections to time-out and hit
their re-transmit limit. The ACK is _defined_ as proof that your packet
got through, and that the ACK-packet got back to you. This should be
regarded as an existence proof that there is PROBABLY still a path.
All nak type stuff should be treated as a hint that you can probably
timeout now, rather than waiting. Doing an 'soon' re-transmit of
the oldest unacked packet ONLY would be a good place to start.

--
~Paul

prep@yarrow.wt.uwa.edu.au ( prefered )
zrepachol@cc.curtin.edu.au

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 94 11:22:19 +0100
From:      mvdl@et.tudelft.nl (M. van der Laan)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for MSDOS BBS?

In article <1994Feb4.215333.24@kodiak.gvltec.edu>, stognels@kodiak.gvltec.edu writes:

> What software would be recommended for adding a door to a BBS (running 
> on an IBM-PC) to allow a SLIP internet connection.  Or, what MS-DOS BBS
> software has SLIP support built-in or available? 

KA9Q is a package that will allow you to setup a SLIP connection.

Michel.

------------------------------------------------------------------------------
   Michel van der Laan                   |   [ Dutch & Dangerous! ]  
   At Dept. of Electrical Engineering    :   MVDL@ET.TUDelft.NL
   At System affairs WLINK BBS domain    :   system@wlink.nl / wtrlnd!system
   At BBS Waterland [+31 (2990) 40202]   :   Michel@wlink.nl
   At BBS Waterland on FidoNet           :   2:280/802.16  
   * BBS Waterland: 12 lines, waterland.wlink.nl, 2:280/802 and 2:280/803 *

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Feb 1994 13:14:24 GMT
From:      rstone@superior.carleton.ca (Ron Stone)
To:        comp.protocols.tcp-ip
Subject:   Winsock Spec compliant stacks

Hi, 

My understanding a few months ago was that ICPM was not part of the
winsock spec. I hear now that that has changed. If so, can anyone tell
me of 100% compatible stacks on the market, with full winsock ICMP
functionality. Also, if the current spec is available on the net,
could someone point me to it, or mail a copy.


Thanks in advance.

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

Ron Stone                                       rstone@ccs.carleton.ca

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1994 14:43:34 GMT
From:      stevef@medusa.aom.bt.co.uk (Steve Fosdick)
To:        comp.programming,comp.protocols.misc,comp.protocols.tcp-ip,comp.terminals,comp.unix.questions
Subject:   Re: Telnet servers: How do I write one?

Geoffrey Talvola (gtalvola@bbn.com) wrote:

> I would like to experiment with writing a telnet server.  For instance
> I can say "telnet 141.212.196.79 3000" and get connected to an
> interactive weather server from University of Michigan.  But this
> server only operates in line mode; what I'd like to do is be able to
> write a telnet server which could recognize what the remote user's
> terminal type was, and be able to fully utilize its capabilities and
> draw all over the screen.

This is not easy.  The telnet protocol is usually implemented as a
finite state machine to enable the select(2) call to be used for
bi-directional multiplexing, and the data held in ring-buffers.

I would start by using archie to locate a copy of the source code for the
standard UNIX telnetd program and modify that do do what you want.

--
Steve Fosdick                           Post:   Room 210, B67, BT Labs,
E-mail: stevef@aom.bt.co.uk                     Martlesham Heath,
Tel:    +44 473 642987                          IPSWICH   IP5 7RE
Fax:    +44 473 644607                          England

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 94 18:43:36 GMT
From:      bcr@k9.via-term111 (Bill C. Riemers)
To:        comp.programming,comp.protocols.misc,comp.protocols.tcp-ip,comp.terminals,comp.unix.questions
Subject:   Re: Telnet servers: How do I write one?

In article <2j0bam$d5s@cyclops.aom.bt.co.uk> stevef@medusa.aom.bt.co.uk (Steve Fosdick) writes:

   > I would like to experiment with writing a telnet server.  For instance
   > I can say "telnet 141.212.196.79 3000" and get connected to an
   > interactive weather server from University of Michigan.  But this
   > server only operates in line mode; what I'd like to do is be able to
   > write a telnet server which could recognize what the remote user's
   > terminal type was, and be able to fully utilize its capabilities and
   > draw all over the screen.

   This is not easy.  The telnet protocol is usually implemented as a
   finite state machine to enable the select(2) call to be used for
   bi-directional multiplexing, and the data held in ring-buffers.

   I would start by using archie to locate a copy of the source code for the
   standard UNIX telnetd program and modify that do do what you want.

This can already be done with "rlogin".  The main limitation with "rlogin" is
that it uses a fixed port #.

                            Bill



-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1994 22:54:27 GMT
From:      slama@ctron.com (Frederick G. Slama)
To:        comp.protocols.tcp-ip
Subject:   Obtaining local ethernet hardware address.


	With-out using ether_hostton(), is there a way to interrogate the
ethernet interfaces on a local host for their respective 48 bit hardware
addresses? Can this be done with ioctl()/SIOCGIFCONF to obtain if_req
structures with the hardware addresses? If so, how is this done? Using this
technique to obtain inet level protocol information is a breeze, but can
the same ioctl()/if_req API be used to acquire the hardware address???
	If this is a FAQ, please direct me to a site which contains the
list.


Thanks!,

	Fred

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 1994 10:22:38 GMT
From:      milos@varda.ics.muni.cs (Mila Blazek)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   rarpd problem on SVR4

Hi everybody,

on my SVR4.0/PC ICL DRS/NX V4.0, rarpd does not respond to rarp packets:

BSDI$ tcpdump rarp
09:27:45.180448 rarp who-is 8:0:20:0:a8:c9 tell 8:0:20:0:a8:c9

SVR4$ ps -ef|grep rarp
    root   287     1  0 08:55:46 ?        0:01 /usr/sbin/in.rarpd -a

SVR4$ ifconfig eth0
eth0: flags=23<UP,BROADCAST,NOTRAILERS>
	inet 147.251.8.32 netmask ffffff00 broadcast 147.251.8.255
	ether 2:7:1:a:d5:3c

/etc/ethers:
8:0:20:0:A8:C9	147.251.8.33   (or name from /etc/hosts)

Any hints ?
Thank you in advance.

Miloslav Blazek                         <milos@muni.cz>
Masaryk university Brno

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Feb 94 00:58:01
From:      rene.diependaele@infoboard.be
To:        comp.protocols.tcp-ip
Subject:   UNIX_MNG_APL&SYS_SW


==B=E=G=I=N==>
> Hi,
> 
> As UNIX system manager I know the problems of users and managers in a
> dayly UNIX-environment. That's why:
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=
> = I'm building a UNIX 'Manager for Applications and System Software':     =
> = MASS, also usable as B.B.S., for UNIX system managers and common users. =
> = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=
> 
> I want to know the people who are interested:
>  [a] to help me in this stuff, via Internet (lot of questions!)
>  [b] to use it later (they can fetch it from my disk or I can email it)
>  [c] a & b
> 
> MASS serves for general purpose, it's an open system that:
> ---------------------------------------------------------
> - helps and economizes time for exhausted or beginning UNIX-system managers.
> - simplifies the use of a mass of different applications, userprograms,
>   scripts, sw-tricks, etc... for the common user.
> - automatics routines and boring jobs.
> - makes your UNIX-system watertight by using userinitial-logins with
>   paswords, not programnames, even without losing the old login-way
> - helps controlling the software development environment
> - escorts you as novice on your way to UNIX-professional
> - needs no GUI
> 
> 
> For this moment MASS manages already our own mass of all kinds of software.
> 
> It supports among all UNIX things:
> ---------------------------------
> * user creation of personal time-out menus with a simply w.p.
> * system manager creation of business time-out menus with a simply w.p.
> * standard system managing time-out menus for MASS, UNIX and
>   on request WP, INFORMIX, etc...
> * time-out set up per user
> * on-line help per menu-item with create-possibility per own menu-item
> * on-screen manual for questions
> * language-independence
> * planning and programming of a functional macrosystem
> * background processing for all kind of jobs
> * remote monitoring
> * interactive local and remote mail
> * calculation of productivity per user, application and terminal
> * history logging and reporting
> * UNIX-workgroups division
> * closed UNIX-password security
> * (restricted) zones via gateway '!' for programmers/users
> * own B.B.S.-system
> * follow up and expansion via user-bank and user-suggestion-bank
> * all your wishes, your own interesting scripts, etc...
> 
> 
> MASS is builded in asci-UNIX-shellscripts.
> It works in Bourne and Korn shell.
> What means: no compile or transfer problems.
> 
> Everybody can send us UNIX-shell-scripts via e-mail or via our B.B.S.
> If they are good they get a place in the system managing menu so
> every user of MASS is benifited by it in the next release.
> The author of a shellscript can find his name in the authorlist
> of menunumbers. Other MASS-users can write him via e-mail for a
> simular problem.
> 
> MASS will come out as free-ware with a very low contribution for
> administration, updates, new releases, username and password.
> 
> Every business, system manager or user can pick up his own copy via
> our B.B.S. or demand it via his e-mail adress.
> 
> 
> When interested contact us on our e-mail adress and mention, I want to:
>  [a] help you
>  [b] use MASS
>  [c] a & b
>                    AAGO  +---------------------------+
>        Rene Diependaele  !  E-mail: rd@infoboard.be  !
>   Gouden Leeuwstraat 19  +---------------------------+
>   ~   ~      9300 AALST      Voice: 32 53+78 91 89
>    \|/   ~  /\  Belgium        Fax: 32 53+78 65 90
>   -  "-    ~~~~  /\ v
>    /|\  /\/    \/  \/\ v
> ~    /\/  \/\/\/ /\ \v\/\
>   ~ /  \/\/  \ \/  \~\/~ \
>  /\/  ~/m/~ a~\/s~~ s/ []__U n i x
> /  \  /[_]_[_]_[_]_[_]_[___()
>     \==0=0=0=0=0=0=0=0=00==0=#=
> 
>   -- Rene Diependaele --
<==E=N=D==

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 94 21:34:01 GMT
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.unix.aix,comp.protocols.tcp-ip,comp.unix.questions,comp.unix.internals
Subject:   REPOST: SLIP problems, connected but cannot ping




Fellow Netters,

	I have this problem with SLIP running on an IBM RS6000, AIX 3.2.4.
The modem dials out, the remote modem answers, the connection is made and
everything seems to be fine. But now if I try to ping the remote machine I
get no response. I can see the SD light on the local modem blinking for
every ping message being sent, and the RD light on the remote modem blinks
for this packet (both the modems are setup in the same room for testing),
but I get no response to the ping packets sent.

	I checked the routing tables on both machines, and they seemed OK.
Is there a utility I could use to see the packets that are being sent out
and the packets being received by the remote host?

	To make matters worse, this problem is intermittent. I get a good response
on some connections, and no response on others. I have not been able to
figure out a pattern for the failure.

	Is this a bug in the AIX implementation of SLIP, or am I doing something
wrong?

	Any and all responses on this matter greatly appreciated.

Thanx,

Raj.
-- 
===============================================================================
  __  __     .
 /   __/    /                               Raj Malhotra.
/   ( /_   /                                voice : (609)860 7111. 
        __/                                 email : manmetha@gauss.rutgers.edu

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

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 10:58:37 -0500
From:      mikhail@panix.com (Mikhail Kuperblum)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Concerned about tcp checksum notice, please help

In article <CKwsxE.4xC@world.std.com>,
Steve Prowten <sprowt@world.std.com> wrote:
>
>Howdy, all -- We occasionally see the checksum message:
>
>    NOTICE: tcp sum: src 80A9D08C, sum 00000010
>
>on the console of our SCO Unix 3.2.4.2 Intel box.  The hex value
>is never the same twice.  We've got an SMC network card, using the
>SCO wdn drivers.  Can anybody tell me what this might be and whether
>it should cause concern?
>
>Many thanks,
>
>S. Prowten   sprowt@world.std.com
>-- 
>Steven Prowten   sprowt@world.std.com

RELEASE:  SCO TCP/IP Generic

PROBLEM:  I see the following message on the console when I am
          using SCO TCP/IP:

                notice: tcp sum src C009C2E9, sum 00400301

          The src and sum fields change.

CAUSE:    This is a warning message generated by the TCP driver in
          the kernel.

          It is generated when the machine receives an Ethernet packet from
          another machine which has an error in the TCP part of the packet.
          The 'src' is a hexidecimal representation of the IP address of the
          remote machine and 'sum' is the checksum of the packet.

          For example: src C0,09,C2,E9 = 192.9.194.233

          The TCP driver places a header on the data to be sent and then
          checksums the packet and places the checksum in the header. The
          packet is then passed to the IP layer which agains adds a header
          including a checksum (the IP checksum is only a checksum of the
          IP header). The packet then goes to the network adapter driver
          for sending across the network.
          On the receiving end, the headers are removed and the checksums
          checked.  This message appears if the checksum in the TCP header
          does not match the checksum generated on the packet received.

          This is a non-fatal error.  The TCP layer ignores the packet with
          the checksum error and then receives 'out-of-sequence' data, causing
          it to request a re-send of the packet. A few of these errors a day
          on a busy network is to be expected.

SOLUTION: This has been seen on fast machines (486 and 33Mhz 386) with the
          3COM 503 card and SCO TCP/IP Release 1.1.1, however, persistent,
          nearly constant error messages are most often caused by bad
          cabling/termination, cable ringing, or a bad card (or simply
          an incompatable one) on the network. You may also see sporadic
          occurances when running via SLIP or PPP due to line noise.

-- 
Mikhail Kuperblum            [mikhail@panix.com]           W e   c o v e t . . .

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue,  8 Feb 1994 12:35:30 -0500
From:      Kwan-Ju Chen <kc2x+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Shareware winsock TELNET program



Any other shareware winsock telnet program out there?  I know of QVTNET only.

Thanks


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 17:43:32 -0600
From:      dpm@bga.com (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   Telnet "forwarder"


Sometime in the past two or three months, someone posted a telnet
"forwarder" in one of the source groups.  I.e, it listens at one port
for requests, does a password check, then turns into a
pipe--forwarding bits to the telnet port on a third machine.  It is
the type of thing you might use to emulate direct telnet access to the
outside when you have a firewall machine.

I dutifully saved the source code for the program, knowing that I
would want it in a few months.  Now I need it, but the bits have
disappeared off of my disk!  (I suspect they fell prey to an
over-zealous mail cleaning session.)

At any rate, I can't find the program now.  Does anyone else
remember seeing this program?  I've checked the news archives
I can think of with no luck.  Archie isn't helpful since I don't
remember the program's name.

It wouldn't be a hard program to write, but....

Thanks,
-dpm

-- 
 David P. Maynard, Carnegie Mellon University & Dependable Solutions
 USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862
 EMail: dpm@depend.com,  Tel: +1 512 251 8122,  Fax: +1 512 251 8308
--

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Feb 1994 21:14:08 -0800
From:      carr@esl.com (John A. Carr)
To:        comp.protocols.tcp-ip
Subject:   IP Broadcasts

What is the effect of a node broadcasting with an improper broadcast
address?  Our network uses a subnet mask and an all ones broadcast address.
 A variety of nodes have either the netmask or broadcast address or both
configured improperly.  I understand the effects of an improper netmask,
but the effects of a bad broadcast address are less clear.  

Our network number is 129.193.0.0 and our 6 bit subnet makes this
129.193.144.0 for our subnet.  Our all ones broadcast address is therefore
129.193.147.255.  There are three cases:

1)  broadcasting to 129.193.144.0
2)  broadcasting to 129.193.0.0
3)  broadcasting to 129.193.255.255

What happens in these cases?  The users don't seem to see any adverse
effects.  I don't want to hassle them to change if it doesn't matter.  Most
are Suns running 4.1.3 and default to 0's.  

Also, is there a way to elicit a broadcast response from a node?  Now I
have to wait for a broadcast to float by my analyzer.  It would be nice if
I could "ping" and get a broadcast response.

Thanks.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John A. Carr          ESL Incorporated           carr@esl.com

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 16:42:39 -0500
From:      mikhail@panix.com (Mikhail Kuperblum)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Concerned about tcp checksum notice, please help

In article <CKwsxE.4xC@world.std.com>,
Steve Prowten <sprowt@world.std.com> wrote:
>
>Howdy, all -- We occasionally see the checksum message:
>
>    NOTICE: tcp sum: src 80A9D08C, sum 00000010
>
>on the console of our SCO Unix 3.2.4.2 Intel box.  The hex value
>is never the same twice.  We've got an SMC network card, using the
>SCO wdn drivers.  Can anybody tell me what this might be and whether
>it should cause concern?

One more thing, it is possible to stop this message from popping up on your
console screen (one can argue, that it may not be wise to do such).

If your TCP/IP release is 1.2.0:

a) Modify /etc/conf/pack.d/tcp/space.c & change line that reads
  "int tcpprintfs  = 1;" to "int tcpprintfs = 0;".

If your TCP/IP release is 1.1.3:

a) Apply adb patch:

          (NOTE: the "#" and "*" are prompts)

          # cd /etc/conf/pack.d/tcp
          # cp Driver.o Driver.o.bak
          # adb -w Driver.o -
          * tcpprintfs/D
          tcpprintfs:     1
          * tcpprintfs/W 0
          tcpprintfs:     0x1=    0x0
          * tcpprintfs/D
          tcpprintfs:     0
          * $q
          #

b) Relink your kernel.

-- 
Mikhail Kuperblum            [mikhail@panix.com]           W e   c o v e t . . .

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 13:29:43 GMT
From:      jackt@dean.med.ufl.edu   (Cactus Jack)
To:        comp.protocols.tcp-ip
Subject:   Redirecting COM1 to TCP/IP??

Hello,

	I have a 486 DX2/50 running OS/2 2.1 and TCP/IP 2.0.

	Is it possible to redirect all traffic to and from a BBS using TCP/IP?
I was thinking of some method to associate a COM port to TCP/IP.  The BBS
will think it is communicating via the COM port, but data is actually being
received/sent via TCP/IP.

Any ideas will be greatly appreciated.

Bang!  Bang!

-----
  **************  Home of the RSPW Archives  **************

  Jack J. Thompson            Archives:  Anonymous FTP to
  jackt@dean.med.ufl.edu                   cactusjack.health.ufl.edu
  College of Medicine                            
  University of Florida         


-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Feb 1994 14:15:13 GMT
From:      sprowt@world.std.com (Steve Prowten)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Concerned about tcp checksum notice, please help


Howdy, all -- We occasionally see the checksum message:

    NOTICE: tcp sum: src 80A9D08C, sum 00000010

on the console of our SCO Unix 3.2.4.2 Intel box.  The hex value
is never the same twice.  We've got an SMC network card, using the
SCO wdn drivers.  Can anybody tell me what this might be and whether
it should cause concern?

Many thanks,

S. Prowten   sprowt@world.std.com
-- 
Steven Prowten   sprowt@world.std.com

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 16:22:51 GMT
From:      papowell@dickory.sdsu.edu (Patrick Powell)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootpd for Solaris 2.1....

Geoffrey Liersch (lurch@ee.latrobe.edu.au) wrote:

: Hi,
 
: Has anyone had success in getting a bootp server to compile under Solaris 2.1
: or any version of Solaris for that matter?
 
: I ftp'd bootp2.2alpha.tar.Z and changed all the bcopy's type functions to the 
: equivalent mem??? functions, added some header files and it seems to compile
: OK.  The problem occurs when the program is run,  the initial piece of code
: that determines if it has been started from inetd or from a terminal using 
: getsockname forgets to set errno and the test then fails.
 
: Has anyone overcome this problem????


: Thanks,
 
: Lurch

1. Check to make sure that a previous version of bootpd is not running.
   Do:  ps -aux | grep boot
   You should see something like:
root       137  0.0  0.0   60    0 ?  IW   Feb  3  0:00 bootpd -s
papowell  5400  0.0  1.4   32  196 p3 S    08:19   0:00 grep boot
papowell  5398  0.0  2.8   64  412 p3 S    08:19   0:00 sh -c ps -aux |grep boot

   The PID of the running bootpd is 137.

2. If there is a version running,  check to see if it is started by inetd.
   grep boot /etc/inetd.conf

   If it was started by inetd, then edit the lines in the inetd file:
#bootps	dgram	udp	wait	root	/usr/etc/bootpd
^ comment out this line,  and then do a kill -HUP to the inetd process

4. Check to see if it was started from the rc.local file:
# start up the bootp server
if [ -f /usr/etc/bootpd -a /etc/bootptab ]; then
	bootpd -s && 		echo -n ' bootpd'
fi

5. Now kill off the bootpd process: kill -HUP 137

You should be able to start up your test version now.

Have fun!

--

papowell@sdsu.edu
Prof. Patrick Powell, Dept.  Electrical and Computer Engineering,
Engineering 403G, San Diego State University, San Diego, CA 92182-0190
Office (619) 594-7796; Lab (619) 594-2434 FAX (619) 594-3703

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 16:32:48 GMT
From:      papowell@dickory.sdsu.edu (Patrick Powell)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Concerned about tcp checksum notice, please help

Steve Prowten (sprowt@world.std.com) wrote:

: Howdy, all -- We occasionally see the checksum message:
 
:     NOTICE: tcp sum: src 80A9D08C, sum 00000010
 
: on the console of our SCO Unix 3.2.4.2 Intel box.  The hex value
: is never the same twice.  We've got an SMC network card, using the
: SCO wdn drivers.  Can anybody tell me what this might be and whether
: it should cause concern?
 
: Many thanks,
 
: S. Prowten   sprowt@world.std.com
: -- 
: Steven Prowten   sprowt@world.std.com


1.  You have got a runt packet in,  which just HAPPENS to look OK to the
Ethernet interface.  Rare,  but it happens.  I have seen it twice in
a week here.

2.  You have a flakey interface card, with a bad memory chip.  Replace
the card IMMEDIATELY.   You may get some VERY strange errors if you
do not do this NOW!  You have been warned!

Patrick ("When in doubt, replace the hardware. Guido, order another Cray!")
  Powell
--


papowell@sdsu.edu
Prof. Patrick Powell, Dept.  Electrical and Computer Engineering,
Engineering 403G, San Diego State University, San Diego, CA 92182-0190
Office (619) 594-7796; Lab (619) 594-2434 FAX (619) 594-3703

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Feb 1994 17:29:30 GMT
From:      braun@wc.novell.com (Karl Tunnell-Braun)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: How to administer IP address space?  Database/spreadsheet/?

In article <1994Feb8.204256.1@vaxc.cc.monash.edu.au> (John Mann) johnm@vaxc.cc.monash.edu.au (John Mann) writes:
>In article <2hjktc$k6j@netnews.upenn.edu>, tony@scotty.dccs.upenn.edu
>(Anthony Olejnik) writes:
>> What are some of the methods used to administer IP addresses?
>> How do some of the other places out there, keep track of your addresses?
>> 
>
>I am very interested in some scheme to automatically maintain DNS and
>bootptab files -- either some front-end program that edits the files for
>you; or a "network hosts database" from which would be run periodic
>"reports" which are the new DNS and bootptab files.
>

I am currently working on some perl-oriented tools to roll up flat
file databases containing {hostname, ip-addr, hw-addr} entries into
DNS and Bootp files.  I will be migrating this to DHCP as soon as
there is enough of a spec to deal with (and I have the bandwidth to
make the changes).

If anyone else is working on similar issues, I'm interested in
maintaining communications.

--
Karl Tunnell-Braun   408/321-1301			braun@novell.com
Network Scapegoat in Training				Novell IS Lan Eng.
"That which does not kill us, makes use stronger" 		- Nietzche
"Embrace Tiger, Return to Mountain"

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Feb 1994 17:35:54 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding out who pinged me

In article <7FEB199412000846@reg.triumf.ca>,
Rod Nussbaumer <bomr@reg.triumf.ca> wrote:
>I have seen eveidence that some machine(s) are sending out pings on an
>ongoing basis (about once per 5 minutes), and my general paranoia wants
>me to find out who is doing this.  Is there any official means within some
>standard that allows this?  If so, is there any free software to run
>underDOS/packet drivers that does this?  If this isn't a major job,
>I'd be willing to hack some WATTCP code or other existing code to do the
>job, but I'm no TCP/IP wiz.  Sort of a 'reverse ping' thing is what I
>need.

If you have the WATTCP source, just compile any application
with debugging enabled and place a break point on icmp_Reply()
in pcicmp.c

That is the rountine which does the ping reply.

Erick



-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 18:13:55 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   cluster mbufs



    Could some one explain to me the intricacies of cluster mbufs or show me
where to find the information?

                             Jerry Freedman,Jr

ps I am interested in them in the context of Sun 4.1.x

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 19:46:40 GMT
From:      dennis@dehn.math.nwu.edu (Dennis Director)
To:        comp.protocols.tcp-ip,comp.os.linux.help
Subject:   "Network is unreachable" with new SLIP

I am trying to upgrade to the new kernel of Linux (99.14)
so the networking through SLIP will allow my to use
Mosaic.  Everyting but Mosaic works with my SLIP setup
for version 99.13.

I have installed a new system and the new Net-2 packages
according to the FAQs and HOWTOs and READMEs.

I can make a SLIP connection now, and I can ping the SLIP
server after the connectin is made.  Such as:

PING elvex (129.105.9.1): 56 data bytes
64 bytes from 129.105.9.1: icmp_seq=0 ttl=182 time=286 ms
64 bytes from 129.105.9.1: icmp_seq=1 ttl=183 time=257 ms

But when I try to ping any other machine that I normally
connet to I get something like:

PING cauchy (129.105.81.17): 56 data bytes
ping: packet too short (36 bytes) from 129.105.81.17
ping: sendto: Network is unreachable
ping: wrote cauchy 64 chars, ret=-1
ping: packet too short (36 bytes) from 129.105.81.17
ping: sendto: Network is unreachable

I have issued a route command like:

route add default gw 129.105.9.1

as suggested by some previous notes.

Is there a usefull step by step procedure to determine why
I get the dreaded "Network is unreachable ..."?

As usuall, thanks for everyones generous help!


-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Feb 1994 21:16:10 GMT
From:      consol@world.std.com (CSI ContractSolutions)
To:        comp.protocols.tcp-ip
Subject:   PPP for Altos Unix system v5000


Hello,

I'm looking for a PPP package that would work with ALTOS UNIX SERVER.  I 
need a package that will be installed on the server and let terminal 
users to utilize internet service through a modem.

I already have Altos TCP/IP.

any suggestions???

Thank you in advance.

young Kim

consol@world.std.com


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1994 21:54:48 GMT
From:      robin@paros.com (Robin Cutshaw)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   Re: rarpd problem on SVR4

In article <2j54pe$crv@rhino.cis.vutbr.cz>, milos@varda.ics.muni.cs (Mila Blazek) writes:
|> Hi everybody,
|> 
|> on my SVR4.0/PC ICL DRS/NX V4.0, rarpd does not respond to rarp packets:
|> 

I just ran into this problem last night on a Dell SVR4.  If you put in.rarpd
in debug mode it sees the packets and says that it responds.  The remote
client never sees it.  I need to dump the packets on the lan to see the
problem.  I'll let you know if I find anything...

robin

-- 
----
Robin Cutshaw        internet: robin@paros.com
VP, R&D              CIS:      76466,102
Paros, Inc.          BellNet:  404-874-5122

      "Time is just one damn thing after another" -- PBS/Nova
----
--

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Feb 1994 21:56:01 GMT
From:      ltu@ki.icl.se (Lars_Tunkrans)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   Re: rarpd problem on SVR4

milos@varda.ics.muni.cs (Mila Blazek) writes:

>Hi everybody,
 
>on my SVR4.0/PC ICL DRS/NX V4.0, rarpd does not respond to rarp packets:
 
>Any hints ?
>Thank you in advance.
 
>Miloslav Blazek                         <milos@muni.cz>
>Masaryk university Brno

Please Tell us which Version of DRSNX and TCP/IP you are using.

I have booted printservers with rarp on DRS/NX Version 6 Level 2 together
with TCP/IP Version 2 Level 3.

//Lars.
--
_______________________________________________________________________________
Lars Tunkrans DRS Product Centre  Phone: +46 (0)87937419  FAX: +46 (0)87938109
DOMAIN Address: ltu@icl.se  X400 Gateway:  l.tunkrans@swe2007.wins.icl.co.uk 
X400:    I=L;S=Tunkrans;OU1=SWE2007;ORG=ICL;PRMD=ICL;ADMD=400NET;C=SE

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 12:35:04 -0800
From:      skynyrd@tahoma.cwu.edu (Chris Timmons)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: packet size and the TCP/IP network throughput

Dongchen Lu (dlu@omega.eng.hawaii.edu) wrote:
:      According to some papers,( quite old 1988 and 1989)
:  the packet size for the best network throughput using TCP/IP in a ethernet 
: local network is 1024 bytes. this is because the memory management and 
: fragmentation etc. 
:      I did some some measurement by using Berkerly Sockets programming tools.
: the best network throughput I got is using 2048 bytes and above packet size for TCP/IP.  the measurement software is programmed having the minimum overhead. and the network load is monitored to have the same load condition.
:      My question is: what packet size is for the best TCP/IP network
: throughput, is it conditional? are there some new documents about performance
: analysis of TCP/IP, or new TCP/IP version have different memory management ?

Several very good books on TCP/IP cite RFC1144 (Jacobson) when discussing
MTU values in the presence of low speed serial links.  This is kind of a 
special case but you might find it interesting.

--

-Chris Timmons, Network Engineer / Systems Programmer 
 Central Washington University, Ellensburg, Wa.
 skynyrd@tahoma.cwu.edu

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 94 00:26:12 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification for uuencoded files

In article <stan.huyge.28.00113928@ClemsonSC.NCR.COM>, stan.huyge@ClemsonSC.NCR.COM (Stan Huyge) writes:
> If someone knows where to find the specification for uuencoding files, I would 

The program itself is small, and the source is widely available.
Would you like a copy?

-- 
All opinions Copyright (c) 1994 by John Chambers.  Inquire for licensing at:
1-617-647-1813 ...!{harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc 

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 09:28:21 -0500
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: How to administer IP address space? Database/spreadsheet/?

In <1994Feb8.204256.1@vaxc.cc.monash.edu.au> (John Mann) johnm@vaxc.cc.monash.edu.au (John Mann) writes:

>We currently have 6531 registered IP addresses in 161 subnets and 43
>subdomains.  We are currently adding about 50 PCs per week. The manual
>task of editing the forward and reverse DNS tables and the bootptab
>files is becoming quite a chore :-(.

Many sites do the following:
1.  Have one master text file (maintained under SCCS or RCS) that
lists ip address, hostname, aliases, and comments.  After
editing this file, "make" runs some perl scripts that generate
the DNS tables, bootptab, etc.  All automaticly.
2.  Have one person designated as the "hostmaster" that knows
how to edit this table and type "make".

>The system should also manage the other messy things such as CNAME and
>MX records for hosts, NS records for the various subdomains,
>incrementing the SOA Serial number etc.

If you are still maintaining all of your DNS stuff manually,
you are really working to hard.

Tom

-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.org (play)
"Psst!  Hey, Anthony!  Y'know what I        | Disclaimer:  I do not
like about existing?"  "Uh... uh... what?"  | speak for Mentor Graphics.
"Possessing a physical extension."  -TSA    |

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 94 09:08:26 PST
From:      marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services)
To:        comp.protocols.tcp-ip
Subject:   Why all this fingering?

This may have been discussed before, and maybe everyone else already
knows the answer, but I don't, so here goes:

Why are my DNS machines (at least) being fingered repeatedly by such
hosts as: bruno.cs.colorado.edu, dino.concicit.ve, maelstrom.oc.com,
plaza.aarnet.edu.au, mudhoney.micro.umn.edu, netcom5.netcom.com,
sm0223.mcclellan.af.mil, and others?

It seems to me that the finger protocol was originally developed so that
people could check to see if someone they knew was logged in, with some
other added information.  Now my DNS machines are being fingered on a
regular basis by people I don't know for reasons I don't know.

I have heard that it is part of some information gathering project (if
anyone can give me details I would appreciate it).  What I want to know
is how other people feel about this, as it seems somewhat invasive to
me.  Maybe I am too sensitive, but I don't like seeing information
collection by random probing.

Comments?

MarkJ
-- 
Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views don't perforce match yours.
SAICnet Logical Network Manager    | My opinions aren't perforce SAIC's.
SAIC, San Diego, CA (619) 458-2794 | I take responsibility for my iguana.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 03:51:17 GMT
From:      James G. Speth <speth@end.com>
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   TCP/IP through a shell account???

A program idea came to me today, but before I launch into a coding binge
I want
to get some input as to whether it is impossible or already done.

I would like to write something similar in functionality to a PPP daemon,
but
one that does not need superuser priveledges to run, and does not modify
routing
tables.  My idea is to take the PPP packet that is received at the remote
end
and analyze it.  Rather than forwarding on the IP packet, the daemon
would act
on the contents of the packet.  If it is a TCP packet, then it would open
a TCP
stream to the destination, and send the data through.  Similarly for UDP.
 For
other protocols it would either return errors or ignore them or whatever.

This would allow a non-superuser to set up this program in her account,
dial
in, and initiate TCP connections to the outside world.  It would not allow
people to access the user's home machine though (ie. through FTP),
because as
far as the internetted world is concerned, all the connections are
actually
initiated from the machine running the daemon.  However, for most users,
this
would be enough.

So help me, please.  Is there any reason why this won't work?  Is there
anything out there that already does this, or are people currently
working on
it?

I've just touched on the surface of my idea here, but I'd be happy to
discuss
it further.  Thanks in advance.

Jim

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 06:02:02 GMT
From:      devmorfo@mtu.edu (Evmorfopoulos Dimitris)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   Re: TCP/IP through a shell account???

In article <2j9mjl$9q1@darkstar.UCSC.EDU>, James G. Speth <speth@end.com> writes:
> A program idea came to me today, but before I launch into a coding binge
> I want
> to get some input as to whether it is impossible or already done.
> 
> I would like to write something similar in functionality to a PPP daemon,
> but
> one that does not need superuser priveledges to run, and does not modify
> routing
> tables.  My idea is to take the PPP packet that is received at the remote
> end
> and analyze it.  Rather than forwarding on the IP packet, the daemon
> would act
> on the contents of the packet.  If it is a TCP packet, then it would open
> a TCP
> stream to the destination, and send the data through.  Similarly for UDP.
>  For
> other protocols it would either return errors or ignore them or whatever.
> 
> This would allow a non-superuser to set up this program in her account,
> dial
> in, and initiate TCP connections to the outside world.  It would not allow
> people to access the user's home machine though (ie. through FTP),
> because as
> far as the internetted world is concerned, all the connections are
> actually
> initiated from the machine running the daemon.  However, for most users,
> this
> would be enough.
> 
> So help me, please.  Is there any reason why this won't work?  Is there
> anything out there that already does this, or are people currently
> working on
> it?
> 
> I've just touched on the surface of my idea here, but I'd be happy to
> discuss
> it further.  Thanks in advance.
> 
> Jim

	Since you are talking about something so restricted, hhave you checked
out "term" ? And by the way, you need root access on the remote host to grab the 
ports that will have the data you are talking about.

-- 
	 ______      _______
	|  __  \    |  _____|	devmorfo@cs.mtu.edu  (Evmorfopoulos Dimitris)
	| |  \  |   | |___              
	| |   | |   |  ___|     Masters student working hard on        
	| |___| |   | |_____
	|_______| * |_______| * "Sliding Sunday, Week compression algorithm." 

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 06:40:38 GMT
From:      peng@pirates.cs.swt.edu (Wuxu Peng)
To:        comp.protocols.tcp-ip,comp.unix.osf.misc
Subject:   Anonymous ftp: how to tar/compress?

    I am using version 2.1c of wuarchive-ftpd on my DEC OSF1.3a
box.  I have problems setting up anonymous ftp to get a
compressed file (with suffix .Z or .gz) or tarred file
(with suffix .tar, .tar.Z, or tar.gz).  I have put
"compress", "gzip", and "tar" (GNU version) into ~ftp/bin,
and set up the ftpconversions files according to the
samples.  It still does not work.  Every time I tried
to get a compressed or tarred file/dir,  I only got
an empty file, with proper name.  However, when I log in
as an ordinary user, it all works.  I am at the end of
my wit.  Any pointers are highly appreciated.

Thanks.


--

--wuxu peng (peng@pirates.cs.swt.edu)


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 08:48:13 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   Re: TCP/IP through a shell account???

In article <2j9mjl$9q1@darkstar.UCSC.EDU> James G. Speth <speth@end.com> writes:
>I would like to write something similar in functionality to a PPP daemon,
>but one that does not need superuser priveledges to run, and does not
>modify routing tables.  My idea is to take the PPP packet that is received
>at the remote end and analyze it.  Rather than forwarding on the IP
>packet, the daemon would act on the contents of the packet.  If it is a
>TCP packet, then it would open a TCP stream to the destination, and send
>the data through.  Similarly for UDP.

How would incoming UDP be handled?  Since UDP doesn't have connections,
this daemon wouldn't know whether to wait for a response to UDP packets
that are transmitted.  And what if another process already has the port
bound?  For instance, NTP packets are sent with the source port being the
NTP well-known port, but if the machine running the daemon already has an
NTP process, it will have that port bound, and your PPP daemon won't be
able to listen for the response.

Your scheme also has some of the same problems as the often-requested
"address translating gateway".  Many protocols include IP addresses in the
application layer data; for instance, the PORT command in FTP contains the
client's address.  But it's difficult for the daemon to find them and
change them to refer to the gateway machine.

FTP also has another problem.  The data connection is implemented in
reverse -- the client listens and the server connects.  But how would your
daemon know to listen on the port that the PPP host is listening on, since
listening on a port doesn't transmit anything?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      09 Feb 1994 11:55:10 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: cluster mbufs

In article <2j8kp3$j1i@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes:

       Could some one explain to me the intricacies of cluster mbufs or show me
   where to find the information?

This is explained in the BSD internals book by Karels, Quarterman et
al. It is also covered in the "Socket-Based IPC Implementation Notes"
chapter of the Network Programming Guide - part of the standard SunOS
documentation. That chapter is derived from the paper "Networking
Implementation Notes" which is part of BSD documentation.

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 12:03:20 GMT
From:      rudi@chem.rug.nl (Rudi van Drunen)
To:        comp.protocols.tcp-ip
Subject:   routed (5.2.3) on linux broken ?


Hi all !

I think I discovered a bug in routed 5.2.3 for linux.
when started I get snedto: Invalid argument; everytime
routed tries to send it's routing tables.

Digging  in the source (of af.c) one sees that the 'flags' variable
passed to the sendto call is wrong (might be of the wrong type 
(it is int; but has to be unsigned int according to the man pages.))

When just making flags equal to 0 just before doing the sendto
it seems to work, but I think that is defintely NOT a good solution.

Maybe some of you experienced the same problem, and fixed it the
right way (how ??)
Is there somewhere out in netland a newer version without this 
bug ...
Please share your experiences with me !

thanks !

rudi


-- 

 Rudi van Drunen                      Internet: rudi@chem.rug.nl
                			      : rudi@rugrcx.rug.nl
 Dept. of Biophysical Chemistry 	 X400 : c=nl;admd=400net;prmd=surf;
 University of Groningen			o=rug;ou=chem;s=van.drunen;i=R;
 The Netherlands                        Bitnet: 

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 13:41:58 GMT
From:      maislin@hermes3.sps.mot.com (David Maislin)
To:        comp.protocols.tcp-ip
Subject:   New Group?

What is be a good idea to start a comp.protocals.slip group?  I seem
to see discussions on about six different group concerning SLIP.  I have
many questions about SLIP and if anyone can help I would appreciate it.

I just finished installing the Internet Kit for the PC and have the following
problems configuring it correctly.

1.  I have a Practical Peripheral Modem 14,400 Baud, IBM PS2/486 25 MHz with
    windows installed.  What should those TCPMAN SLIP SETUP parameters
    be set to?  Do I need to type in the GATEWAY regardless of the SLIP
    connection?  When I launch TCPMAN it tends to always show the GATEWAY,
    IP ADDRESS, etc...  The README files were short on this subject.

2.  I can successfully connect, I then try to launch anything, let's say MOSAIC.
    after the first home page loads, nothing much ever happens when I click on
    anything else.  The same thing happens when I launch telnet.  The login
    screen will successfully appear, but when I go to type my login name,
    nothing happens.  It doesn't even let me type one letter, or at least
    nothing shows up on my screen, even if I hit return.

3.  We have to first connect to an authentication server, login with a
    Security Dynamics ACE card (changes passwords every sixty seconds).
    Then we have to type SLIP and point at a SLIP server.  After I am
    connected via SLIP, I then have my IP assigned to me and I can
    launch the various programs provided in the KIT.  Would this
    create any problems for me?

4.  The terminal server that I connect to is a CISCO terminal server
    with Motorola UDS 14,400 modems.  Does anything on the terminal
    server side need to be changed or reconfigured?  I believe that
    only one or two other people have connected via SLIP to this site
    so far and they may have not been to successful also.

5.  Can SLIP support IPX for NOVELL servers?  If so, how?




---
+----------------------------------------------------------------------------+
|     .     .     |                                                          |
|    ...   ...    | David Maislin                                            | 
|   ..... .....   | Systems Analyst/UNIX Systems Administrator               |
|  ..   ...   ..  | Reliability & Quality Assurance                          |
| .      .      . | Semiconductor Products Sector                            |
|                 | Phoenix, AZ                                              |
|     Motorola    | maislin@hermes3.sps.mot.com        Phone:(602)-244-4169  |
 +----------------------------------------------------------------------------+
|                  'connectionLESS IS MORE' -- Data Broker                   |
+----------------------------------------------------------------------------+




-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 94 20:42:56 +1100
From:      (John Mann) johnm@vaxc.cc.monash.edu.au (John Mann)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: How to administer IP address space?  Database/spreadsheet/?

In article <2hjktc$k6j@netnews.upenn.edu>, tony@scotty.dccs.upenn.edu
(Anthony Olejnik) writes:
> What are some of the methods used to administer IP addresses?
> How do some of the other places out there, keep track of your addresses?
> 
> In my particular organization, we use a custom (Ingres) database
> application (running on a DEC machine running Ultrix). That way,
> all authorize individuals can simply establish a telnet session
> (from anywhere) to obtain a unique (and unassigned) IP address.

I am very interested in some scheme to automatically maintain DNS and
bootptab files -- either some front-end program that edits the files for
you; or a "network hosts database" from which would be run periodic
"reports" which are the new DNS and bootptab files.

We currently have 6531 registered IP addresses in 161 subnets and 43
subdomains.  We are currently adding about 50 PCs per week. The manual
task of editing the forward and reverse DNS tables and the bootptab
files is becoming quite a chore :-(.

In the scheme I am looking for, local network administrators should be
able to easily allocate the next free IP address on one of the subnets
they manage and add the new name to their subdomain.  They would also
record Ethernet card addresses, the user's name, location and phone
number, ...  There should be inbuilt checks for duplicated host name or
Ethernet card address, correct syntax for host names and addresses ...
The system should also keep track of who did what and when ;-).

The system should also manage the other messy things such as CNAME and
MX records for hosts, NS records for the various subdomains,
incrementing the SOA Serial number etc.

Does anyone know of such a IP address tracking system?

Alternatively, does anyone know of a Network Management System that also
includes such IP address space management tasks?

Thanks,
	John
--
John Mann
Network Services Activity           Net: John.Mann@cc.monash.edu.au
Computer Centre, Monash University  Tel: +61 3 905 4774
Clayton, Victoria 3168, Australia   Fax: +61 3 905 4746

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 15:21:48 GMT
From:      jasonh@chineham.euro.csg.mot.com (Jason Haar)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

I'm glad someone brought this up - recently I've been thinking that the 
FTP protocol looks well overdue for an overhaul.

There are number of "extensions" out there now - ones that allow you to 
tar and/or compress files on the server before transferring them, as well 
as things like BinHexing Macintosh files before sending. The format of 
the LIST command is just the tip of the iceberg...

I find all of these extensions rather useful - but they're just not part 
of the standard.

Are there any plans afoot to rewrite FTP away from this Unix-centric world
to one that's more generic? (e.g. systems like VAX/VMS and Macs have more
than one data 'fork' - so how do you transfer two streams at once). It may
be that the majority of ftp servers on the Internet are Unix - but the
majority of _clients_ aren't... 


--

Cheers,

Jason Haar

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 15:49:21 GMT
From:      griesser@zeus.uni-duisburg.de (Michael Griesser)
To:        comp.protocols.tcp-ip
Subject:   Re: where is snoop ?


Try tcpdump, it does the same job.

Ciao   Michael

--------------------------------------------------------------------
Michael Griesser, FB7 Fachgebiet Technische Informatik  Uni Duisburg
griesser@zeus.uni-duisburg.de   IRC: mowgli    M.GRIESSER@IUS.gun.de


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 15:56:43 GMT
From:      wls@magrathea.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip,comp.unix.osf.misc
Subject:   Re: Anonymous ftp: how to tar/compress?

In article <2ja0h6$4g4@pirates.cs.swt.edu>, peng@pirates.cs.swt.edu (Wuxu Peng) writes:
>     I am using version 2.1c of wuarchive-ftpd on my DEC OSF1.3a
> box.  I have problems setting up anonymous ftp to get a
> compressed file (with suffix .Z or .gz) or tarred file
> (with suffix .tar, .tar.Z, or tar.gz).  I have put
> "compress", "gzip", and "tar" (GNU version) into ~ftp/bin,
> and set up the ftpconversions files according to the
> samples.  It still does not work.  Every time I tried
> to get a compressed or tarred file/dir,  I only got
> an empty file, with proper name.  However, when I log in
> as an ordinary user, it all works.  I am at the end of
> my wit.  Any pointers are highly appreciated.

Unless you make special versions of these commands which don't use the
shared libraries (using "-non_shared"), there's a lot you need to set-up
in your anonymous ftp area.  Things, like:

	/sbin/loader
	/usr/shlib/libc.so
	/etc/sia/siainitgood
	/etc/sia/bsd_matrix.conf	(I'm not positive you need
	/etc/sia/matrix.conf		 these two)

While you're at it, you should have:

	/etc/zoneinfo/localtime

Otherwise, ftp may not have the correct time.

We have a set-up running this way, and it works fine.

--
Bill Stapleton
     wls@magrathea.csd.uwm.edu
     uwmcsd4!wls

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 17:15:27 GMT
From:      jan@filetek.com (Jan Morales)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.security.unix,comp.unix.admin
Subject:   need packet filter software ala BFP

I need to be able to block TCP/IP packets to and from specified
addresses (e.g., those in a subnet) from being forwarded by a Sun
workstation running as a router.  I have looked into BPF, which
seems to do what I need, but it requires SunOS source which we
don't have.  Is there any software, free or commercial, which
will do this?

I have a Sun SPARCstation SLC running SunOS 4.1.3 and plan to
use CSLIP 2.7.

Thanks for any help.  Followup-To: set to comp.sys.sun.admin.

Jan
-- 
Jan Morales                      Internet: jan@filetek.com
FileTek, Inc.                        UUCP: uunet!fltk!jan
Rockville, Maryland, U.S.A.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 17:33:07 GMT
From:      billy@utdallas.edu (Billy Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

peter@ncrpda.curtin.edu.au (Peter N Lewis) writes:

>The output should be something like this:
 
>-rw-------  1 peter         848 Dec 14 11:22 00README.txt

Talk about a UNIX centric view of the world.  To make this
proposal work, you need to specify how Novell, VMS, VM, etc
translate their permissions into this format.  I know for
starters that this information is not sufficient to represent
the VMS protection schema, which is far superior to the default
UNIX one.

>-p - add / on the end of directories, especially important for links.
>-F - add /, *, @, = to the end of various files.
>-l - in the long format described above (ie LIST should ignore it)
>-R - recursive listing (some mirroring software relies on this)
-a is another needed one

--
Billy Barron,  Network Services Manager, Univ of Texas at Dallas
billy@utdallas.edu 

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 17:58:50 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Broadcasts

In article <carr-080294211408@macm403.esl.com> carr@esl.com (John A. Carr) writes:
>What is the effect of a node broadcasting with an improper broadcast
>address?  Our network uses a subnet mask and an all ones broadcast address.
> A variety of nodes have either the netmask or broadcast address or both
>configured improperly.  I understand the effects of an improper netmask,
>but the effects of a bad broadcast address are less clear.  
>
>Our network number is 129.193.0.0 and our 6 bit subnet makes this
>129.193.144.0 for our subnet.  Our all ones broadcast address is therefore
>129.193.147.255.  There are three cases:
>
>1)  broadcasting to 129.193.144.0
>2)  broadcasting to 129.193.0.0
>3)  broadcasting to 129.193.255.255
>
>What happens in these cases?  The users don't seem to see any adverse
>effects.  I don't want to hassle them to change if it doesn't matter.  Most
>are Suns running 4.1.3 and default to 0's.  
>
>Also, is there a way to elicit a broadcast response from a node?  Now I
>have to wait for a broadcast to float by my analyzer.  It would be nice if
>I could "ping" and get a broadcast response.

One of the major problems used to be Unix TCP/IP kernels which would try
to play router by default.  The machines would see that the packet was not
addressed to them, but not see that they were broadcasts.  These machines
would then try to forward these packets back onto the same net, often
issuing an ARP for the destination.  If you had many of these machines on
your net, every broacast would be followed by a flood of packets from
these machines (broadcast ARPs usually).  If any of these machines managed
to forward the packet as a broadcast, then a cable meltdown could be expected
as the broadcasts regenerated.  Luckily, there is usually a way to turn
IP forwarding off in these machines if the vendor still defaults it on.

Art


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 18:04:44 GMT
From:      boinepel@enws196.eas.asu.edu (Hareesh K. Boinepelli)
To:        comp.protocols.tcp-ip
Subject:   Need Info on MAPI

Hi all,

I am looking for info on MAPI (Message Application Programmers Interface).
This is supposed to be an email interface for PCs ( I am not 100% sure).
If anyone of u out there are aware of MAPI, could u please suggest
me some references where I can look for more info.

Thanks a lot

---
***********************************************************
Hareesh K. Boinepelli
Electrical Engineering Department, 	      
Arizona State University, Tempe, Arizona.
email: boinepel@enuxsa.eas.asu.edu            

-----------------------------------------------------------------------
"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton
-----------------------------------------------------------------------


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 07:43:56 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on X.25 efficiency

In article <CL0Foo.514@capvolmac.nl> cv1540@capvolmac.nl (Martin Tirion) writes:
>
>Hi,
>
>I am looking for people with experience in using TCP/IP on top of X.25. We are
>thinking of implementing this but we would like to exchange some thoughts with
>people who have actually seen this work and have done measurements on
>performance. We have tried to do a benchmark and it seemed as if a FTP of a 
>small file (around 4 kbytes) took TWICE ! as many packets as when bare X.25 was 
>used. This got less worse when the files grew larger but the number of packets 
>was still considerably larger in comparison to bare X.25. Since we are paying 
>per (fixed size) packet this is not a nice thing to have.

   There is considerable overhead for tcp/ip over X.25 as you've
   discovered.  Actual thruput figures will depend greatly on the
   specific implementation...and whether or not your X.25 packet
   network will allow useage of 512-1024 byte packets.  If you are
   stuck with 128 byte packets thruput can be rather slow.

   HOWEVER, if those files are important to you, I wouldn't even think
   of transferring them over X.25 without some type of transport layer
   to protect your data integrity--X.25 alone cannot do this, in fact
   a RESET event GUARANTEES that your data just got corrupted.  
 
   TCP/IP over X.25 is a bit of overkill for data integrity though, as
   the X.25 network will provide protection against data (packet)
   order, individual packet corruption, lost packets, etc.  and in
   fact everything but Virtual Circuit stall, reset, or abnormal
   clear.   

   Does your network allow the use of uucp over X.25?  In our
   customers experience, it provides better thruput since it does
   error recovery a lot closer to the X.25 layers.  


>
>With this experience in mind we would like to do some more tests, but we would 
>like to hear some results from others as well. Is this phenomenon in line with 
>what others see or have we done something wrong completely wrong here ? What 
>about TCP/IP header-compression, is that possible and does it help ?
>
  I don't know of any vendor offering header compression on X.25.



-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 19:33:28 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

peter@ncrpda.curtin.edu.au (Peter N Lewis) writes:
}The following is a proposed specification for the FTP LIST output,
}which is unspecified in the RFC, but which many modern (GUI) clients
}are interpreting anyway.

   [...essentially `all the world is unix' format...]

Yuck!

IMHO, the right solution is a different command "XNLS" (?)
which gives more information in a more flexible and easily
and deterministically parsed format.

BTW, I *specifically* left the useless `link count' out
of the format my ftpd returns partly to thwart this
`all the world is unix' parsing disease.  Of course, I
also refuse to honor the bletcherous passing of "ls flags"
in the LIST/NLST filename-arg too.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 20:46:34 GMT
From:      vsagen@garnet.msen.com (VSA Inc.)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   Re: TCP/IP through a shell account???

James G. Speth (speth@end.com) wrote:
: A program idea came to me today, but before I launch into a coding binge
: I want to get some input as to whether it is impossible or already done.
: I would like to write something similar in functionality to a PPP daemon,
: but one that does not need superuser priveledges to run, and does not modify
: routing tables.  My idea is to take the PPP packet that is received at the
: remote end and analyze it.  Rather than forwarding on the IP packet, the
: daemon would act on the contents of the packet.  If it is a TCP packet,
: then it would open a TCP stream to the destination, and send the data through.  Similarly for UDP.
: For other protocols it would either return errors or ignore them or whatever.

What you are describing is an actuall TCP proxy, as opposed to
something like SOCKS, which is an application proxy.

This would necessarily involve creating a TCP/IP protocol stack so
you could talk to the protocol stack on the other end of the PPP or
SLIP connection.  This is certainly doable, but is a very major
project.

Perhaps you could take source code for TCP/IP and add in your proxy
code and code to maintain the remote and local port/address mapping.

Even still, this is a major undertaking.  Perhaps a better approach
would be to take a program like the SOCKS sockd and hack into 2 parts
that talk over the modem connection.  SOCKS already has a protocol
for passing socket based function call parameters; it should not be
difficult to add an extra field to hold the port numbers of the SOCKS
clients to the packets that go over the modem link between the 2 halves
of the modified SOCKS sockd.

Ron Wilson

Ron Wilson

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 21:06:02 GMT
From:      vsagen@garnet.msen.com (VSA Inc.)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

Billy Barron (billy@utdallas.edu) wrote:
: peter@ncrpda.curtin.edu.au (Peter N Lewis) writes:
 
: >The output should be something like this:
 
: >-rw-------  1 peter         848 Dec 14 11:22 00README.txt
 
: Talk about a UNIX centric view of the world.  To make this
: proposal work, you need to specify how Novell, VMS, VM, etc
: translate their permissions into this format.  I know for
: starters that this information is not sufficient to represent
: the VMS protection schema, which is far superior to the default
: UNIX one.

Actually, it may be sufficient to only indicate read, write and
execute/search permission in the context of the user id the ftp
client has registered with the ftp server.  The other permissions
are generally only relavent when the user has ftp'ed to his/her
own account AND both the ftp client and server allow file manage-
ment commands to be issued by the user.

When I ftp from one of my accounts to another, I almost always
also telnet as well.  I run the file transfers in the ftp session
and do file management in the telnet session.  I find this much
easier to do than to try to do file management only with ftp
commands.

Ron Wilson

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 21:32:29 GMT
From:      jdonahue@world.std.com (Jerry F Donahue)
To:        swnet.lans,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.protocols.novell
Subject:   Network Protocol Analyzer Software




Hi!

We're looking for network protocol analyzer software that will
support tcp/ip, novell, and possibly appletalk. If you have any
user input on some of the commercial packages available we'd be
really interested in hearing them. I'll post a summary to the net
when we've finished. ( We've used a sniffer and like it, but the 
price is a little rich for our needs )

Please reply by email rather than news, if possible.

Thanks in advance,
Jerry Donahue

email:	jdonahue@world.std.com
voice:	804-358-0667 

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 22:09:24 GMT
From:      peng@pirates.cs.swt.edu (Wuxu Peng)
To:        comp.protocols.tcp-ip
Subject:   Re: Why all this fingering?

Mark Jenkins, SAIC/CIR Network Services (marcus@cpva.saic.com) wrote:
: This may have been discussed before, and maybe everyone else already
: knows the answer, but I don't, so here goes:
 
: Why are my DNS machines (at least) being fingered repeatedly by such
: hosts as: bruno.cs.colorado.edu, dino.concicit.ve, maelstrom.oc.com,
: plaza.aarnet.edu.au, mudhoney.micro.umn.edu, netcom5.netcom.com,
: sm0223.mcclellan.af.mil, and others?


I believe that most (if all) of these fingerings are
from the "netfind" service programs running on those
machines. 

If u are being fingered more often than others -->
you site or youself are more important than others  :)

--

--wuxu peng (peng@pirates.cs.swt.edu)


-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 22:18:01 GMT
From:      peng@pirates.cs.swt.edu (Wuxu Peng)
To:        comp.protocols.tcp-ip,comp.unix.osf.misc
Subject:   Re: Anonymous ftp: how to tar/compress?

Bill Stapleton (wls@magrathea.csd.uwm.edu) wrote:
: In article <2ja0h6$4g4@pirates.cs.swt.edu>, peng@pirates.cs.swt.edu (Wuxu Peng) writes:
: >     I am using version 2.1c of wuarchive-ftpd on my DEC OSF1.3a
: > box.  I have problems setting up anonymous ftp to get a
 
: Unless you make special versions of these commands which don't use the
: shared libraries (using "-non_shared"), there's a lot you need to set-up
: in your anonymous ftp area.  Things, like:
 
: 	/sbin/loader
: 	/usr/shlib/libc.so
: 	/etc/sia/siainitgood
: 	/etc/sia/bsd_matrix.conf	(I'm not positive you need
: 	/etc/sia/matrix.conf		 these two)
 
: While you're at it, you should have:
 
: 	/etc/zoneinfo/localtime
 
: Otherwise, ftp may not have the correct time.


Thanks a lot!   My goodness,  without this help, I don't
know how long will it take for me to fiugre it out.  It's
all working.   I also tried -non_shared, but it still needs
/sbin/loader and /usr/shlib/libc.so.

BTW, has anybody successfully set up the upload mode?
I have changed the upload mode for ~ ftplib/incoming
many different ways in   ftpaccess,  but files put
there always have 644 mode.  Do I need some additional
files?  This is annoying, but is not as bad as the previous
one.

--

--wuxu peng (peng@pirates.cs.swt.edu)


-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 22:30:36 GMT
From:      bob@astph (Bob Ford)
To:        comp.protocols.tcp-ip
Subject:   Socketpair Routine on ISC UNIX?

We are currently running ISC UNIX ver. 4.0 on  486-50 MHz machines.
We've been working on on database server for an in-house appliction.
We would like to create a client-server model that allows many client
processes on the client machine and few server processes on the server machine;
for example 100 client processes to 25 server process.

These server processes will need to use IPC's and shared files descriptors
on order to maintain orderly processing of the database files.  We had
hoped to use the "socketpair()" routine in order to pass some open file
descriptors between server processes.  However it seems that we cannot locate
this particular symbol in any of the provided libraries.  Does this
symbol exist in ISC UNIX,  or is there another way to achieve the same 
result?
-- 
Bob Ford                            Voice:(814)234-8592x36
INTERNET: astph!bob@cse.psu.edu	    ALTERNATE: astph!bob@attmail.com
Philadelphia Phillies		    FAX:  (814)234-1269

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Feb 1994 23:00:11 GMT
From:      aseira@crash.cts.com (Ira Cohen)
To:        comp.protocols.tcp-ip
Subject:   Offer General Ledger to beta site


	Need another corporate BETA SITE for a very robust, easy to use
GENERAL LEDGER.   100% Oracle, V6, Forms 3.0, ReportWriter, PL/SQL. 

	If your company's current GL leaves the users wanting, Or if your
organization is considering creating a new GL - consider the functionality
and flexibility of this GL. 

	It was designed to support the needs of demanding companies
needing a sophisticated system.   It does almost everything. 
Easily integrates with existing systems. 

	Supports any CORPORATE STRUCTURE (companies, divisions, profit
centers, departments, jobs, etc, etc).   Each organization may be of a
different percent of ownership, different calendar and different chart of
accounts. 

	REPORT organization's consolidated Income Statement and Balance
Sheet in moments - detail or summary, see posted amounts verses
consolidated amounts. 

	Fast.  Reporting database is specifically designed (summarized) to
execute reports and statements without being a burden on computer
resources.   It's no longer a special request to produce a historic 
statement mid-month.   And, creation of new reports and statements
don't require that programmers have substantial accounting knowledge. 

  Instinctively generates balancing entries for JOURNAL ENTRIES made to
multiple organizations.   Automatic reversal off accruals.   Support for
tax, elimination, recurring entries and cash flow. 

	Quickly create BUDGETS using very intuitive and flexible tool;
multi-version, 4-4-5, percent of increase, copy facility, etc. 


About the system's author:

BS in Accounting('71),   MS Computer Science('78)
Member  -  Oracle Developer's Alliance,  Oracle Consultant's Alliance

	7 years accountant for CPA's & Fortune 500 (Consolidation specialist)

	16 years accounting and manufacturing systems
	programmer/analyst/design leader.
	Past 7 years consultant/contractor to various large companies
	($100 million to multi-billion)

	Designed & developed 4 GL's from scratch
	(Including Data General's General Ledger product offering)
	Enhanced/modified/converted greater than 10 GL's.

	This system applies many years of computer based accounting system
knowledge.   It provides the best attributes and none off the many
pitfalls. 

For further information contact    Internet:  aseira@crash.cts.com
				   Voice:     619-275-4972




-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 01:13:55 +0000
From:      rms@carapace.demon.co.uk (Richard Simmons)
To:        comp.protocols.tcp-ip
Subject:   68000 based source code for TCP/IP


-- 

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 02:49:13 GMT
From:      Mike Turpin <dmt@ornl.gov>
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP and MacTCP

Given below is a problem and followup that I posted on comp.sys.mac.comm.
 As we learned the source of the problem (proxy ARPs), it became apparent
that this newsgroup was probably more appropriate.

I've looked for the FAQ, but couldn't locate it (so forgive me if the
answers to my questions are given there).

========

>>We've recently seen a strange MacTCP dialog appearing on some
>>Macintoshes on restart.  The text of the dialog is:
>>
>>Another device, which has the physical address
>>hhhhhhhhhhhh, is currently using the IP address
>>nnn.nnn.nnn.nnn.
>>
>>where hhhhhhhhhhhh is the Ether address (hex) of the machine that is
>>being rebooted and nnn.nnn.nnn.nnn is its IP address.
>>
>
>Update - we tracked down the source of the problem:
>
>As a Mac starts up, it ARPs for its IP number.  If it hears a
>response, then there may be a case of duplicate IP numbers on the net and
>the user is alerted (this is acutally GOODNESS).  Most often this would
>happen when one user gets a copy of MacTCP from another user and forgets
>to change the IP address in the control panel (the dreaded "floppy
 swappy"
>problem); HOWEVER, normally the ARP would timeout and MacTCP would
 proceed
>(being assured that its address was unique).
>
>What's happening on our net now is that we have a device that is doing
>"proxy ARPs".  So, MacTCP ARPs for itself (hoping to get NO reply) and
 the
>proxy ARPer replies with the address of the original ARPer.  Some devices
>are smart enough to ignore ARPs that contain the device's own
>hardware/network address.  Unfortunately, MacTCP isn't.
>
>We are pursuing shutting off the proxy ARPer for the time being; however,
>from a TCP/IP "purist" standpoint, the operation of the proxy ARPer may
 be
>entirely correct and Apple's implementation of TCP may be at fault. 
>There is, however, evidence that the proxy ARPer shouldn't respond to a
>request for a device that it has heard on the _same_ LAN interface (see
>RFC 925).  
>
>Any TCP/IP purists out there?  Whos fault is this? The proxy ARPer,
>MacTCP, or both?
>
>fyi....current versions of MacTCP (2.02 or greater) will tolerate this
>condition.  Earlier versions refuse to work if there is a response to
>the initial ARP.
>
>Mike Turpin

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 03:11:33 GMT
From:      benjamin@picasso.ucsf.edu (Dennis Benjamin)
To:        comp.protocols.tcp-ip
Subject:   Re: Why all this fingering?

marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services) writes:

>This may have been discussed before, and maybe everyone else already
>knows the answer, but I don't, so here goes:
 
>Why are my DNS machines (at least) being fingered repeatedly by such
>hosts as: bruno.cs.colorado.edu, dino.concicit.ve, maelstrom.oc.com,
>plaza.aarnet.edu.au, mudhoney.micro.umn.edu, netcom5.netcom.com,
>sm0223.mcclellan.af.mil, and others?

	The machines in the above list all offer the "netfind" service
wherein anyone may log in under the username "netfind" and search for
the internet email address of an arbitrary person. You provide the
last name of the person you're after, and a few keywords to narrow
down the list of hosts to be searched (e.g. marcus CIR Network).
The host will then finger the user at a number of machines and
report any hits. I don't think that the servers update themselves
regularly (like an archie server would); this implies that your machines
fall under a keyword that is frequently searched.

Dennis


-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 03:32:00 GMT
From:      bracken@accord.ece.cmu.edu (J Eric Bracken)
To:        comp.protocols.tcp-ip
Subject:   cslip-2.7 + tahoe BSD code?


The documentation for the cslip-2.7 package (for the Sun) mentions
the benefits of replacing the SunOS 4 tcp/ip code with the BSD
`tahoe' release's network code.

Has anybody out there managed to do this?  Was it worth it?  Would
you be willing to share how it was done?

--Eric Bracken

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 94 11:39:05 PDT
From:      Openview_forum@dmewrk1.orl.mmc.com
To:        comp.protocols.tcp-ip
Subject:   OVF 94 Call for papers



_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

       _/_/_/                             _/          _/
    _/     _/                             _/        _/ _/
   _/     _/  _/_/_/    _/_/   _/     _/  _/      _/       _/_/  _/       _/
  _/     _/ _/    _/ _/   _/  _/_/   _/   _/    _/  _/  _/   _/  _/      _/
 _/     _/ _/    _/ _/_/_/_/ _/  _/ _/    _/  _/   _/  _/_/_/_/  _/  _/ _/
 _/    _/ _/    _/ _/       _/   _/_/     _/_/    _/  _/         _/_/_/_/
 _/_/_/  _/_/_/    _/_/_/  _/     _/      _/     _/    _/_/_/    _/   _/
        _/
       _/          _/_/_/_/_/
      _/          _/
                 _/        _/_/    _/_/_/  _/     _/  _/    _/
                _/_/_/  _/    _/  _/   _/ _/     _/  _/_/ _/_/
               _/      _/    _/  _/      _/     _/  _/  _/  _/
              _/      _/    _/  _/      _/     _/  _/       _/
             _/       _/_/_/   _/       _/_/_/    _/        _/

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/




    _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
   _/
  _/              C A L L   F O R   P A P E R S
 _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
                                                             _/
        Orlando Fl Peabody Hotel 8-12 August 1994           _/
                                                           _/
 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

The Second OpenView Forum User/Developers conference on Integrated Network
and Systems Management (OVF '94) will be held from August 8-12, 1994 in 
Orlando Fl, USA, at the Peabody Hotel. 

The OpenView Forum 1994 conference on Integrated Network and  
Systems Management using the OpenView Framework will build on the
successes of OVF 93 conference as the central technical exchange 
forum for the research, standards, development, systems integrator, vendor
and user community for OpenView network and systems management frameworks.

The OpenView Forum community exemplifies the increasing interest 
in overall Enterprise management solutions across all types of networks, 
supporting enterprise communication systems, distributed computing systems, 
database management system, automated Operation systems, facilities management 
systems, help desk management systems and client/server application management. 
 

Authors are invited to submit unpublished papers, as well as proposals for
tutorials, panel discussions, vendor/user/developer demonstrations, or 
birds-of-a-feather sessions (informal discussion groups), in the following 
areas:

 - User requirements, expectations and analysis for integrated network 
   and Systems management

 - Standards issues 

 - Telecommunications management

 - Fault, configuration, accounting, performance, security management
 
 - Help desk

 - Service level management

 - Proactive network management
 
 - Management protocols and protocol management

 - Desktop management

 - Software distribution

 - Database management systems using SNMP/ONC RPC/DCE RPC
 
 - Distributed systems management
 
 - Information interpretation: AI techniques, rule-based analysis

 - Distributed network management between windows & unix platforms

 - Management applications

 - User interface (enhanced graphics for network node device management)

 - User interface for event management for various network protocols
   (SNA, TCP/IP, DECNET, NOVELL, APPLE, etc)

 - Common network repository for configuration, performance, & trouble 
   ticket management

 - Automated network management for configuration, performance, & trouble
   ticket management
  
 - Trials, case studies experiences: solutions, limitations and challenges on
   HOSTMIB, DTMF, Software distribution, DBMS & Email monitoring, Client/Server 
   Application alert/abort/re-start monitoring, RMON, Automated operations, etc

 - Product strategies and different vendor approaches for the OpenView 
   Framework

 - Open topics relating to the OpenView Framework

Please submit six (6) copies of complete papers in English to the address
listed below. The cover page should include paper title, brief abstract, list
of key-words, author(s) full name(s), affiliation(s) and complete address(es),
telephone number(s) and electronic mail address(es).

All submissions will be carefully reviewed by our Program Committee and
returned to the author(s) with comments to incorporate any suggested revisions.
The authors of accepted papers will receive the suggested modifications made by
the reviewer(s) for inclusion in the widely distributed, hard-bound Conference
Proceedings.
 
The final camera-ready copy should be no longer than 12 single-spaced pages.
Final papers arriving too late will be will not be published, and may be
removed from the conference presentation. The authors of accepted papers
must guarantee that their paper will be presented at the conference.

A limited number of stipends are available only to students unable to obtain 
funding to attend the conference. Students whose papers are accepted and who
will present the paper themselves are encouraged to apply if such assistance 
is needed. Requests for stipends should be addressed to Frank Belland,
VP of Technical Operations, at the address below.	


PLEASE SEND COMPLETE PAPERS TO:

Program Chair:
Frank Belland
OpenView Forum
VP Technical Operations
313 Green Reed Road
MP 802-OVF94
De bary Fl 32713
Email: fbelland@dmewrk1.orl.mmc.com
Office: (407) 826-7299
Fax:    (407) 826-7634


Papers should be submitted as soon as possible,
for inclusion in our conference schedule. 

Proposals accepted starting:          March  1, 1994
Deadline for Receipt of Papers:       April 18, 1994
Notification of Acceptance Mailed:    May    1, 1994
Final Camera Ready Papers Due:        June   1, 1994
------------------------------------------------------

Suggestions for Tutorials, Panel Discussions,
Birds-of-a-Feather Sessions, and additional Conference
Topics should be submitted to:

Special Events and Tutorials Chair:

Paul Edmunds
Duke Power Company - CS03D
401 S. College St.
PO Box 1008
Charlotte, NC 28201-1008
Email: paul@hpnet2.dukepower.com
Office: (704) 382-5758
Fax:    (704) 382-0381



Deadline for Receipt of Proposals for Tutorials,
               April 18, 1994
Panel Discussions, Birds-of-a-Feather Sessions,
               April 18, 1994
------------------------------------------------------

ORGANIZING COMMITTEE:
Cathy Lytle
GTE Federal Systems Division
15000 Conference Center Drive
Chantilly VA  22021
Email: lytle@eng.gtefsd.com
Office: (703) 818-4322
Fax:    (703) 818-5484.

Paul Edmunds
Duke Power Company - CS03D
401 S. College St.
PO Box 1008
Charlotte, NC 28201-1008
Email: paul@hpnet2.dukepower.com
Office: (704) 382-5758
Fax:    (704) 382-0381

Frank Belland
Martin Marietta Corporation
313 Green Reed Road
MP 802-OVF94
De bary Fl 32713
Email: fbelland@dmewrk1.orl.mmc.com
Office: (407) 826-7299
Fax:    (407) 826-7634

Rick Sturm 
US West Advanced Technologies
4001 Discovery Drive
Suite 190
Boulder, CO 80303
Email: sturm@advtech.uswest.com
Office: (303) 541-6262
Fax:    (303) 541-6250


ADVISORY BOARD:
Greg Stephens
Hewlett-Packard Company
5725 W. Las Positas Blvd.
Pleasanton, CA 94588
CIS: 73125,1374
Email: greg@hpuplca.nsr.hp.com
Office: (510)-460-1508
Fax:    (209)-599-4729

Bob Natale 
American Computer
209 Perry Pkwy
Gaithersburg MD 20877
Email: natale@acec.com
Office: (301)-258-9850  
Fax:    (301)-921-0434  


PROGRAM COMMITTEE:
Members of the Organizing Committee and Advisory Board
are also members of the Program Committee.


Anyone who would like to volunteer to help with conference planning
please call or email:

Paul Edmunds
Duke Power Company - CS03D
401 S. College St.
PO Box 1008
Charlotte, NC 28201-1008
Email: paul@hpnet2.dukepower.com
Office: (704) 382-5758
Fax:    (704) 382-0381



VENDOR PROGRAM
The Conference offers vendors/users/developers the opportunity to
demonstrate their network management products during five days, in
parallel to the conference. Vendors/users/developers interested in
the opportunity to present products and/or future plans should contact:

OpenView Forum
Frank Belland
Martin Marietta Corporation
313 Green Reed Road
MP 802-OVF94
De bary Fl 32713
Email: fbelland@dmewrk1.orl.mmc.com
Office: (407) 826-7299
Fax:    (407) 826-7634

For information about OVF '94 or to indicate your
interest in participating, please send this form to:

OpenView Forum
Frank Belland
Martin Marietta Corporation
313 Green Reed Road
MP 802-OVF94
De bary Fl 32713
Email: fbelland@dmewrk1.orl.mmc.com
Office: (407) 826-7299
Fax:    (407) 826-7634



Complete/Check items below:

 [ ]  I am interested in attending.

 [ ]  I intend to submit a paper.
      Provisional Title: ____________________________________________

 [ ]  I intend to submit a poster.
      Provisional Title: ____________________________________________

 [ ]  I plan to submit a tutorial proposal. 
      Provisional Title: ____________________________________________

 [ ]  My company is interested in participating in the Vendor Program.

Please send me more information regarding:

 [ ]  Technical Program

 [ ]  Tutorial Program

 [ ]  Vendor Program

 [ ]  Accommodation

 [ ]  Other (Please Specify)__________________________________________

 [ ]  Membership in the OpenView Forum

 [ ]  Volunteer activities for conferences

Name:

Address:
 
City:

Post/State:

Zip Code:

Country:

Phone:

Fax:

Email Internet Addr:

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
/

----------End of Original Message----------






-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1994 18:02:47 +0800
From:      peter@ncrpda.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip,comp.infosystems.gopher,comp.sys.mac.comm
Subject:   FTP LIST Specification proposal

The following is a proposed specification for the FTP LIST output,
which is unspecified in the RFC, but which many modern (GUI) clients
are interpreting anyway.

I'd like to hear any comments anyone has on this specification, and
the issue in general.  I've set followups to go to
comp.protocols.tcp-ip, since that seems to me to be the most appropriate
place for discussion, but I may well be wrong on this...

*****
FTP LIST Specification - Peter N Lewis, Feb 1994.

For a long time the FTP LIST output has been unspecified and yet there
are more and more programs each year that rely on this format in one
way or another.  To try to combat this problem I am proposing a
specification of a LIST format that is easily decoded and very close 
to the current common format.

Please note that I am offering up this specification in the hope of
increasing compatibility amongst servers and clients but no one is 
under any obligation to pay any attention to this document.

It is necessary to distinguish between the output format and the method
of decoding the format since we wish to allow all decoders to interpret
as many of the current versions of the LIST format, while trying to
reduce the variation in the output.

The output should be something like this:

-rw-------  1 peter         848 Dec 14 11:22 00README.txt

The first character should be one of [-dl].  "-" means a file, "d"
means a directory and "l" means a link.  In many cases it may be
preferable to resolve the link and display it simply as a file or
directory, since the client otherwise has no way to tell which it is
except by trying to change directory into it (or by using the -p
switch, see later).  Currently the only way I've been able to find to
determine if a link is a file or directory is to check if it has an
extension (ie terminates in a dot followed by 1 to 3 characters).

The rest of the line should be found by matching
<space><3-letter-month-code><space><any><digit><space><digit|space><digit>
and using the earliest such match (since that string may be part of the
file name.  The month name match should be case insensitive, and should
match one of the twelve English three-letter month abbreviations:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
Servers should always use the English version.  Clients should of course
display the date in the local language and format where possible.  Some 
servers may currently use French month names, so you might like to also 
accept them.

Once you have found that, you can determine the file size by looking at
the number immediately before that match location.  This number may be
missing or invalid for directories, links, or other "file types".

The date format is either:

  MMM DD hh:mm
OR
  MMM DD  YYYY
OR
  MMM DD YYYY 

In the first case, the year is taken to be the most recent past occurence 
of the date.  Servers should choose to switch over well before this becomes 
close to allow for variations in the local time.

And the file name follows the date and continues to the end of the line.
If the file name is a link, it may include a pointer to the original, in
which case it is in the form "name -> link".  This is really very bad,
since that is also a perfectly valid file name under unix and other
systems (especially the Macintosh).

The information between the first character and the size (for files) or
date (for other types) should be ignored as it varies too much between
implementations.

When decoding, it is important to note that many implementations include
a line at the start "total <number>".  Also, they may include the
special files "." and "..".

Servers should try to support the important unix "ls" switches:

-p - add / on the end of directories, especially important for links.
-F - add /, *, @, = to the end of various files.
-l - in the long format described above (ie LIST should ignore it)
-R - recursive listing (some mirroring software relies on this)

Site maintainers should consider the problem of determining the type of
a link and try to maintain the original name or at least the original
extensions (this will also help users as well as client software).

Author:

Peter N Lewis <peter.lewis@info.curtin.edu.au>
10 Earlston way,
Booragoon, 6154, WA,
AUSTRALIA

Contributors:

Editing: Quinn
James W. Matthews <James.W.Matthews@Dartmouth.EDU>

Obviously, any errors in this document are my own!
*****
-- 
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 16:22:34 -0500
From:      ananth@access2.digex.net (A N Ananth)
To:        comp.protocols.tcp-ip
Subject:   FIONREAD, recv() of variable length messages

i am trying to send messages that are composed of a fixed size
header part and a variable size data part (with the length of
the variable sized data part contained in the header) across
a TCP socket interface. as expected, the implementation does
not respect message boundaries and on the receiving side, i
have to repeatedly call recv() to read all received data.

i am trying to minimise use of buffers and reassembly hassles
by using the FIONREAD option of ioctl as under:

typedef struct
{
   int	datlen;		/* data length in octects */
   int	srcid;
   int 	dstid;
   char	msgtyp;
   char msgcode;
} BUFHDR_T;

#define HDRSIZ	sizeof(BUFHDR_T)

typedef struct
{
   BUFHDR_T	hdr;		/* buffer header */
   char		data[256];	/* data portion */
} BUFFER_T;

{ /* code fragment */
   BUFFER_T	buffer;		/* one buffer */
   BUFFER_T	*bufp;		/* buffer pointer */
   int		rc;		/* return code */
   int		datsiz;		/* size of variable data portion */
   int		nbytes;		/* bytes available at socket */

   bufp = &buffer;
   do
   {
      rc = select(...);
      rc = ioctl(s, FIONREAD, &nbytes);
   }
   while (nbytes < HDRSIZ);

   /* header has arrived */
   rc = recv(s, bufp, HDRSIZ, 0);
   datsiz = bufp->datlen;

   do
   {
      rc = select(...);
      rc = ioctl(s, FIONREAD, &nbytes);
   }
   while (nbytes < datsiz);

this scheme is obviously not robust and invariably loses
synchronisation and the task is stuck waiting for bytes
to arrive which never do.

how have others dealt with this? thanx in advance for any
hints.
-- 
ananth	     <ananth@digex.com>        Phone: (410) 765-9281
Prism Communications Inc               "See the colours"

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 08:31:14 GMT
From:      jagane@netcom.com (Jagane D Sundar)
To:        comp.protocols.tcp-ip
Subject:   Re: cluster mbufs

In article <JIM.94Feb9115510@dewar.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>In article <2j8kp3$j1i@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes:
>
>       Could some one explain to me the intricacies of cluster mbufs or show me
>   where to find the information?
>
	Briefly, mbufs are 128 byte structures that can hold data. If the size
	of the packet is bigger you can either chain mbufs together or use
	clusters which are 1k(in 4.3 BSD) buffers. The mbuf flags has M_EXT
	set and the data pointer points to the cluster instead of into itself.

	Your best reference is the Berkeley Net/2 code available widely at
	ftp sites. Use with 'Design of the 4.3 BSD Operating System" by
	McKusick, Karels et al.

	The actual sizes of various structures will probably be based on the
	page size of your machine ( 8K for Suns I believe), and you machine's
	include files will have the exact values. Note that Solaris replaced
	the mbuf scheme with streams buffers.


	Jagane
	to hol

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 94 09:03:01 GMT
From:      avalon@cairo.anu.edu.au (Darren Reed)
To:        alt.security,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Both ACK and ICMP UNREACH (Re: icmp (bombs))

(I missed the start of this thread but hmm....)

prep@yarrow.wt.uwa.edu.au (Paul Repacholi) writes:

>In article <2iofgl$c12@nz12.rz.uni-karlsruhe.de> uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz) writes:
 [...]
>> Getting both an ACK and an ICMP UNREACH can indicate at least these
>> four situations:
>> - the ICMP is spoofed (ICMP bomb)
>> - the ACK is spoofed
>> - the software on the peer host is broken
>> - a temporary routing problem (yes, this *should* not happen)
 [...]
>> So what is the correct way of dealing with this problem, if any? Of
>> course, any ICMP UNREACH should be verified, but what if it matches
>> the ACK?
 
>The correct way is to wait for the connections to time-out and hit
>their re-transmit limit. The ACK is _defined_ as proof that your packet
>got through, and that the ACK-packet got back to you. This should be
>regarded as an existence proof that there is PROBABLY still a path.
>All nak type stuff should be treated as a hint that you can probably
>timeout now, rather than waiting. Doing an 'soon' re-transmit of
>the oldest unacked packet ONLY would be a good place to start.

RFC 1122, 3.2.2.1:

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

And therein lies the flaw.  What would make more sense is to examine
the header found in the ICMP packet closely, check all port numbers
and all the seq/ack numbers and accept if they're inside the window
since the error 'must' be from a recent packet.  I'm not sure what
the wisdom is of having two packets with the same meaning, however,
such as the case of RSTs and port unreachables.

            A Destination Unreachable message that is received with code
            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
            routing transient and MUST therefore be interpreted as only
            a hint, not proof, that the specified destination is
            unreachable [IP:11].  For example, it MUST NOT be used as
            proof of a dead gateway (see Section 3.3.1).

(NOTE: this doesn't counter Port or Protocol `unreachables'.  One might
       wonder, however, at the wisdom of accepting and acting upon a
       "Protocol Unreachable" message after the connection has been
       established.)

But, the good-ol 4.3BSD doesn't seem to regard Host unreachables as a
hint, and closes it in the same manner as a port unreachable.

  It seems, there is nothing which can be done in the case of port
unreachables, they are required as part of compliance with the
requirements for Internet hosts to be there and act with the same
power as the TCP RST flag, although nearly all unix platforms will
send a TCP RST rather than a port unreachable, should a problem
arise (such as it being rebooted while the TCP connection is dormant).

Darren

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 94 10:01:06 GMT
From:      avalon@cairo.anu.edu.au (Darren Reed)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

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

[...]
>At least you can prevent against this on some servers,
 
>	on Suns running SunOS 4.1.x:
 
>		adb -w -k /vmunix /dev/mem
>		nfs_portmon?W1
>		nfs_portmon/W1

If you look in /etc/rc.local on SunOS 4.1.x, the following should be
there somewhere:
...
        if [ -f /etc/security/passwd.adjunct ]; then
                # Warning! Turning on port checking may deny access to
                # older versions (pre-3.0) of NFS clients.
                rpc.mountd
		echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem >/dev/null 2>&1
        else
...
(used and enabled when the C2 option is installed).

>	on Suns running Solaris 2.x
 
>		add to /etc/system
 
>		set nfs:nfs_portmon = 1

Does solaris2 have a similar option in rc.local ?

Putting the adb in rc.local is a good idea, in case you change or recompile
your kernel.  Some Unix variants to have "int nfs_portmon = 0;" in param.c
- nice and convienient :)

Still, who needs to be root when /usr/spool/mail is mounted from the mail
server, is writeable and you can create any file with any perms you like ?
setgid is usually required too so that all mail files are group mail.

Darren

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 10:05:10 GMT
From:      ph10@cus.cam.ac.uk (Philip Hazel)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: How to administer IP address space?  Database/spreadsheet/?

In article <1994Feb8.204256.1@vaxc.cc.monash.edu.au>, (John Mann) johnm@vaxc.cc.monash.edu.au (John Mann) writes:
|> 
|> We currently have 6531 registered IP addresses in 161 subnets and 43
|> subdomains.  We are currently adding about 50 PCs per week. The manual
|> task of editing the forward and reverse DNS tables and the bootptab
|> files is becoming quite a chore :-(.

We have a similar sized DNS zone, consisting of a class B split into subnets, 
and several class C's as well. I have written a Perl script that generates the
zone files for the forward zone and all the reverse zones from a single input
file that looks like a forward zone with a few additional bits of syntax. Not 
only does it do the generation, it checks for a whole lot of errors and so 
protects you from your typing mistakes.

The script is called "makezones", and is available by anonymous ftp from

ftp.cus.cam.ac.uk:/pub/software/programs/DNS/makezones

There are copious comments. You might well be able to massage it into 
generating your bootp tables as well.

Philip

-- 
Philip Hazel                   University Computing Service,
ph10@cus.cam.ac.uk             New Museums Site, Cambridge CB2 3QG,
P.Hazel@ucs.cam.ac.uk          England.  Phone: +44 223 334714

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 12:02:43 GMT
From:      kelly@netcom.com (Kelly Goen)
To:        comp.protocols.tcp-ip
Subject:   Re:TCP/IP through a shell account

 Actually I had a similar thought a time ago and its more related to a 
concept discussed infrequently on the firewalls list...
this is what is known as a tunnelling driver
In my case I PAY for 1 Machine to be connected to the internet on a pretty
much 24 hour basis... however I travel with an MSDOS/Windows
subnotebook with a 14.4 modem... running chameleon TCP/IP/PPP

what I was considering was a SYSV Streams based tunnel driver that would
be pushed onto ip so that connections to that IP would instead be fed first to a ppp driver and then encrypted and encapsulated over UDP out to the detinastion
host running a program designed to communicate over a high numbered UDP
port. The resulting data stream would then be unencapuslated and unencrypted
(decryption would occur here in the first version as Chameleon
 doesnt as yet support this concept ) the PPP Datastream would then be directed
at the serial port the user is logged in over and complete the connection
with the PPP component in the Chameleon TCP... The upstream is of course a
reversal of this concept. This would allow cheap $17.00 per months
shell account to be used with the same funtionality as expensive
$4.00 per hour PPP accounts. 1 Server could service MANY users in this fashion 
 and offer a greater range of functionality...

    what do you think
    kelly


-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 13:08:57 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.novell
Subject:   Re: Network Protocol Analyzer Software

In article <CKz7u6.GJM@world.std.com>,
Jerry F Donahue <jdonahue@world.std.com> wrote:
>
>
>
>Hi!
>
>We're looking for network protocol analyzer software that will
>support tcp/ip, novell, and possibly appletalk. If you have any
>user input on some of the commercial packages available we'd be
>really interested in hearing them. I'll post a summary to the net
>when we've finished. ( We've used a sniffer and like it, but the 
>price is a little rich for our needs )
>
>Please reply by email rather than news, if possible.
>
>Thanks in advance,
>Jerry Donahue
>
>email:	jdonahue@world.std.com
>voice:	804-358-0667 

Klos Technologies, Inc. makes a product called PacketView that handles what
you're looking for.  It's a DOS-based software package that costs $299,
and using your own ethernet adapter (with either a packet driver or ODI
driver) can capture and decode network protocols, including IPX/SPX/NCP,
TCP/UDP/IP, SNMP, VINES IP, XNS and AppleTalk.  It also supports ARCNET and
token-ring.  A demo version of PacketView is available via our BBS at
(603) 429-0032 or anonymous FTP at mv.mv.com:pub/users/klos/pvdemo.zip.

Feel free to call or email if you have any additional questions.

Sincerely,

Patrick Klos
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
============================================================================

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 13:19:36 GMT
From:      cv1540@capvolmac.nl (Martin Tirion)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on X.25 efficiency

Hi,

I am looking for people with experience in using TCP/IP on top of X.25. We are
thinking of implementing this but we would like to exchange some thoughts with
people who have actually seen this work and have done measurements on
performance. We have tried to do a benchmark and it seemed as if a FTP of a 
small file (around 4 kbytes) took TWICE ! as many packets as when bare X.25 was 
used. This got less worse when the files grew larger but the number of packets 
was still considerably larger in comparison to bare X.25. Since we are paying 
per (fixed size) packet this is not a nice thing to have.

With this experience in mind we would like to do some more tests, but we would 
like to hear some results from others as well. Is this phenomenon in line with 
what others see or have we done something wrong completely wrong here ? What 
about TCP/IP header-compression, is that possible and does it help ?

I can't give any specifics about the used software and hardware because I don't 
have them. I am more interested to find out whether this is a general aspect of 
putting TCP/IP on X.25. If it is not we can just get some good hard- & software, 
right ?

Thanks in advance for any information you can share with me.
______
Tom van Peer
Cap Volmac BV, Utrecht, The Netherlands
tom@capvolmac.nl

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 11:43:30 +0100
From:      hajo@sv5.mch.sni.de (Kuras.Hans-Joachim)
To:        comp.protocols.tcp-ip
Subject:   Need Berkeley ftp address for ftp sources

Hi,

I need to have the original Berkeley sources for the implementation
of 'ftp' and 'ftpd' for making a portability report for an OSI-based 
proprietary stack.

So, if anybody  could tell me the Internet Address of an ftp server
at Berkeley.edu carrying this stuff, I'd appreciate very much.

Please don't flame me if it's in the FAQ, but I didn't find it in
comp.answers.

cul8r,
Hajo
-- 
-------------------------------------------------------------------------------
\ \ / / Hans-Joachim Kuras               Siemens Nixdorf Informationssysteme AG
 \ X /  Department BU BA NM 223         Network Mgmnt.-Solutions / SMN Local OS
 / X \  Phone: +49 89 4144 7513                                Otto-Hahn-Ring 6 
/ / \ \ E-Mail: Hans-Joachim.Kuras@mch.sni.de           81730 Muenchen, Germany

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 13:49:41 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

avalon@cairo.anu.edu.au (Darren Reed) writes:

>If you look in /etc/rc.local on SunOS 4.1.x, the following should be
>there somewhere:
>...
>        if [ -f /etc/security/passwd.adjunct ]; then
>                # Warning! Turning on port checking may deny access to
>                # older versions (pre-3.0) of NFS clients.
>                rpc.mountd
>		echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem >/dev/null 2>&1
>        else
>...
>(used and enabled when the C2 option is installed).

There is more of this code in SunOS rc.local.  (E.g., ypbind -s)
I suggest you pretend you have /etc/security/passwd.adjunct
on all occasions.

>>	on Suns running Solaris 2.x
 
>>		add to /etc/system
 
>>		set nfs:nfs_portmon = 1
 
>Does solaris2 have a similar option in rc.local ?

It doesn't have an rc.local.  Using /etc/system to set kernel variables
is much cleaner, IMHO.  (If you're not familiar with /etc/system, you
should know that you don't need to build a kernel.  Just reboot.)

>Putting the adb in rc.local is a good idea, in case you change or recompile
>your kernel.  Some Unix variants to have "int nfs_portmon = 0;" in param.c
>- nice and convienient :)
 
>Still, who needs to be root when /usr/spool/mail is mounted from the mail
>server, is writeable and you can create any file with any perms you like ?
>setgid is usually required too so that all mail files are group mail.

But what if it's mounted nosuid on the server?

Casper

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 15:16:12 GMT
From:      wucolin@popeye.CIS.McMaster.CA (Colin Wu)
To:        comp.protocols.tcp-ip
Subject:   Re: How to administer IP address space?  Database/spreadsheet/?

In article <1994Feb8.204256.1@vaxc.cc.monash.edu.au> (John Mann)  
johnm@vaxc.cc.monash.edu.au (John Mann) writes:
>In article <2hjktc$k6j@netnews.upenn.edu>, tony@scotty.dccs.upenn.edu
>(Anthony Olejnik) writes:
>> What are some of the methods used to administer IP addresses?
>> How do some of the other places out there, keep track of your addresses?
>> 
>Does anyone know of such a IP address tracking system?
>
>Alternatively, does anyone know of a Network Management System that also
>includes such IP address space management tasks?
>
>--

A few years ago I wrote such a program which we still use.  It is a daemon that  
listens for connections on a port that anybody can telnet to.  When someone  
needs an IP address they just telnet to this port on that machine and answer a  
few questions, like the machine owner's name and location, machine's hardware  
address, name, MX names, etc. and the program figures out which subnet and  
subdomain the machine belongs in, assigns it a unique, unused IP address and  
domain name.  The program will also write out all the appropriate DNS entries  
to their respective files, and e-mail the DNS administrator.

One shortcoming of this program is that it doesn't know how to edit or delete  
entries from the DNS files or how to free up IP addresses that are no longer in  
use.  We currently do all that by hand.

Another shortcoming is that there's virtually no documentation (can you say  
zilch?), but you're welcome to take a look.  It's written in generic C and can  
be ftp'd from popeye.cis.mcmaster.ca:/pub/unix/registerd.tar.Z.  E-mail me if  
you can't figure something out.  In the mean time I'll try to throw some sort  
of documentation together.

--
   __     _             _            Colin Wu
  /  )   //            ' )   /       Network Analyst
 /    __|/  o ____      / / / . .    Computing & Information Services
(__/ (_) \_<_/ / <_    (_(_/ (_/_    McMaster University
                                     (905)525-9140 ext 24050

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 15:20:44 GMT
From:      greene@brtph93.bnr.ca (Paul Greene)
To:        comp.protocols.tcp-ip
Subject:   Re: rarp rfc needed!

Can anyone point me in the directions for some documentation
on the "rarp" protocol.  I have a copy of RFC826 which discusses
arp, but I'd also like to get my hands on the rarp specifications.

Any information would be appreciated!

Thanks...

-Paul Greene (greene@bnr.ca)
 *personal opinions*

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 15:23:03 GMT
From:      milos@varda.ics.muni.cs (Mila Blazek)
To:        comp.protocols.tcp-ip
Subject:   rarpd problem on SVR4/PC

Hi everybody,

on my SVR4.0/PC ICL DRS/NX V4.0, rarpd does not respond to rarp packets:

BSDI$ tcpdump rarp
09:27:45.180448 rarp who-is 8:0:20:0:a8:c9 tell 8:0:20:0:a8:c9

SVR4$ ps -ef|grep rarp
    root   287     1  0 08:55:46 ?        0:01 /usr/sbin/in.rarpd -a

SVR4$ ifconfig eth0
eth0: flags=23<UP,BROADCAST,NOTRAILERS>
	inet 147.251.8.32 netmask ffffff00 broadcast 147.251.8.255
	ether 2:7:1:a:d5:3c

/etc/ethers:
8:0:20:0:A8:C9	147.251.8.33   (or name from /etc/hosts)

Any hints ?
Thank you in advance.

Miloslav Blazek                         <milos@muni.cz>
Masaryk university Brno
Czech republic

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 04:43:58 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: FIONREAD, recv() of variable length messages


I wanted and did accomplish exactly as you desire to do with SOCK_STREAM.
In general you have to treat the stream as if it where a serial modem-like
connection and impliment a simple protocol iwth a header struct.
No need for send/recv seq #'s since TCP AND IP are both doing that, but
you do need to manage "packet framming".

1st I was NEVER able to get the "keep msg boundary" sock option to work
on my box; Unixware/Lackman TCP/IP stack (poor implimentation of TCP/sockets).

I use recv(,,,MSG_PEEK) to pre-fetch the pkt byte count, the 1st 2 bytes
of my pkt header. then I do a recv/recvfrom for the byte count.  The real
trick is that pkts >1024 bytes will come in fragmented and the fragmentation
can variy depending on TCP's dynamic MTU size of the moment, which varies
from the 1024 bytes after fresh boot up up to ??? (I've seen it as high
as 8k).  So the recv's for byte count will return less than byte count.

My application was a library for general application asynchronous/SIGPOLL
usage with 1-->N simultaneous circuits, so I had to memcpy the pkt 
fragment to a hidden buffer in the library untill the rest of the pkt cam in.
This ment setting a timer (just grab a copy of time((time_t*)0)) and 
flussh/close this circuit if no data came in > X seconds.

In retrospect, I would no recommend using recv(,,2,,MSG_PEEK) for the 
byte count.  It is possible that these 2 bytes can be split between
TCP buckets and my code will not do the dance that TCP requires to get
the 2nd byte from the next TCP pkt.  TCP I have not observed will
cancatenate the current TCP bucket with the next in the queue untill
ALL of the bytes have been dequeued by recv(), recv(,,,MSG_PEEK), leaves
the bytes queued and will not cause a queueing of the next buckets'
data (I believe?!?!).  Therefore I recommend reading for 2 bytes putting
these in the cache buffer to be saved away if the read for bytecount-2
returns fewer bytes.

I alsow put 2 magic chars at the end of the packet for pkt sanity 
checking and I scratch & sniff  the pkt for sane values in several
header and trailer fields before I pass the pkt on.

The only mechanism for recovering from a de-synchronized stream is to
drain the stream for several seconds, hoping that the next pkt is
synchronised.  I have only seen this in code that either had bugs or 
did not handle network out-bound induced flow controls.  Which is
a chapter in a book in itself.  Which offers me an opportunity to
jab R. Stevens, Rago and more for not writting about network flow control
feed back to the applicatoin and what the applicatoin should do.  After al
that is what us application/library programmers are struggling with
to make a product commercial and robust??!!!!?!?!#$#$^(* especially
under a streams buffer brain dead O.S. like Unixware 1.0 and Lackman@#*&(@#$&U

Good luck it is doable, and the benefit is guarranteed delivery of packet
oriented dtaa unlike UDP.  FYI you can drop pkts at the end of session
or end of a dropped circuit, and you don't know how many pkts wehre
dropped.... Only your recieving app knows for sure.
cs



A N Ananth (ananth@access2.digex.net) wrote:
: i am trying to send messages that are composed of a fixed size
: header part and a variable size data part (with the length of
: the variable sized data part contained in the header) across
: a TCP socket interface. as expected, the implementation does
: not respect message boundaries and on the receiving side, i
: have to repeatedly call recv() to read all received data.
 
: i am trying to minimise use of buffers and reassembly hassles
: by using the FIONREAD option of ioctl as under:
 
: typedef struct
: {
:    int	datlen;		/* data length in octects */
:    int	srcid;
:    int 	dstid;
:    char	msgtyp;
:    char msgcode;
: } BUFHDR_T;
 
: #define HDRSIZ	sizeof(BUFHDR_T)
 
: typedef struct
: {
:    BUFHDR_T	hdr;		/* buffer header */
:    char		data[256];	/* data portion */
: } BUFFER_T;
 
: { /* code fragment */
:    BUFFER_T	buffer;		/* one buffer */
:    BUFFER_T	*bufp;		/* buffer pointer */
:    int		rc;		/* return code */
:    int		datsiz;		/* size of variable data portion */
:    int		nbytes;		/* bytes available at socket */
 
:    bufp = &buffer;
:    do
:    {
:       rc = select(...);
:       rc = ioctl(s, FIONREAD, &nbytes);
:    }
:    while (nbytes < HDRSIZ);
 
:    /* header has arrived */
:    rc = recv(s, bufp, HDRSIZ, 0);
:    datsiz = bufp->datlen;
 
:    do
:    {
:       rc = select(...);
:       rc = ioctl(s, FIONREAD, &nbytes);
:    }
:    while (nbytes < datsiz);
 
: this scheme is obviously not robust and invariably loses
: synchronisation and the task is stuck waiting for bytes
: to arrive which never do.
 
: how have others dealt with this? thanx in advance for any
: hints.
: -- 
: ananth	     <ananth@digex.com>        Phone: (410) 765-9281
: Prism Communications Inc               "See the colours"

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 04:51:38 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Basic socket programming.

Stuart Gresley Staniford-Chen (stanifor@siemens.cs.ucdavis.edu) wrote:
: Hi -
 
: I'm a neophyte network programmer trying to learn the ropes (using the
: book by Rieken and Weiman on Unix network applications).  I have coded
: a simple client/server deal where the server opens a socket and then
: finds and prints it's name (using getsockname).  I then give the
: client the name of the host that the server is on and the port number
: as a command line argument.  The two then exchange some information
: and print it.
 
: All of this works perfectly provided that both are on the same 
: machine and I tell the client 'localhost'.  However, when I try
: to run the client on a different machine it does not work -
: the clients connect() call fails with a Connection refused error.  I
: have checked and the server is still functioning correctly after
: this.
 
: Probably there is something incredibly obvious to the initiate that I
: am doing wrong because I don't know about it.  Any help would be
: appreciated.

FYI: Both read R. Stevens, Network Programming in Unix, and get the src 
contained in this an other network programming books off most archieve
sites in; /pub/books/stevens.netprog.tar.Z on ftp.uu.net or most
oan archive site.  

Check your in_addr struct loading of the client/server addresses!!

You've undoubtedly errored in loading the address.

: Stuart Staniford-Chen
: stanifor@cs.ucdavis.edu


-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 15:32:24 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

	I like the idea of having a standard LIST output.  Unix's ls
output, is not acceptable for a standard (even if it is largely a de
facto one already).  It doesn't allow presentation of enough
information about the file that users of non-unix systems tend to
expect.

In article <2jacc7$knm@ncrpda.curtin.edu.au> you write:
>The following is a proposed specification for the FTP LIST output,
>which is unspecified in the RFC, but which many modern (GUI) clients
>are interpreting anyway.

If those clients are assuming a unix output, then they will likely
break when confronted with other OSes (eg VMS, VM, TOPS-20).  I'm in
the process of writing a universal parser that tries very hard to know
what kind of server it is talking to and parse the output accordingly.
It usually doesn't need to know exactly, because the formats are
distinct enough that it usually has enough information to parse the
output from its context (unless the format changes from a VMS
DIRECTORY format to a Unix ls format).

>The output should be something like this:
>-rw-------  1 peter         848 Dec 14 11:22 00README.txt

I'm not sure that this output has enough useful information in it to
standardize on it.  It is quite Unixy and the internet standards are
not supposed to be this tied to an OS.

>The rest of the line should be found by matching
><space><3-letter-month-code><space><any><digit><space><digit|space><digit>
>and using the earliest such match (since that string may be part of the
>file name.  The month name match should be case insensitive, and should
>match one of the twelve English three-letter month abbreviations:
>Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
>Servers should always use the English version.  Clients should of course
>display the date in the local language and format where possible.  Some 
>servers may currently use French month names, so you might like to also 
>accept them.

This is an english-centric standard.  There are many valid date
formats, some of which have been localized.  Forcing this change would
cause all ftp clients to have to convert english to the local
language.  As it is now, if I connect to a French version of unix (one
in which ls prints french months), and I speak french, then I'll
understand the date.  With this RFC implemented, either I need to
learn english, or my ftp client needs to.  ISO standards for dates
exist, and they should be used.

>The date format is either:
>  MMM DD hh:mm
>OR
>  MMM DD  YYYY
>OR
>  MMM DD YYYY 

There should be some way to get a resolution to seconds, or better.

>Servers should try to support the important unix "ls" switches:
>-p - add / on the end of directories, especially important for links.
>-F - add /, *, @, = to the end of various files.
>-l - in the long format described above (ie LIST should ignore it)
>-R - recursive listing (some mirroring software relies on this)

Uggg.  This too is too unix centric.  -p is a perfectly valid file
name in many places.  How do I know the difference between when the
user wants a certain listing format v information on that file?

Don't get me wrong.  I like this idea.  However, standardizing on the
Unix ls format is not useful.  There is much information that other
OSes drag around about a file that this format doesn't address (eg,
VMS's used v allocated information).

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 05:25:58 -0800
From:      chic@goshen.connected.com (Charles Green)
To:        comp.protocols.nfs,ieee.pcnfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS server to use with PC/TCP ???

Eigil Krogh Sorensen (eks@vki68.aar-vki.dk) wrote:
: Is there a NFS server that can be used on PCs and run together with
: PC/TCP so PC disk(partitions) can be exported from the PC and
: mounted on other computers ?
 
: We use both DOS and Windows.
 
: If so would you please inform me the name of the product and evt.
: where I can get it.

I am using a product ny NetManage called chameleon - it works pretty well.
The easiest way to contact them is by gopher, or E-mail to netmanage.com
I think that this is also an FTP site.

Chic



-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 16:46:52 GMT
From:      magnet@nRCHs022 (MAGNet)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: packet size and the TCP/IP network throughput

Dongchen Lu (dlu@omega.eng.hawaii.edu) wrote:
:      My question is: what packet size is for the best TCP/IP network
: throughput, is it conditional? are there some new documents about performance
: analysis of TCP/IP, or new TCP/IP version have different memory management ?
: 	
:     Thanks for your response  

What needs to be considered when viewing packet size/performance issues
is Inter-Message Gap [IMG]. For every packet sent there is an IMG. So
the smaller your packets, the more overhead from the layer, the larger
your packets (in theory) the better your perfomance. This is a good  
rule of thumb. Don't try testing this with PING though because PING
runs under ICMP not TCP/IP. ;^?

-Brad


--
"Networking is the Vietnam of computing. Something can nuke you from
 behind, and it's gone when you turn around. It's impossible to win a
 guerrilla war against a highly distributed enemy." - Mike Smith.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 17:15:09 GMT
From:      michaelw@desaster.sunflower.sub.org (Michael Will)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   Re: TCP/IP through a shell account???

devmorfo@mtu.edu (Evmorfopoulos Dimitris) writes:
>	Since you are talking about something so restricted, hhave you checked
>out "term" ? And by the way, you need root access on the remote host to grab the 
>ports that will have the data you are talking about.

He definitly meant something like TERM :-) maybe he should try to get it...
...it works wonderful for me...

Cheers, Michael Will
-- 
Michael Will <michaelw@desaster.sunflower.sub.org>   Linux - share and enjoy :-)
Life is not there if you can't share it...        Hazel'O'Connor  Breaking Glass
Happily using Linux 0.99p15 with X11R5, \LaTeX, cnews/nn/uucp/TERM and:     PGP!
                         Analysis ist "kleiner Epsilon".

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 19:09:34 GMT
From:      magnet@nRCHs022 (MAGNet)
To:        comp.protocols.tcp-ip
Subject:   Re: Obtaining local ethernet hardware address.

Frederick G. Slama (slama@ctron.com) wrote:

: 	With-out using ether_hostton(), is there a way to interrogate the
: ethernet interfaces on a local host for their respective 48 bit hardware
: addresses? Can this be done with ioctl()/SIOCGIFCONF to obtain if_req
: structures with the hardware addresses? If so, how is this done? Using this
: technique to obtain inet level protocol information is a breeze, but can
: the same ioctl()/if_req API be used to acquire the hardware address???
: 	If this is a FAQ, please direct me to a site which contains the
: list.


: Thanks!,
 
: 	Fred

There is a public doamain program called "getethers" which will
probes for this. I'm not sure HOW it's implemented however.

-Brad
brad.glidewell@nt.com

--
"Networking is the Vietnam of computing. Something can nuke you from
 behind, and it's gone when you turn around. It's impossible to win a
 guerrilla war against a highly distributed enemy." - Mike Smith.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Feb 1994 20:01:58 GMT
From:      rock@inf.ufrgs.br (Marco Antonio da Rocha)
To:        comp.protocols.tcp-ip
Subject:   network management



Hi my friends!,

I am student of posgraduation course at University of Rio Grande do Sul of Instituto de Informatica - Porto Alegre Brasil, I am working in network management and I would like to know if is posible for you to relate some experiences about network management.  I am going to init a work about proactive management with performance network and I need to investigate which are the principals problems to cause the performance degradation on the network, I am working with TCP/IP network and netWare.

Also if you know some bibliografy references about, it will be very useful for me.

Thanks a lot,


Marco Antonio da Rocha
CPGCC-UFRGS
e-mail: rock@inf.ufrgs.br







-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1994 10:18:36 +0800
From:      peter@ncrpda.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

>Billy Barron (billy@utdallas.edu) wrote:
>: peter@ncrpda.curtin.edu.au (Peter N Lewis) writes:
 
>: >The output should be something like this:
 
>: >-rw-------  1 peter         848 Dec 14 11:22 00README.txt
 
>: Talk about a UNIX centric view of the world.  To make this
>: proposal work, you need to specify how Novell, VMS, VM, etc
>: translate their permissions into this format.  I know for

Not really.  The proposal doesn't require all information to be available,
and anything between the first character and the size are up to the server,
I made no attempt to specify them.  So for example, a VMS directory might
look like this:

d [NLEWISPN] (RWE,RWE,,) 18:25   3 AUG  7  1990 AE.DIR;1
instead of
AE.DIR;1                    3   7-AUG-1990 18:25 [NLEWISPN] (RWE,RWE,,)

Please remember what I am trying to do is to formalize what GUI clients
are already doing, which is interpretting the LIST command's output to
display in a sensible manner (to allow sorting by size or date for instance).
This is already done by clients for the Mac and presumably other machines.

Sure, life would be much better if the FTP protocol supported a structured
list command, but it doesn't, and it probably never will, and even if it
did in some future version of the RFC, it would probably never be implemented
in as high a percentage of FTP servers as are currently parseable as I
described.

Now, if you have other suggestions that solve the problem I describe, please
post or mail me!  Simply saying it doesn't cope with some servers is not
particularly useful, since we currently have no way to cope with any of
the servers!
   Peter.
-- 
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 00:08:44 +0000
From:      rms@carapace.demon.co.uk (Richard Simmons)
To:        comp.protocols.tcp-ip
Subject:   source for 68000 based TCP/IP wanted

I am trying to find a simple and inexpensive way to use ethernet to control
some 68000 based HW. The controller will be some more of the same HW or a PC.

Can anyone direct me to some public domain C source for TCP/IP.

I have examined the Clarkson/Rutgers TCP code but it seems to contain a 
substantial amount of 8086xxx assembly code.

I should also like advice on which ethernet chipset is considered to be
the best or at least the industry standard - I've had problems in the past 
with chips going off the market as soon as I design them in!

Finally where does the most current specification for TCP/IP reside 
and who is responsible for keeping it up to date?

Any information would be greatly appreciated either via this thread or 
by Email to 

            rms@carapace.demon.co.uk 

Richard.
-- 
Z

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 01:03:00 GMT
From:      SEB1525@MVS.draper.com (Steve Bacher)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

In article <2jacc7$knm@ncrpda.curtin.edu.au>,
peter@ncrpda.curtin.edu.au (Peter N Lewis) writes:

>The following is a proposed specification for the FTP LIST output,
>which is unspecified in the RFC, but which many modern (GUI) clients
>are interpreting anyway.

This is certainly a good and overdue idea.

>The output should be something like this:
>
>-rw-------  1 peter         848 Dec 14 11:22 00README.txt
>
>The first character should be one of [-dl].  "-" means a file, "d"
>means a directory and "l" means a link.

But not necessary limited to those 3.   Conceivably you could have
sockets, pipes, block or character special files.  At least you can't
shut out the possibilities.

>The rest of the line should be found by matching
><space><3-letter-month-code><space><any><digit><space><digit|space><digit>
>and using the earliest such match (since that string may be part of the
>file name.  The month name match should be case insensitive, and should
>match one of the twelve English three-letter month abbreviations:
>Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
>Servers should always use the English version.  Clients should of course
>display the date in the local language and format where possible.  Some
>servers may currently use French month names, so you might like to also
>accept them.
 
>Once you have found that, you can determine the file size by looking at
>the number immediately before that match location.  This number may be
>missing or invalid for directories, links, or other "file types".

This is excessively complex for parsing, as well as freezing the
requirement for specific-language month names (why limit to English
and French?).  Much easier would be a word count.  If we can insure
that usernames will never contain whitespace, and no implementation
will display a group id (without a -g flag being passed, at least),
then we can simply count off the number of whitespace-delimited words.

>And the file name follows the date and continues to the end of the line.
>If the file name is a link, it may include a pointer to the original, in
>which case it is in the form "name -> link".  This is really very bad,
>since that is also a perfectly valid file name under unix and other
>systems (especially the Macintosh).

If we can guarantee 100% that:

 every entry which is a link will have "l" in the first character
 every entry which has "l" in the first character will be a link
 every entry which is a link has the string "-> filename" at the end

then we can parse out the link information without running into an
ambiguity with a file whse name contains "->".  Unfortunately, this
all breaks down if the link itself contains "->" ...

Also, exactly one space prior to the "->".  This is because the file
name may contain spaces.  That is why "to the end of the line" needs
to be taken literally.

>The information between the first character and the size (for files) or
>date (for other types) should be ignored as it varies too much between
>implementations.

But this is a standard - we can make people follow it, can't we?
Otherwise what's the point?


--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 04:22:51 GMT
From:      wmchung@ie.cuhk.hk (chung wai man)
To:        comp.protocols.tcp-ip
Subject:   Bottleneck Locating

Hello.

The OSI has 7 layers for communication.  I am interested to locate
the bottleneck on my system, i.e. on which layer the bottleneck of
communicaton lies. I have once used a protocol analyser. However,
I can only have the header info of every ETHERNET frame. I cannot have
info of determining where the bottleneck lies.

If you know how to solve, pls reply by email.

Thanks a lot.


-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 05:40:18 GMT
From:      stanifor@siemens.cs.ucdavis.edu (Stuart Gresley Staniford-Chen)
To:        comp.protocols.tcp-ip
Subject:   Basic socket programming.

Hi -

I'm a neophyte network programmer trying to learn the ropes (using the
book by Rieken and Weiman on Unix network applications).  I have coded
a simple client/server deal where the server opens a socket and then
finds and prints it's name (using getsockname).  I then give the
client the name of the host that the server is on and the port number
as a command line argument.  The two then exchange some information
and print it.

All of this works perfectly provided that both are on the same 
machine and I tell the client 'localhost'.  However, when I try
to run the client on a different machine it does not work -
the clients connect() call fails with a Connection refused error.  I
have checked and the server is still functioning correctly after
this.

Probably there is something incredibly obvious to the initiate that I
am doing wrong because I don't know about it.  Any help would be
appreciated.

Stuart Staniford-Chen
stanifor@cs.ucdavis.edu


-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 15:41:47 -0600
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: Peer to Peer Communication

In article <1994Feb11.213029.21454@csi.uottawa.ca>, u589977@csi.uottawa.Ca
(mforzley) wrote:

>Hi, I am working on a program that will allow distributed machines to 
>communicate in a peer to peer fashion using UDP as a transport mechanism.
>The problem is that I dont want to have a server running and then clients
>will call the server. What I want to do is the following.
>Suppose there are 4 computers on the network. Then machine A can call machine
>B, C or D without knowing in advance whether these 3 machines are running 
>there applications or not. If they are, then the connection will be accepted
>otherwise the machine called will start the application and accept the 
>connection. 

You need to at least have some application running on the server machine
that can fire-up the server application; UDP (nor any other protocol) by
itself can't start up applications. Most Unix boxes have a built in
application (called "inetd") to start up other server applications in
response to TCP connection attempts, but they don't have anything like
that for UDP.

If it is simply a question of not wanting a large process hanging around
all of the time, write a small program that will listen to the appropriate
UDP port and start-up the application when it receives a packet. It can
then forward the packet to the real server application. When the server
application decides that it can exit, it can tell the mini-program that it
is leaving so that it can be restarted if more data comes in.

pr

-- 
Pete Resnick    	(...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 94 15:53:46 PDT
From:      jsnook@halcyon.com
To:        comp.protocols.tcp-ip
Subject:   Re: MIME for Windows and PCs


In article <NADEL.109.0009C546@litc.lockheed.com>, <NADEL@litc.lockheed.com> 
writes:
> Newsgroups: comp.protocols.tcp-ip
> Path: 
nwnexus!cyber2.cyberstore.ca!math.ohio-state.edu!cs.utexas.edu!uunet!butch!litc
lockheed.com!NADEL
> From: NADEL@litc.lockheed.com (Ron Nadel)
> Subject: MIME for Windows and PCs
> Message-ID: <NADEL.109.0009C546@litc.lockheed.com>
> Lines: 7
> Sender: news@butch.lmsc.lockheed.com
> Organization: Lockheed Missiles & Space Co.
> X-Newsreader: Trumpet for Windows [Version 1.0 Rev A]
> Date: Fri, 11 Feb 1994 17:46:10 GMT
> 
> We have Chameleon TCP/IP for Windows on our PCs, but I would like to support 
> MIME on these systems as well to allow for binary attachments of spreadsheets
> etc.  Is there MIME software for Windows available?  Do I need a MIME server?
> 
> Thanks, 
> 
> Ron

Ron:

The latest version of Chameleon TCP/IP for Windows (4.0) supports MIME.
It shipped a few weeks ago.

James Snook
jsnook@halcyon.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 10:10:17 GMT
From:      jlose@clark.net (Jim Lose)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Over X.25?

I'm trying to solve the following problem:

	I have several 486's running SCO ODT, connected on
	an X.25 network. I want the machines to be able to
	communicate over the X.25 network using TCP/IP.

Does anyone know of a product which is installable under SCO
ODT that will enable TCP/IP to run on top of X.25?

Jim Lose 

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 10:16:18 GMT
From:      achilles@theseas.ntua.gr (Achilles Voliotis)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Sparc LX crashing while running cslip-2.7


I have serious problems running cslip-2.7 on a Sparcstation LX running
SunOS 4.1.3_U1 (with all the patches applied). The main problem is that
2-3 minutes that the link comes up, the machine crashes:

Feb 11 00:04:17 theseas vmunix: panic on cpu 0: mget
Feb 11 00:04:17 theseas vmunix: syncing file systems... [2] 4 [2] 4 [2] 4 [2] 4 
[2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2] 4 [2
] 4 [2] 4 [2] 4 give up!

I believe that is a LX-specific problem, since a Sparcstation IPX with
exactly the same configuration can keep the SLIP link up for weeks!

Is this a known bug? Is it a cslip or SunOS bug? Is there a patch that
solves the problem? Please reply by mail (to achilles@theseas.ntua.gr).

Thanks in advance
-- 
						   __            _  _
						  /  )    /     // //
						 /--/ _. /_  o // // _  _
						/  (_(__/ /_<_</_</_</_/_)_

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 94 19:44:26 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP and MacTCP

In article <2jgsv7INN125@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> In article <1994Feb10.024913.24028@ornl.gov> Mike Turpin <dmt@ornl.gov> writes:
>>>What's happening on our net now is that we have a device that is doing
>>>"proxy ARPs".  So, MacTCP ARPs for itself (hoping to get NO reply) and
 the
>>>proxy ARPer replies with the address of the original ARPer.  Some devices
>>>are smart enough to ignore ARPs that contain the device's own
>>>hardware/network address.  Unfortunately, MacTCP isn't.
 
>>>We are pursuing shutting off the proxy ARPer for the time being; however,
>>>from a TCP/IP "purist" standpoint, the operation of the proxy ARPer may
 be
>>>entirely correct and Apple's implementation of TCP may be at fault.
>>>There is, however, evidence that the proxy ARPer shouldn't respond to a
>>>request for a device that it has heard on the _same_ LAN interface (see
>>>RFC 925).
>
> I believe that the proxy ARPer is incorrect.  Proxy ARP is intended to be a
> substitute for routing, to support devices that don't understand subnet
> masks (or have their subnet masks misconfigured -- a common occurrence in a
> PC/Mac environnment).  I suppose this kind of proxy ARP could be useful for
> devices that don't implement ARP; the router would presumably have a
> statically-configured table of ARP entries for these devices, and send the
> appropriate responses.  But if the proxy learned the hardware address via
> ARP, there's no reason for it to respond to ARP queries for that address
> from the same interface (the device has already demonstrated that it
> implements the ARP protocol).

This is all true, but MacTCP isn't following the "robustness principle"
(be liberal in what you accept and conservative in what you send) very well.
Not that I've ever found MacTCP to be very robust... :-)
--
James Harvey   harvey@iupui.edu   IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer:  These are my own opinions.  I do not speak for Indiana University.
He who refuses to read history is doomed to repeat it.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 14:23:25 GMT
From:      lbr@holos.atl.ga.us (Len Reed)
To:        comp.protocols.tcp-ip
Subject:   RFCs on CD-ROM

Are the RFCs available on CD-ROM?  I'm especially interersted in the
TCP/IP suite RFCs.
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358 ext. 16
Domain: lbr@holos.atl.ga.us   UUCP: lbr@holos0.UUCP

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 15:59:47 GMT
From:      jvbunt80@ursa.calvin.edu (Jack VandeBunte)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   Re: TCP/IP through a shell account???

michaelw@desaster.sunflower.sub.org (Michael Will) writes:

>devmorfo@mtu.edu (Evmorfopoulos Dimitris) writes:
>>	Since you are talking about something so restricted, hhave you checked
>>out "term" ? And by the way, you need root access on the remote host to grab the 
>>ports that will have the data you are talking about.
 
>He definitly meant something like TERM :-) maybe he should try to get it...
>...it works wonderful for me...

Is there a TERM frontend for DOS or must one use Linux? 
 
                            -xXx-
If so, where? (fsp/ftp?)
--
jvbunt80@ursa.calvin.edu / TREES ARE FOR THE BIRDS: PAVE THE PLANET!
"I'm a member of the Young Republicans, tomorrows fascists today."
You are here. Resistance is Futile. Subvert the dominant paradigm.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 17:46:10 GMT
From:      NADEL@litc.lockheed.com (Ron Nadel)
To:        comp.protocols.tcp-ip
Subject:   MIME for Windows and PCs

We have Chameleon TCP/IP for Windows on our PCs, but I would like to support 
MIME on these systems as well to allow for binary attachments of spreadsheets
etc.  Is there MIME software for Windows available?  Do I need a MIME server?

Thanks, 

Ron

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 20:16:39 -0000
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Why all this fingering?

In article <1994Feb9.090826.17962@cpva>,
	marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services) writes:
>This may have been discussed before, and maybe everyone else already
>knows the answer, but I don't, so here goes:
>
>Why are my DNS machines (at least) being fingered repeatedly by such
>hosts as: bruno.cs.colorado.edu, dino.concicit.ve, maelstrom.oc.com,
>plaza.aarnet.edu.au, mudhoney.micro.umn.edu, netcom5.netcom.com,
>sm0223.mcclellan.af.mil, and others?

Looks like a lot of netfind servers here...

>It seems to me that the finger protocol was originally developed so that
>people could check to see if someone they knew was logged in, with some
>other added information.  Now my DNS machines are being fingered on a
>regular basis by people I don't know for reasons I don't know.

Not so much to find if you are logged in, but to find if you exist.

>I have heard that it is part of some information gathering project (if
>anyone can give me details I would appreciate it).  What I want to know
>is how other people feel about this, as it seems somewhat invasive to
>me.  Maybe I am too sensitive, but I don't like seeing information
>collection by random probing.

netfind isn't random probing.  It's responding to specific(ish) lookups.
If you want to tailor the behaviour of modern netfind servers, add some
TXT RRs to your DNS setup.  I have the following:

; these are netfind URLs
warwick.ac.uk.    IN   TXT    "wp-dap://C=GB@O=University of Warwick"
warwick.ac.uk.    IN   TXT    "wp-smtp-expn-finger://mail.csv.warwick.ac.uk"

This tells netfind how to do X.500 lookups for my domain, and which machine
to send SMTP and finger queries to.

If you don't want people to be able to do lookups via netfind for
your site, add this record:

machine.dom.ain.  IN   TXT    "wp-noop://"

Cheers,
-- 
Ian 'Vato' Dickinson [ID17]                                 Kibo bait :-)
cudep@csv.warwick.ac.uk  ...!uknet!warwick!cudep         vato@spuddy.uucp
          MIME mail welcome - don't send me no steenkin' X.400
Poke <A HREF="http://crocus.csv.warwick.ac.uk/staff/cudep.html">this</A>.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 20:22:45 GMT
From:      swel@bluecross.on.ca (Steve Welsh)
To:        comp.protocols.tcp-ip
Subject:   Dialup router reply


-- 
Steve Welsh                     \\\///
swel@bluecross.on.ca           / @  @ \   __   __              ___          __
Telecommunications Specialist  |   j  |  [_   /    |_| \    /   |    /\  / / _
Ontario Blue Cross             | (---)|  __]  \__  | |  \/\/   _|_  /  \/  \_|

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 21:22:47 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP and MacTCP

In article <1994Feb10.024913.24028@ornl.gov> Mike Turpin <dmt@ornl.gov> writes:
>>What's happening on our net now is that we have a device that is doing
>>"proxy ARPs".  So, MacTCP ARPs for itself (hoping to get NO reply) and
 the
>>proxy ARPer replies with the address of the original ARPer.  Some devices
>>are smart enough to ignore ARPs that contain the device's own
>>hardware/network address.  Unfortunately, MacTCP isn't.
 
>>We are pursuing shutting off the proxy ARPer for the time being; however,
>>from a TCP/IP "purist" standpoint, the operation of the proxy ARPer may
 be
>>entirely correct and Apple's implementation of TCP may be at fault. 
>>There is, however, evidence that the proxy ARPer shouldn't respond to a
>>request for a device that it has heard on the _same_ LAN interface (see
>>RFC 925).  

I believe that the proxy ARPer is incorrect.  Proxy ARP is intended to be a
substitute for routing, to support devices that don't understand subnet
masks (or have their subnet masks misconfigured -- a common occurrence in a
PC/Mac environnment).  I suppose this kind of proxy ARP could be useful for
devices that don't implement ARP; the router would presumably have a
statically-configured table of ARP entries for these devices, and send the
appropriate responses.  But if the proxy learned the hardware address via
ARP, there's no reason for it to respond to ARP queries for that address
from the same interface (the device has already demonstrated that it
implements the ARP protocol).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 21:23:39 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: RFCs on CD-ROM

In article <1994Feb11.142325.617@holos.atl.ga.us> lbr@holos.atl.ga.us (Len Reed) writes:
>Are the RFCs available on CD-ROM?  

Yes.  Likely sources include the Internet Network Information Center
(look on ftp.internic.net or use gopher or WWW).



-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Feb 1994 22:18:38 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Peer to Peer Communication

> You need to at least have some application running on the server machine
> that can fire-up the server application; UDP (nor any other protocol) by
> itself can't start up applications. Most Unix boxes have a built in
> application (called "inetd") to start up other server applications in
> response to TCP connection attempts, but they don't have anything like
> that for UDP.

inetd does indeed handle UDP--that's how most TFTP servers are fired up.

	Rich Stevens

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1994 09:43:41 +0800
From:      peter@ncrpda.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

jasonh@chineham.euro.csg.mot.com (Jason Haar) writes:

>Are there any plans afoot to rewrite FTP away from this Unix-centric world
>to one that's more generic? (e.g. systems like VAX/VMS and Macs have more
>than one data 'fork' - so how do you transfer two streams at once). It may
>be that the majority of ftp servers on the Internet are Unix - but the
>majority of _clients_ aren't... 

No plans that I know of, and you're right, it is about time.  But I wouldn't
want to see it changed the way you describe.  The protocol needs to be 
machine independent, a problem it currently suffers from in a big way,
rather than as you describe becoming even more machine specific.

Look at the original spec, it supports all sorts of structures and formats
and transfer modes, but in practice, no one implements any of these.

When I wrote my Macintosh FTP server, I tried to make it look like the
Unix FTP server.  Not because I particularly like Unix, but because that
is the defacto standard, that is what users are used to seeing.  In general
I think the client or user should not need to know what kind of machine
they are FTPing to (especially for anonymous FTP), so the information and
commands should look the same on all FTP servers.

Anyway, I personally can't see any overhaul of the FTP RFC having much
chance of success, and certainly it would be many years before the 
majority of servers obeyed any new specification so as client writes
we'd still be stuck with the same problem.
   Peter.
-- 
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1994 10:12:02 -0600
From:      mose@ns.ccsn.edu (Russell Mosemann)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Nuking CLOSING entries in netstat on SS2 4.1.3?

   How does one get entries to go away which show up in netstat -f inet
as CLOSING on a SS2 running SunOS 4.1.3?  They seem to mostly involve
PC's which telnet in and for some reason the connection never closes
down properly.  The Sun then waits forever.  It could be the TCP/IP
implementation on the PC, someone may just power down the PC at the
wrong time, or there might be some other strange reason.
  In any case, how can I get the silly things to timeout and go away?
Rebooting, of course, cures a multitude of problems, but I'm looking for
another solution.  Thanks.
-- 
Russell Mosemann     Concordia College      Voice: (402) 643-7445
Computing Center     Seward, NE 68434       Fax:   (402) 643-4073
"I hesitate to articulate for fear of deviating from the path
 of rectitutde."

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1994 00:24:10 GMT
From:      gasteiz@freeport.uwasa.fi (Brian Bell)
To:        comp.protocols.tcp-ip
Subject:   SIMPLE lan gopher client?

I have set up a simple gopher server on our novell lan ... how
can I connect to it?   PCgopher 2&3 need nameservers ... is
there a way to connect using the server's ip address (123.1.1.1).
The whole thing should operate only WITHIN the lan  ... no
internet access.  Help!  
-- 
----- Meet me in the ravintola! -----

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1994 00:45:42 GMT
From:      andyw@studsys.mscs.mu.edu (Andy Whitcroft)
To:        comp.protocols.tcp-ip
Subject:   Need help finding a tcpip network load reporter


Hi Netlanders,

I am hoping that you can help me with this question. I am
a sys admin of a small network and we are about to add more
servers our network. Therefore, I am looking for a network load
reporter. Ideally, it would tell me the following:

After collecting data for 24 hrs, report number of packets
sent, recvieved, collisions, and others info ( IE kinda like
the netstat util ).

I would either need to know how to do this using the tools
that come with SunOS 4.1.3, or I need to know where to goto
on the net to get a tool to do this.


         T a H d A v N a K n Y c O e U,   Andy  Whitcroft,  N9KWS

+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
|     Comments/Questions to: andyw@studsys.mscs.mu.edu,                     |
|     BUT send flames to /dev/null                                          |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1994 03:45:11 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

SEB1525@MVS.draper.com (Steve Bacher) writes:
}This is excessively complex for parsing, as well as freezing the
}requirement for specific-language month names (why limit to English
}and French?).  Much easier would be a word count.  If we can insure
}that usernames will never contain whitespace, and no implementation
}will display a group id (without a -g flag being passed, at least),
}then we can simply count off the number of whitespace-delimited words.

ftp> dir q*
200 PORT command successful.
150 Opening data connection for file list (127.0.0.1,1153).
-rw-rw----  john     john           3936 Dec 31  1992 quota-info
-rwxrwx---  john     john            331 Jun  3  1993 quota.check
-rw-rw----  john     john           1540 Nov  4  1992 quota.min
-rw-rw----  john     john            871 May 11  1993 quota.stats
226 Transfer complete.

   So much for that theory...

}But this is a standard - we can make people follow it, can't we?
}Otherwise what's the point?

   Such a proposal would never make it as a standard IMHE.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Feb 1994 11:47:52 EST
From:      patlee@panix.com (Patrick Lee)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc
Subject:   Re: Internet Talk client for DOS/Windows?

In article <12FEB94.03040565.0013@lafibm.lafayette.edu> Thayer York <YT50@lafibm.lafayette.edu> writes:

>Anyone out there seen (or written) a program for DOS or (preferably)
>Windows that will emulate an Internet Talk session?  Our school's
>network doesn't support it yet and I would really like to be able to
>talk to someone with out having to telnet somewhere else first.

Winsock talk client is available from:

elf.com:/pub/wintalk/wintalk.zip

It supports both talk and ntalk.

--
Patrick Lee <patlee@panix.com>

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Feb 1994 07:48:55 GMT
From:      Thayer York <YT50@lafibm.lafayette.edu>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc
Subject:   Internet Talk client for DOS/Windows?

Anyone out there seen (or written) a program for DOS or (preferably)
Windows that will emulate an Internet Talk session?  Our school's
network doesn't support it yet and I would really like to be able to
talk to someone with out having to telnet somewhere else first.
Any info would be appreciated.

 -= Thayer =-

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 94 15:50:08 CST
From:      jabussey@ualr.edu (Hip Hop child of the 90's)
To:        comp.protocols.tcp-ip
Subject:   Keyboard LED Network Indicator (Help With TCP/IP)

> The has been alot of talk lately about flashing the keyboard led...
> I am wondering if it would be possible for slip to flash the 
> scroll lock led similar to the network indicator on an xterminal.

I am attempting to write a little proggie that will blink the scroll lock
when we get a packet or send a packet. My problem is that I have NO manuals
on TCP/IP or UNIX internals. Could someone point me to a good document on
both or show me where in the kern to look? I figure that I will have to trap
packets as they arrive or leave then send them on their way or put the code 
directly in the kern. 

Where should I start looking?


Jacque Bussey
U of Arkansas, Little Rock
Computer Data Center

jabussey@ualr.edu


-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 94 17:23:35 CST
From:      jabussey@ualr.edu (Hip Hop child of the 90's)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Online Documents?



	Does anyone know of any GOOD online documents for a novice
Networking programmer using TCP/IP ?



Thanks,

Jacque Bussey
U of Arkansas, Little Rock

jabussey@ualr.edu

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 94 16:05:22 GMT
From:      ellis@nova.gmi.edu (R. Stewart Ellis)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.os.linux.development
Subject:   Re: TCP/IP through a shell account???

jvbunt80@ursa.calvin.edu (Jack VandeBunte) writes:

 >michaelw@desaster.sunflower.sub.org (Michael Will) writes:
 
 >>devmorfo@mtu.edu (Evmorfopoulos Dimitris) writes:
 >>>	Since you are talking about something so restricted, hhave you checked
 >>>out "term" ? And by the way, you need root access on the remote host to grab the 
 >>>ports that will have the data you are talking about.
 
 >>He definitly meant something like TERM :-) maybe he should try to get it...
 >>...it works wonderful for me...
 
 >Is there a TERM frontend for DOS or must one use Linux? 

No, one can use most any UNIX, but not DOS or Mac.

 > 
 >                            -xXx-
 >If so, where? (fsp/ftp?)
 >--
 >jvbunt80@ursa.calvin.edu / TREES ARE FOR THE BIRDS: PAVE THE PLANET!
 >"I'm a member of the Young Republicans, tomorrows fascists today."
 >You are here. Resistance is Futile. Subvert the dominant paradigm.


-- 
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765   ___________________
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.    /   _____  ______ 
  Flint, MI 48504      ellis@nova.gmi.edu               /        / /  /  / /
  Gopher,News and  modem   maintainer, all around hack /________/ /  /  / /

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Feb 1994 18:41:16 GMT
From:      lbd@osreq48.rockwell.com (Lionel Dyck)
To:        comp.protocols.tcp-ip
Subject:   Slip with Cisco CS500

Our telecom folks just installed for testing a Cisco CS500 server and have 
advertised to a few folks to test it as a slip server.  Unfortunately the 
manuals haven't arrived yet (sigh) and we are stumbling around.

When I connect I get a prompt and must type in the word SLIP.  This displays
an I.P. address and MTU.  

Now what do I do:

1.   How do I setup my ifconfig at the calling end?
2.   How do I setup my route at the calling end?
3.   Is there something else I have to do?

If this sounds like I am confused, please forgive me - but I am.

I suspect the I.P. address displayed is the I.P. address of the Cisco port and 
that I have to have an I.P. address for my pc that I am calling in from.  Is 
this assumption correct?

Thanks.

Lionel Dyck - Rockwell International
IBMMail:  USROKNTN     Internet:  lbd@osreq48.rockwell.com


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Feb 1994 19:38:23 GMT
From:      dgilmour@shell.portal.com (David L Gilmour)
To:        comp.protocols.tcp-ip
Subject:   Help! Checksum errors using NOS with PPP

Help NOS or PPP wizards!

I recently reconfigured a NOS 1229 asy interface from SLIP to PPP, and
asked my provider (Portal communications) to make the changes on their end.
Although the PPP chat sequence completes, indicating PPP has started and
the login was successful, I subsequently accumulate checksum errors only,
and ppp pp0 shows no successful packets at the physical layer.  I have
tried all manner of combinations of compression settings, but this problem
seems to be at a lower layer anyway, and I have had no luck.  Any inspired
ideas about what could be wrong here?  Thanks in advance!!

David Gilmour, Los Altos, CA



-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Feb 1994 20:29:15 GMT
From:      setaylor@ingr.com
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Concerned about tcp checksum notice, please help

In article <CKwsxE.4xC@world.std.com> sprowt@world.std.com (Steve Prowten) writes:
>
>Howdy, all -- We occasionally see the checksum message:
>
>    NOTICE: tcp sum: src 80A9D08C, sum 00000010
>
>on the console of our SCO Unix 3.2.4.2 Intel box.  The hex value
>is never the same twice.  We've got an SMC network card, using the
>SCO wdn drivers.  Can anybody tell me what this might be and whether
>it should cause concern?
>
>Many thanks,
>
>S. Prowten   sprowt@world.std.com
>-- 
>Steven Prowten   sprowt@world.std.com

The following is an explanation I received from our network support people
on the same question:
-------
The message contains an IP address of the transmitting node, and the checksum
value. The IP address is a 32 bit number (4 bytes or 8 HEX characters). Each
frame has its own TCP checksum value. The transmitting node will compute a 
checksum value, and the receiving node will compute a checksum value. The two
checksum values must match. But this is not the case in the above session.

Checksum incorrect:

- due to incorrect calculation at remote (transmit)
- due to the network, and network interfaces
- due to incorrect calculation at local node (receive)

--------
The node generating the error in your case for 80 A9 D0 8C would be IP address
128.169.208.140.  This is computed by converting each of the 4 hex numbers
to decimal (e.g. 80 hex = 128 dec).  I know the explanation doesn't tell
you exactly what the problem is, but at least you can figure out which IP
addresses are involved.  Hope this helps

Stan Taylor
Intergraph Corporation
e-mail: setaylor@ingr.com


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Feb 1994 21:44:12 GMT
From:      Thayer York <YT50@lafibm.lafayette.edu>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.apps
Subject:   Telnet w/IBM-3278

Does anyone know of a Winsock Telnet program that has IBM-3278 terminal
emulation?  Any help would be appreciated.

 -= Thayer =- -> yt50@lafibm.lafayette.edu <-

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 94 04:28:49 GMT
From:      proff@suburbia.apana.org.au (Julian Assange)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Online Documents?

jabussey@ualr.edu (Hip Hop child of the 90's) writes:



>	Does anyone know of any GOOD online documents for a novice
>Networking programmer using TCP/IP ?

try rfc1180 (can be obtained from many places, including nic.ddn.mil)

- Julian
--
-------------------------------------------------------------------------------
                            suburbia.apana.org.au 
    Suburbia Public Access Unix - 24 Hr Internet Connection - +61 3 596 8366
===============================================================================

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Feb 1994 11:44:05 GMT
From:      g91s9798@alpha.ru.ac.za (Graham Smith)
To:        comp.protocols.tcp-ip
Subject:   Replacing IP as the bottom layer of the internet



Somebody  recently  posted the following interesting paragraph
in a newslist somewhere:

>We  do  have  to sort something out as in July the powers that
>be  meet  to  decide  on  the replacement for IP as the bottom
>layer  of  the  internet.  Whichever of the three options they
>choose  it  will  mean a lot of kernel and library work to get
>support  done  and in... especially if they do anything stupid
>like  chose  the CLNP option [Any lurkers here who get to vote
>an  the  internet/osi  joint  meeting  please  pick  something
>sensible and implementable not CLNP....]

I  am  curious.  Could anybody who knows anything, please tell
me more. Specifically:
	What are the three options?
	Why these three and why is CLNP, whatever it is, bad?
	Once a base is chosen, when will the 'switchover' date be?

Facts, rumours or red-faced spit blowing flames are all welcome.


Graham



-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1994 15:51:57 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

Graham Smith <g91s9798@alpha.ru.ac.za> wrote:
}>We  do  have  to sort something out as in July the powers that
}>be  meet  to  decide  on  the replacement for IP as the bottom
}>layer  of  the  internet.  Whichever of the three options they
}>choose  it  will  mean a lot of kernel and library work to get
}>support  done  and in... especially if they do anything stupid
}>like  chose  the CLNP option [Any lurkers here who get to vote
}>an  the  internet/osi  joint  meeting  please  pick  something
}>sensible and implementable not CLNP....]
 
}I  am  curious.  Could anybody who knows anything, please tell
}me more. Specifically:
}	What are the three options?

    There is "TUBA" (which is the pro-CLNP camp), and
    "SIPP" which is the "PIP" and "SIP" camps joined.
    I haven't heard much about IPv7 of late, so perhaps
    there is a new contender?

}	Why these three and why is CLNP, whatever it is, bad?

    CLNP is the OSI connectionless network protocol.
    It is basically IP after a committee got its hands
    on it.   One of the major factors against it is
    it has a big bloated packet.  Consider that a single
    telnet byte now acquires 20 bytes of IP and 20 bytes
    of TCP overhead (40:1).  Using CLNP would make this
    close to 100:1.

}	Once a base is chosen, when will the 'switchover' date be?

    Not for several years, perhaps not in this century.

}Facts, rumours or red-faced spit blowing flames are all welcome.

    Send a subscribe message to "big-internet-request@munnari.oz.au"
    to hear it from the horses mouths...

    My preference (and wager) is on SIPP...

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 06:15:52 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

In article <g91s9798.761139845@alpha.ru.ac.za>, g91s9798@alpha.ru.ac.za (Graham Smith) writes:

|> I  am  curious.  Could anybody who knows anything, please tell
|> me more. Specifically:
|> 	What are the three options?
|> 	Why these three and why is CLNP, whatever it is, bad?
|> 	Once a base is chosen, when will the 'switchover' date be?

2 options not three:
i. CLNP with an NSAP allocation scheme designed to fit the problem and existing router 
implementations....albeit costly in hosts
ii. SIPP, with a simplified, better IP header and multicast and real time and 
mobility and smart policy routes and mobile hosts, with pilot host impleemtatins,
but not much i nthe way of routers yet.

CLNP is deemded to be bad (good) by some people as it has a header with fields that dont
fall on neat byte multiple boundaries (e.g. not 2/4/8), and has variable lenght fields
(deemed to be flxible by otehrs though...)

there can be no 'switchover' date - how will you get 2.4 million host system administrators
to agree a single day? 

there will be a period of transition lasting many years....

|> Facts, rumours or red-faced spit blowing flames are all welcome.

well, my point of view, for what its worth (0:-) is that there is no competition:
CLNP exists, so we might as well admit it,
but there are issues of ownershipw of change control, 
so select SIPP as the IPng (IP Next Generation) but recommend people route both
and go with the multiprotocol internet we've come to know and love...

-- 
jon crowcroft (hmmm...)

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1994 20:22:47 GMT
From:      hauck@nic.cerf.net (Harold Hauck)
To:        comp.osf.misc,comp.client.server,comp.databases,comp.os.misc,comp.protocols.ibm,comp.protocols.tcp-ip,comp.unix.aix,comp.unix.large,comp.unix.misc,bit.listserv.ibm.tcp-l,bit.listserv.novell,bit.listserv.techwr,alt.computers.consultants
Subject:   CALL for PAPERS - SHARE SUMMER CONFERENCE - BOSTON MA


                       Call for Papers
            SHARE Summer 1994 Meeting (SHARE 83)
  August 7-12, 1994     Boston Marriott Hotel    Boston MA.

SHARE is the oldest organized user group in the computer 
industry.  SHARE was founded in 1955 by 22 organizations 
about to receive new IBM 704 computers, and has been meeting 
and growing continuously since then.  SHARE's original 
purpose was to promote the SHAREing of information between 
member organizations and their employees.  Over time, 
SHARE's purpose expanded to include influencing IBM and 
other vendor products and directions, and the member 
interest areas grew beyond mainframes to include all aspects 
of computing within the enterprise.  Today, SHARE has about 
1950 member organizations (SHARE Members are organizations, 
rather than individuals), and the SHARE conferences attract 
about 7000 computer professionals each year.

SHARE's mission is to improve the effectiveness of its 
Members' information systems by providing education, 
promoting mutual support, and influencing information 
technology strategies, products and services.  The 
association fosters an environment for joint research and 
development, and provides forums for the exchange of 
information among its Members, with IBM, other vendors, 
other information systems industry organizations, and 
computer professionals.  

Papers submitted in response to this Call for Papers and 
selected for presentation by SHARE will be described by 
their authors in a one hour session to SHARE members at the 
SHARE Summer Meeting to be held in Boston Massachusetts the 
week of August 7 to 12, 1994.  All papers selected for 
presentation will be published in the SHARE Summer Meeting 
Proceedings.  

SHARE emphasizes the use of current and emerging 
technologies to further the efficient and effective use of 
information systems by its Members.  While Member interests 
span both proprietary and open systems computing 
environments, the scope of this Call for Papers is focused 
upon open systems technologies.  Examples of these 
technologies and products include the AIX or UNIX operating 
system environments, TCP/IP communications protocols, client 
server computing using the Distributed Computing Environment 
DCE, and transaction processing with ENCINA or CICS/6000 TP 
Monitors. 
 
Papers in which the author describes the unique use of a 
product or technology, or presents methods to solve 
problems, or discusses the use and interpretation of 
experimental data about a specific situation would interest 
 SHARE members.  Potential topics within the above technology 
and product set may include but need not be limited to:

     Application design, development, or implementation 
     Batch processing and job scheduling 
     Interoperability with MVS, VM, AS400, etc.
     Performance monitoring and measurement 
     Workload forecasting, capacity planning and prediction 
     Internetworking with SNA, TCP/IP, Novell, etc.
     Network design, performance, and management 
     Systems, data, and storage management 
     Database management systems, design or performance 
     End user support 
     Graphics applications and multimedia 
     Office applications, e.g. mail and printing support 
     Parallel processing applications using multiprocessor 
     systems.

Popular papers are reports written by professional 
practitioners who describe some specific finding about an 
implemented system environment.  Although analytical 
techniques and results are of interest to SHARE attendees, 
their primary emphases are on practical issues and 
experiences.  Most SHARE attendees work in operational 
commercial data centers and are responsible for the 
management, production, and operational use of their 
computer installations.  SHARE participants exchange 
information to facilitate achieving their enterprise's 
objectives, they look to the technical presentation sessions 
at the SHARE Conferences as a means to find out about the 
latest computer products, systems techniques, and to enhance 
their personal professional skills.  Authors of papers which 
help SHARE Members achieve these objectives will be 
appreciated and their papers will be well received.

Selection of papers will be through a blind-referee process.  
Editorial assistance will be provided to authors of 
accepted papers.  SHARE policy prohibits using a paper as a 
means to either promote or disparage specific products.  
While the factual comparison and explanation of product 
features are appropriate, authors should be aware that a 
presentation and demonstration program, The Technology 
Exchange, is available at the SHARE Conference for vendors 
to provide product specific information.

To assist individuals who have not previously written a 
technical paper, SHARE will provide a New Author Mentor 
Program.  New authors may use this program to obtain special 
guidance, paper review, and editorial assistance.  Authors 
using this program must adhere to the normal paper 
submission process and schedule.  In addition, by March 31, 
1994, the author must submit two copies of a fully drafted 
paper (not an abstract or outline) along with a letter 
 requesting participation in the Mentor program.  SHARE will 
assign a mentor to contact the author to review and edit the 
submitted paper.  By May 15, the normal paper due date, the 
author will resubmit a revised paper to be considered in the 
normal selection process.  No additional special 
consideration will be given to mentored papers.  

Preference will be given to papers that have NOT been 
previously published or presented.  Authors of papers will 
be required to assign the copyright for their papers to 
SHARE Inc. for publication in the conference proceedings.  
It will be the author's responsibility to secure any release 
required by the author's employer for publication.  Papers 
should be no more than 12 typeset pages including tables and 
illustrations.  

Using normal SHARE conference and Speaker registration 
procedures, authors from SHARE Member organizations may 
attend all SHARE activities.  Authors not employed by SHARE 
Member organizations must register with SHARE as a visitor 
conference speaker. They are welcome to attend SHARE 
sessions during the day they are scheduled to present their 
paper.  Speaker from non member organizations who want to 
attend the full conference may pay the normal conference 
fees and register as a visitor.  Transportation and any 
other expenses associated with the writing and presentation 
of papers are the responsibility of the author.  

Paper Submission Schedule:

March 31, 1994      Paper Submission Form and abstracts (8 
                    copies) due.

May 15, 1994        Completed papers (8 copies) due.

June 31, 1994       Notification of acceptance.

July 22, 1994       Final, camera ready copy and 
                    presentation foil masters due.   
  
August 8-12, 1994   Presentation of papers at SHARE 
                    Summer Conference. 

Inquiries to:

SHARE Inc.
RISC Systems Program Manager
1021 Howard St.
Santa Rosa, CA 95404
Voice,    (707) 573-0498
Fax,      (707) 573-0395
email     hauck@cerf.net

                SHARE 83 Paper Submission Form

When you complete your paper or abstract, please complete 
and attach this paper submission form and provide all of the 
requested information for you and your coauthors.  Your 
telephone number and street address, not a P.O. Box, are 
critical for our future communications.

Paper Title
____________________________________________________________
____________________________________________________________
____________________________________________________________

Has this paper been previously published? __________________

Author Last Name              First Name             Initial

____________________________  _____________________  _______
Company

____________________________________________________________
Street Address

____________________________________________________________
City                          State/Country

____________________________  ______________________________
ZIP/Postal Code               Phone

____________________________  ______________________________
Internet/email address        Fax Number

____________________________  ______________________________

In the event you have coauthors, please provide their names 
and companies.  A maximum of two coauthors can be used.

Coauthor Last Name           First Name             Initial

____________________________  ____________________  ________
Company 

____________________________________________________________
Coauthor Last Name           First Name             Initial

____________________________  _____________________  _______
Company

____________________________________________________________

Please mail this form and 8 copies of your abstract to SHARE 
83 Papers, 1021 Howard St., Santa Rosa, CA 95404.  
Alternately, you may email this form along with your abstract 
to hauck@cerf.net.  Final camera ready papers must be mailed 
to the above address.  
-- 
Harold Hauck
Open Systems Computer Consulting
(707) 573-0498

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 10:24:39 -0800
From:      rag@crl.com (Robert A. Gravley)
To:        comp.protocols.tcp-ip
Subject:   APPC LEAVES TCP/IP IN THE DUST

My boss, a very technical traditional mainframer, dropped an article on 
my desk that stated APPC is faster than TCP/IP in file transfers, etc.  
While I generally let things like this go unanswered ... this article 
has created a huge debate within our organization!  The article was 
written by Kevin Tolly of Interlab.  The article name is, "For File 
Transers, APPC Leaves TCP/IP in the DUST".  It appears in the February 
1994 iusse of DATA COMMUNICATIONS. 

Has anyone else seen this?  Does everyone agree that as the article states: 
 
"And APPC blew the doors off TCP.  In fact, it ran well over 350 percent
faster at the top end (TCP/IP topped out at 3.78 Mbit/s; APPC hit 14.11
Mbit/s)."

I would appreciate any comments and or ideas on how to intelligently 
respond to this .... particularly since my experience does not reflect 
the resluts of this test!!!!!!!

_____________________________________________________________
Bob Gravley
The Indus Group, Inc.
rag@crl.com
_____________________________________________________________


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1994 22:37:10 GMT
From:      gagrawal@cs.tamu.edu (Gopal Agrawal)
To:        comp.protocols.tcp-ip
Subject:   Question on ttcp ..

Hi,

This is a question from a newbie. 

We just started to play around with ttcp. The way to use ttcp is, 
I believe, to execute "ttcp -t xxx.xxx.xx.xxx" on one station and 
"ttcp -r" on the other; where xxxx.xxx.xx.xxx forms the network 
interface address of the receiving station.  

We have sparc stations connected through ethernet as well as 
fddi interface cards. So how does the ttcp on the transmitting 
station know which interface to use to send out the data ? I
looked into the code but could not find any hardcoding as to 
whether it should use ethernet/fddi.  How does one tell ttcp
to use a particular interface to send out data. 

regards,
--   
   ______ ______ ______ ______ __  |\/\/\/|
    ____/  __  /  __  /  __  /  /  |  \  /|  LIFE's COMPLEX - IT HAS
   / __   /   /  /   /  /   /  /   | (o)(o)  REAL & IMAGINARY PARTS.
  /   /  /   /   ___/  __  /  /    C      _) 
_____/ _____/ __/   __/ __/ ______/ | \___|  
E-mail - gagrawal@cs.tamu.edu       |   /   All Std. Disclaimers apply.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Feb 1994 23:35:30 GMT
From:      u1@syscon.ee.unsw.edu.au
To:        comp.protocols.nfs,ieee.pcnfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS server to use with PC/TCP ???

In article <2ittqb$c67@belfort.daimi.aau.dk> eks@vki68.aar-vki.dk (Eigil Krogh Sorensen) writes:
>Is there a NFS server that can be used on PCs and run together with
>PC/TCP so PC disk(partitions) can be exported from the PC and
>mounted on other computers ?
 
>We use both DOS and Windows.
 
>If so would you please inform me the name of the product and evt.
>where I can get it.


>Thank you in advance
 
>Eigil Krogh Sorensen
 
>---------------------------------------------------------------------
>        Address:       Water Quality Institute
>                        Science Park Aarhus
>                        10, Gustav Wieds Vej
>                        DK-8000 Aarhus C
>                        DENMARK.
 
>        Phone:          +45   86 20 20 00    or
>                        +45   86 20 20 11  local  2114
 
>        Fax:            +45   86 19 75 11
 
>       E-mail:         eks@aar-vki.dk
>----------------------------------------------------------------------
There is a product called "idrive" which is a product of FTP software Inc. -
the same people who produce PC/TCP.

Regards,
	- jeff
	J.Lee@unsw.edu.au

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Feb 1994 23:47:34 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

In article <2jacc7$knm@ncrpda.curtin.edu.au>,
Peter N Lewis <peter@ncrpda.curtin.edu.au> wrote:

>The following is a proposed specification for the FTP LIST output,
>which is unspecified in the RFC, but which many modern (GUI) clients
>are interpreting anyway.
 
>-rw-------  1 peter         848 Dec 14 11:22 00README.txt

I'd like to join the chorus which says that this format is a bad idea.
My vote is for a special command to provide extra list info.  This
will allow LIST to continue to provide OS-dependent information which
can be useful to the human reader.

There seems to be a consensus that the following is needed:

- modification date/time
    RFC822 specifies a universally-used format. Why switch? Yes, it uses
    English month abbreviations. Use ISO dates if this offends.
    The date/time ad-hoccery that Unix "ls" indulges in is not
    otherwise standard, and is annoyingly inconsistent for machine
    parsing.

- file size
    But these are not always cheaply available to byte precision; e.g.
    a VMS machine cannot determine the size of a text file without
    reading it all. Nor can a Unix machine, come to that, if it's FTP
    text format we're talking about. MSDOS is OK :-)

- flag for subdirectory
    I.e. is name following is a valid argument for the CWD command?

- file name
    We probably need quotes here, if we're going to make this
    bomb-proof. Posters have pointed out that spaces are valid in Mac
    filenames. Well, so they are in Unix ones. And newlines...
    It's probably good enough to put the name last, and say that
    anything up to <CR><LF> is a filename.

Since FTP is *not* a remote filing system, information about links is
pretty well irrelevant. Unix-style hard links can be ignored, and
symbolic links, special files etc. are not relevant to the FTP client.
If a remote system has a symbolic link, the client should not need to
know about it.

The type of file, and its permissions, is IMHO not nearly as useful. The
concept of "permission" varies so much between OSes as to be useless.
The only things that matter under FTP are:
 can I get this file
 can I CWD to this entry

The other things you need to know (e.g. can I remove the directory) can
be found out by trying them. The two I mention are all that's required
point-and-click FTP clients or Archie-like programs.  I'm not
interested that the file is owned by "root", [SYSTEM] or whoever, or
that it has execute permission.

The issue of complex data streams (multiple parts) is not one which FTP
should be burdened with. This is a *transfer* utility, not a filing
system. Think of the FTP data stream as a tape device. All OSes that
use this sort of thing already have a standard for dealing with it.
You can, for instance, FTP files between two VMS machines and preserve
the "out-of-band" structure.

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm. News admin, pipex. Internic: IP4
"... we had no interoperability goal when designing ****.  Therefore the product
interoperates with itself." [A quote from a developer of a TCP/IP product.]
Name omitted to protect the guilty.

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 94 00:30:39 GMT
From:      minich@a.cs.okstate.edu (Robert J Minich)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

by billy@utdallas.edu (Billy Barron):
> Talk about a UNIX centric view of the world.  To make this
> proposal work, you need to specify how Novell, VMS, VM, etc
> translate their permissions into [UNIX] format. [...]

I think Billy is missing the point. The proposal is trying to specify a
machine interpretable format for LIST output. If you agree that UNIX is
the most common OS to find on the server end of an FTP session, then
standardizing around that format for LIST output can be a reasonable
proposition since most existing server software will remain almost exactly
the same! Of course, that's not to say I _like_ format.

My impression is that the FTP spec was designed for _humans_ to get
files, which _they_ know how to access, from one place to another. Thus,
hiding the server's OS is a mistake since the user can figure out
what to do. Thus we end up with a LIST spec that allows you to assume
nothing.

Now, as long as we are at it, I'd prefer a new FTP command to return a
machine readable listing. It should be extensible and provide, if desired,
access to info from the native OS. Client software would attempt to use
the new command and fall back to the old one where necessary.

I assert that what most FTP client software would like to know is:

	1. What's the object's name?
	2. Can I CWD into it?
	3. Do I have permission to retrieve it?
	4. How many bytes would you send if I retrieved it?

All the rest is gravy. I would suggest some sort of query like the
following: (note that XMRL = X-Machine-readable-list

	XMRL <PATH=.> <ATTRIBUTES=NAME,TYPE,SIZE,CAN_READ>

which would return something like

	<.,directory,512,true>
	<..,directory,512,true>
	<README,file,2374,true>
	<name with spaces,file,31,true>
	<name with \> bracket,file,0,true>
	<name with\, uh\, commas,file,0,true>
	<name with back slash\\,file,0,true>

an example for UNIX-specific info:

	XMRL <PATH=/> <ATTRIBUTES=NAME,<UNIX=MODE>>

	<.,<drwxr-xr-x>>
	<..,<drwxr-xr-x>>
	<README,<-rwxr--r-->>
	<name with spaces,<-rwxr--r-->>
	<linked file,<lrwxr-xr-x>>

a Macintosh specific example:

	XMRL <PATH=.> <ATTRIBUTES=NAME,TYPE,<MACINTOSH=TYPE,CREATOR>>

	<Readme,file,<TEXT,MACA>>
	<Some file.sit,file,<SIT!,SIT!>>
	<Subdirectory,directory,<,>>

(Notice the empty fields in the last entry. Mac gurus will note that Mac
directories are not individual files.)

And last, an example for errors:

	XMRL <PATH=.> <ATTRIBUTE=NAME,<UNIX=MODE>>
	### Unknown attribute: <UNIX=MODE>

where ### is some useful error number on the control stream.

To make this useful for client software, we'd have to restrict, for
example, what we call a "directory" to something you can CWD into.
Other interesting points might be that the size of a transferred file is
different for text vs binary on many (most?) machines due to end of line
conversions. Also, for each OS, there should be a standard set of
attributes for interoperability.

It seems like a lot of work with all sorts of pitfalls to get a
workable standard that provides genuinely useful functionality
without becoming so broad that noone implements it.

I propose that a minimal XMRL implementation would support the following
attributes:

	NAME      The name of the file with '\' '>' and ',' escaped.
	SIZE      The number of bytes (approximately) that this file would
	          would occupy if retrieved in the current mode.
	TYPE      One of "file" or "directory", where the latter may be
		  used only for objects that are valid arguments to CWD.
	CAN_READ  Either "true" or "false".

Server specific attributes would be designated as a tuple of
<os_name=attribute_list> in a recursive manner. Note that an
implementation could support more than one OS.

	XMRL <PATH=.> <ATTRIBUTES=NAME,<UNIX=MODE>,<MACINTOSH=TYPE>

This is by no means a formal (or even well thought) out proposal, but I'd
love to hear others' thoughts on the above.
-- 
Robert Minich
minich@a.cs.okstate.edu   | "If that theory should ever reach the Miradorn,
Oklahoma State University |  I'd wake up dead one morning." -- Quark

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 02:07:26 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

In article <2jliat$haj@news.iastate.edu> john@iastate.edu (John Hascall)
writes: 

    }	What are the three options?
    
        There is "TUBA" (which is the pro-CLNP camp), and
        "SIPP" which is the "PIP" and "SIP" camps joined.
        I haven't heard much about IPv7 of late, so perhaps
        there is a new contender?
    
The third contender is CATNIP.  I can't really do it justice, so I won't
even try.  It is viable.

    }	Why these three and why is CLNP, whatever it is, bad?
    
        CLNP is the OSI connectionless network protocol.
        It is basically IP after a committee got its hands
        on it.   One of the major factors against it is
        it has a big bloated packet.  Consider that a single
        telnet byte now acquires 20 bytes of IP and 20 bytes
        of TCP overhead (40:1).  Using CLNP would make this
        close to 100:1.
    
One of the major factors favoring CLNP is that the address has enough bits
in it so that we need not ever worry about under-engineering the address
space again.  If CLNP was used according to the OSI specs (which is NOT a
given), the CLNP header is ~50 bytes, so your ratio would be more like
70:1.

    }	Once a base is chosen, when will the 'switchover' date be?
    
        Not for several years, perhaps not in this century.
    
In fact, there will not be a "switchover".  There should be a gradual
transition.  If there isn't, it doesn't matter as no one will use it
anyhow.

        Send a subscribe message to "big-internet-request@munnari.oz.au"
        to hear it from the horses mouths...
    
Neiiigggghhhhhh.....  ;-)

        My preference (and wager) is on SIPP...

d) None of the above.

Tony

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 03:40:57 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on ttcp ..

In article <2jma2m$m5d@news.tamu.edu> gagrawal@cs.tamu.edu (Gopal Agrawal) writes:
>We have sparc stations connected through ethernet as well as 
>fddi interface cards. So how does the ttcp on the transmitting 
>station know which interface to use to send out the data ? I
>looked into the code but could not find any hardcoding as to 
>whether it should use ethernet/fddi.  How does one tell ttcp
>to use a particular interface to send out data. 

Ttcp just hands the packets to the TCP or UDP protocol socket, and the OS
handles the decision about which interface, just as it does for any other
network application.  The choice of interface is determined from the
destination address.  The system's routing table, which is displayed with
"netstat -r", includes the interface that will be used for transmitting to
any particular address or network.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 11:19:25 GMT
From:      pablo@gandalf (Pablo Brenner)
To:        comp.protocols.tcp-ip
Subject:   MTU Discovery acceptance

Hi folks,
	I'm trying to know how widely accepted is the
MTU discovery protocol.

Can I assume that most workstations imnplement it?

thanks.

-- Pablo

P.S. Please reply by email to pablo@lannet.com

--
Pablo Brenner - pablo@lannet.com
LANNAIR Ltd - Wireless Connectivity
Addr: Atidim Technological Park - Tel Aviv 61131 - ISRAEL
Phone: Intl+972-3-6458-375
Fax:   Intl+972-3-5447-146

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 11:47:08 -0000
From:      obyrne@iol.ie (Chris O'Byrne)
To:        comp.protocols.tcp-ip
Subject:   HELP!  Sending e-mail to an IP address.

Help!  I want to send e-mail to a machine which is on the net (ie has a
working IP address) but which is not listed in the nameserver database.
Is there a gateway or a syntax I can use??

Thanks,
Chris
--
Chris O'Byrne          (obyrne@iol.ie)

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 94 13:28:59 GMT
From:      cracauer@wavehh.hanse.de (Martin Cracauer)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mai

ian@unipalm.co.uk (Ian Phillipps) writes:

>In article <101675@cup.portal.com>,
>Dana B Bourgeois <FelineGrace@cup.portal.com> wrote:
>>I would like to see PC-NFS support TCP as soon as possible.  Hopefully
>>the next version?
 
>If it's a NFS-over-TCP client on a PC that you're after, then there's at
>least one available, since PC/TCP supports it: I don't know of any
>others at present. Details from info@ftp.com, or reply to me, since my
>employers sell this in Europe.
 
>Unfortunately, NFS servers supporting TCP are in shorter supply at least
>on commercially-available systems; I believe that BSD 4.4 has it.
>Interstream demonstrated a TCP/NFS at one Interop, but have never
>released it.

FreeBSD for Intel 80x86 supports it. Found speed of the server
comparable to normal Sun SPARC workstations.

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>,Voice+4940-5221829,Fax.-5228536

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 14:01:31 GMT
From:      Jim.Rymerson@qucdnadm.QueensU.CA (Jim Rymerson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.apps
Subject:   Re: Telnet w/IBM-3278


QWS3270 is a winsock compliant TN3270.  It is available from 
ftp.ccs.queensu.ca in the pub/msdos/tcpip directory.

Jim.
 
In article <12FEB94.18075665.0024@lafibm.lafayette.edu> 
Thayer York <YT50@lafibm.lafayette.edu> writes:>From: Thayer York 
<YT50@lafibm.lafayette.edu>>Subject: Telnet w/IBM-3278
>Date: Sat, 12 Feb 1994 21:44:12 GMT
 
>Does anyone know of a Winsock Telnet program that has IBM-3278 terminal
>emulation?  Any help would be appreciated.
 
> -= Thayer =- -> yt50@lafibm.lafayette.edu <-


-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 94 14:28:50 GMT
From:      thomas@ft4.serum.kodak.com (Th. Bullinger (6-9922))
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Advise: Setup of network

[ Article crossposted from biz.sco.general ]
[ Author was Mr. Bulli (private account) ]
[ Posted on Sun, 13 Feb 1994 16:29:42 GMT ]

Hi Netters,

I'd like to setup a network of my computers at home and would like to have
some advise.

Here is y situation:

-	IBM AT 386DX with SCO UNIX 3.2.2 installed, TCP/IP package available
	(but not yet installed), UUCP installed
-	IBM AT 386DX with MSDOS 5.0, Qemm, Stacker installed
-	IBM AT 386SX with MSDOS 5.0, Qemm, Stacker installed

Here is my "dream":
-	UNIX box as server (with NFS, FTP)
-	DOS boxes as clients (with telnet, ftp, rlogin)

What do I have to do? What ethernet cards are the cheapest/easiest to
implement? What software do I need to accomplish this goal?

Any hint/tip is appreciated,

-- 
--______ __ --------- This message contains only my own opinion ----------
    /   /  ) Work address: thomas@idx.kodak.com       Phone: (716)726-9922
   /   /--<  Home address: mrbulli@btoy1.rochester.ny.us
(_/   /___/  Compu$erve  : 76535,2221                 FAX  : (716)726-7713

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 14:56:45 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

In article <g91s9798.761139845@alpha.ru.ac.za> g91s9798@alpha.ru.ac.za (Graham Smith) writes:

>I  am  curious.  Could anybody who knows anything, please tell
>me more. Specifically:
>	What are the three options?

There are three proposals before the Internet Engineering Task Force
(IETF), which is the group that looks after the Internet protocol
suite (TCP/IP and friends).  

  The proposal that is most similar in design to current IP is called
the "Simple Internet Protocol Plus (SIPP)".  Its draft specs are
online as Internet Drafts (filenames of the form "draft-ietf-sip-*" at
the I-D archive site near you, for example ftp.internic.net).

  The proposal that is CLNP renamed with TCP on top instead of
CLTP/TPx is called "TCP/UDP with Bigger Addresses (TUBA)" and has an
experimental RFC or two out and maybe one Internet Draft.  This
proposal does not include published specs of all of the capabilities
of current IP (e.g.  Multicast is missing).  These deficiencies bother
many folks.

  The third proposal is currently called "CATNIP" and has very little
actual support (as near as I can tell, less than 10 people are working
on it).  This proposal is unlikely to be selected, IMHO.

>	Why these three and why is CLNP, whatever it is, bad?

They were the only 3 proposals made when the IETF made a public call
for proposals for next-generation IP.  The process is completely open,
one could hypothetically create a new proposal even now, though it
would now be hard to get it fully developed enough by the evaluation
deadlines.

>	Once a base is chosen, when will the 'switchover' date be?

There is general agreement that a "switchover date" isn't technically
or operationally feasible.  The transition to next-generation IP will
have to be gradual.  Many consider the transition mechanism proposals
to be the more critical parts of this whole IETF effort.

Ran
atkinson@itd.nrl.navy.mil



-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 15:02:06 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MTU Discovery acceptance

In article <1994Feb14.111925.21468@aristo.tau.ac.il> pablo@gandalf (Pablo Brenner) writes:
>Hi folks,
>	I'm trying to know how widely accepted is the
>MTU discovery protocol.
>
>Can I assume that most workstations imnplement it?

An increasing number of workstations implement it.  Most routers
implement the parts that they need to implement.

There is increasing pressure on commercial vendors to include it in
their shipping code, but it is not universal just yet.  All vendors
SHOULD implement it already.

It is a standards-track Internet protocol, so it is widely accepted
in the community as an important part of IP.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 15:27:26 GMT
From:      davel@to.mobil.com (Dave Linthicum)
To:        comp.protocols.tcp-ip
Subject:   Network Effciency

A question.  If network efficiency can be roughly 
estimated using the following formula:

E = M/(M+O)

where:

M = Message size
O = Overhead needed to send one message
  = (Px delay x speed) + ACK size + H
P = NUMBER OF PACKETS SENT
H = HEADER SIZE 
ACK = Acknowlegment message of meassage received

And IEEE 802.3 uses this formula such as:

E = 100/(100 + 30 + 64 + 2(64) = 31%

What is 30, 64, and 2(64)?  This is in a network modeling book, 
I can't figure it out.

    --Dave

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 15:43:49 GMT
From:      timbuck@borg.lib.vt.edu (Tim Buck)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   10BaseT connected directly?

Is it possible to connect 2 PC's with 10BaseT directly to one another
(without a hub)?  Twisted pair cable seems to be cheaper than coax (not
to mention easier to run along walls, etc.).  This would be to connect
2 PC's at home.
-- 

Timothy Buck              / timbuck@borg.lib.vt.edu  -  Phone (703) 231-4159
Timbuck128@aol.com        / Recognition Research, Inc. -  Fax (703) 231-3568
rri!tim@vtserf.cc.vt.edu  / 1872 Pratt Dr, Suite 1200, Blacksburg, VA  24060

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 16:09:16 GMT
From:      dennis@westford.ccur.com (Dennis Rockwell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on X.25 efficiency

In article <CL0Foo.514@capvolmac.nl>,
Martin Tirion <cv1540@capvolmac.nl> wrote:
>Hi,
>
>I am looking for people with experience in using TCP/IP on top of X.25. 
> [ ... ] Since we are paying      
>per (fixed size) packet this is not a nice thing to have.

Given this, you should tailor your network's MTU to fit 
closely into a multiple of your X.25 packet size, since TCP 
builds its segments to fit exactly into the network's MTU
(avoiding IP-level fragmentation -- the IP over X.25 driver  
must deal with X.25-level fragmentation).  The higher the
multiple, the better, since the per-TCP-segment overhead (40
bytes) would be amortized across multiple X.25 packets.

Of course, this won't fly at all if the hosts aren't
directly connected to the X.25 net, since they must adhere to
their directly-connected network's MTU, and gateways cannot
resegment TCP traffic, they can only IP fragment, which can
only add to your overhead.

-- 
Dennis Rockwell
Concurrent Computer, Westford MA USA

dennis@westford.ccur.com

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 16:26:19 GMT
From:      jfoss@csn.org (Jim Foss)
To:        comp.protocols.tcp-ip
Subject:   RFI: Firewall s/w wanted forgw


I am looking for some software, or a firm that can take my current setup 
with a SCO 3.2 firewall and modify it.

I have the need to allow users on my Novell ethernet to ftp, telnet, etc 
strait out on the Internet without stopping by the firewall first.

I heard of a program called socks.  I investigated this and It looks like 
what we would like to acomplish but, socks will not do it with a DOS
enviroment on the other side.  It has special UNIX clients that will go
through a firewall that you run socks on.

I am in desperate need of a solution.  If anyone can recommend some
software or a firm that would make these changes I would be grateful!

Thanks!

Jim Foss
Mind Extension University
jfoss@meu.edu


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 16:37:30 GMT
From:      wucolin@popeye.CIS.McMaster.CA (Colin Wu)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   [Quest] Getting started with FDDI

Hi, all.

Looks like we're going to be converting our compus backbone to FDDI, and I'm  
going to be one of the people to figure out how to do it.  Could someone please  
point me to a good starting spot? (RFCs, books, etc)

--
   __     _             _            Colin Wu
  /  )   //            ' )   /       Network Analyst
 /    __|/  o ____      / / / . .    Computing & Information Services
(__/ (_) \_<_/ / <_    (_(_/ (_/_    McMaster University
                                     (905)525-9140 ext 24050

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 17:28:01 GMT
From:      rdk@cc.gatech.edu (Bobby Krupczak)
To:        comp.protocols.tcp-ip
Subject:   Streams TCP/IP for SunOS?

Hi!

Are there any commercial or public domain implementations of the TCP/IP protocol
suite available in Streams for SunOS 4.1.x kernels?

Thanks,

Bobby



-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 17:41:54 GMT
From:      mack23@andre.mech.nwu.edu (Chris Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: Obtaining local ethernet hardware address.

In article <2je0pe$d1e@corpgate.rich.nt.com>, MAGNet <magnet@nRCHs022> wrote:
>Frederick G. Slama (slama@ctron.com) wrote:
>
>: 	With-out using ether_hostton(), is there a way to interrogate the
>: ethernet interfaces on a local host for their respective 48 bit hardware
>: addresses? Can this be done with ioctl()/SIOCGIFCONF to obtain if_req
>: structures with the hardware addresses? If so, how is this done? Using this
>: technique to obtain inet level protocol information is a breeze, but can
>: the same ioctl()/if_req API be used to acquire the hardware address???
>: 	If this is a FAQ, please direct me to a site which contains the
>: list.
>
>
>: Thanks!,
 
>: 	Fred
>
>There is a public doamain program called "getethers" which will
>probes for this. I'm not sure HOW it's implemented however.


It looks to me (and I am *not* a network programmer), that ioctl()/SIOCGIFCONF
is used in gethers' "if.c" module to obtain the IP addr of each interface.
Later, /dev/nit is opened, and the hardware address obtained therefrom.

Chris 


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 94 23:04:53
From:      drw@severi.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <2jofl7$9gm@crl2.crl.com> rag@crl.com (Robert A. Gravley) writes:
   "And APPC blew the doors off TCP.  In fact, it ran well over 350 percent
   faster at the top end (TCP/IP topped out at 3.78 Mbit/s; APPC hit 14.11
   Mbit/s)."

   I would appreciate any comments and or ideas on how to intelligently 
   respond to this .... particularly since my experience does not reflect 
   the resluts of this test!!!!!!!

One point which does not seem to have been addressed is that the test
presumes that the momst reasonable test of a prococol's "performance"
is the rate at which it can FTP a file, presumably a multi-megabyte
file.  (Otherwise the transfer times are sub-second on the testbed
they used.)

This presumes that this is the most significant performance-bound use
that the average large company makes of its network.

In my experience, this is not true -- FTP is a large fraction of the
bytes that go over the Internet, but not an overwhelming fraction.
"Interactive" use of various sorts seems to be very significant as
well.

This may tie in with what a friend who works for a TCP/IP vendor said
-- that IP implementations out-of-the-box aren't tuned for maximum
throughput, because they want to leave memory and CPU for the
application.  Now this makes sense if the usual usage is
"interactive", that is, some user front-end is making the requests.
But if you're just pushing files back and forth, the application is
simply waiting for the transfer to finish, so the TCP/IP code can have
the entire machine.

What sort of use do users really put networking protocols to?

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
In the Beginning, there was void... and there was me. And I looked
upon the void and saw that I was alone...  Let there be light!
-- The Bomb, in "Dark Star"

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 18:18:43 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Better LPR doc than RFC1179?

Is there an updated document for the line printer protocol since RFC1179?
There are a number of items which are unclear, such as:

  1) in receive control/data file, the name format is defined but as 'should'
     does this mean I cannot rely on the name format between implementations?

  2) assumeing I can rely on the name format (host, job), the other commands
     (state, remove) appear to only be required to specify job, but not
     host.  Is this true?  If so, how to distinguish the request when there
     are multiple of the same job number from different hosts?

  3) if you are not required to specify byte count, and a null is used to
     terminate the data (receive data file), what about files with
     imbedded nulls (graphics data?)..

If the answer to the above questions is 'read the code', where can I ftp
a copy of it from?  


-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1994 19:51:05 GMT
From:      wtierney@leland.Stanford.EDU (Bill Tierney)
To:        comp.protocols.tcp-ip
Subject:   FTP / Telnetd type questions

I have a couple of questions.  I apologize if they are already
answered somewhere.  I couldn't find them.

1)  I'm running Unix /AIX 3.2.3e  (soon 3.2.5) on RS6000 with tcp/ip.
    I want to setup a program similar to telnetd where
    someone would telnet to a specific port and I would
    run a basic ksh script.  Once the script is done - it would exit
    the session.  I have started looking at the 3.2.3 telnetd
    source code.  Is there a particular place I should be looking
    it to make my change?  Any idea what change I need to do?
    Do I have any other options?

2)  FTP - I started looking at an auto login.  What I need to do
          is to open two connections to two remote machines and
          transfer a file between them.  I loked at the .netrc
          and proxy.  It appears I need an init macro defined.
          When I do the macdef it only saves it for that session.
          How can I create a macro that will auotmatically
          run once it is started up?  Do I have to do an rexec
          command somehow?  Is there any way to perm store a 
          ftp macro?  How do you call it from .netrc?

Either post or email - I'll be checking.

Thanks to all!

Bill Tierney   

email: billt@sul1.stanford.edu

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

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 21:27:17 GMT
From:      mimosa!dox@fokus.gmd.de (Guntram Dox)
To:        comp.protocols.tcp-ip
Subject:   performance meter for IP traffic ?

this might be a faq, but I didn't read this group very often in the last time.

Is there any free available software tool to measure IP performance within the unix kernel ? 
(SunOS4.1 would be nice (:-) )

I've got netperf from HP and I know sniffer etc., but  all this is not what  I want, cause 
I wanna see pure IP performance over an ATM connection.

Any pointers ?

I appreciate your help.

Guntram Dox

dox@fokus.gmd.de
guntram.dox@informatik.tu-chemnitz.de



-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 21:37:32 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: New Group?

In article <1994Feb9.134158.27728@newsgate.sps.mot.com> maislin@hermes3.sps.mot.com (David Maislin) writes:
   What is be a good idea to start a comp.protocals.slip group?  I
   seem to see discussions on about six different group concerning
   SLIP.

I've lost the charter article (Ed?), but during the discussions (early
April 1991) leading to the creation of comp.protocols.ppp, it was
clear that the newsgroup was intended to carry discussions related to
all point-to-point networking protocols.  This would include PPP,
SLIP, ARAP, SLITHERNET, DDCMP, etc.; but not things like Kermit,
[XYZ]modem, uucp "g", Blast, etc.; nor things like ATM, Frame Relay,
X.25, Ethernet, Token Ring, etc.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 21:39:02 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Better LPR doc than RFC1179?

In article <lawsonCL8877.395@netcom.com> lawson@netcom.com (Steven Lawson) writes:
>Is there an updated document for the line printer protocol since RFC1179?

I don't think so.

>There are a number of items which are unclear, such as: [stuff deleted]

The real answer is to read the BSD Net/2 code.  The RFC, while useful,
isn't really a complete substitute for looking at the code.

>If the answer to the above questions is 'read the code', where can I ftp
>a copy of it from?  

I imagine its part of the BSD Net/2 distribution available from
ftp.uu.net and many other archive sites.

Ran
atkinson@itd.nrl.navy.mil


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 21:44:19 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <2jofl7$9gm@crl2.crl.com> rag@crl.com (Robert A. Gravley) writes:
>My boss, a very technical traditional mainframer, dropped an article on 
>my desk that stated APPC is faster than TCP/IP in file transfers, etc.  
>While I generally let things like this go unanswered ... this article 
>has created a huge debate within our organization!  The article was 
>written by Kevin Tolly of Interlab.  The article name is, "For File 
>Transers, APPC Leaves TCP/IP in the DUST".  It appears in the February 
>1994 iusse of DATA COMMUNICATIONS. 

The test appears to have been done in a NON-SCIENTIFIC manner by folks
who don't understand about how TCP/IP works and so can't devise a fair
test.  The whole test strategy appears to be bogon.  Moreover, it
confuses a particular implementation and a particular configuration on
a particular platform with a general result.

It is a good example of how the results can be predicted when the 
organisation funding the tests has a vested interest in a particular
kind of result.

Ran
atkinson@itd.nrl.navy.mil


-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 09:15:29 -0600
From:      ghelmer@alpha.dsu.edu (Guy Helmer)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

>In article <2jofl7$9gm@crl2.crl.com> rag@crl.com (Robert A. Gravley) writes:
>>My boss, a very technical traditional mainframer, dropped an article on 
>>my desk that stated APPC is faster than TCP/IP in file transfers, etc.  
>>While I generally let things like this go unanswered ... this article 
>>has created a huge debate within our organization!  The article was 
>>written by Kevin Tolly of Interlab.  The article name is, "For File 
>>Transers, APPC Leaves TCP/IP in the DUST".  It appears in the February 
>>1994 iusse of DATA COMMUNICATIONS. 
 
>The test appears to have been done in a NON-SCIENTIFIC manner by folks
>who don't understand about how TCP/IP works and so can't devise a fair
>test.  The whole test strategy appears to be bogon.  Moreover, it
>confuses a particular implementation and a particular configuration on
>a particular platform with a general result.

True, the world consists of a lot more than just OS/2-based personal
computers talking to each other, which is (incredibly) the only platform
used in the tests!  Tolly dings the TCP/IP protocol for a variety of
failures which are (most likely) the result of problems in the _single_
implementation of TCP/IP used. 

Tolly also finds fault with TCP/IP's performance when routed, but for the
router he uses Novell's MultiProtocol Router on an unknown PC with unknown
Token Ring boards; MPR on a good PC makes a good router, but I haven't
seen stellar performance out of very many PC ISA-bus Token Ring adapters
(especially not true-blue IBM boards). 

>It is a good example of how the results can be predicted when the 
>organisation funding the tests has a vested interest in a particular
>kind of result.

Tolly seems to have picked a good platform (OS/2) to "beat up" on TCP/IP:
I haven't seen great performance out of IBM's TCP/IP version 1.2 or 2.0 
(but I haven't tried OS/2 on a machine that has a good Token Ring 
adapter installed).

>atkinson@itd.nrl.navy.mil
 
-- 
Guy Helmer, Dakota State University Computing Services - ghelmer@alpha.dsu.edu

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 94 23:20:12 GMT
From:      robinson@mdd.comm.mot.com (Jim Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI programming

Rajappa Iyer (rsi@netcom.com) wrote:
>Bhyravabho Rama <brama@ncratl.AtlantaGA.NCR.COM> wrote:
 
>>2.  How does set options such as SO_LINGER, SO_KEEPALIVE, SO_BROADCAST etc?
 
>Use t_optmgmt to negotiate these options with the transport provider.

Could you possibly be more specific? I wish to set SO_REUSEADDR, and I have
figured out that t_optmgmt() is probably the correct call. However, I
cannot find where in TFM is discussed protocol specific use of this call.

If it makes a difference, the OS is SunOS 5.3.
-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Feb 1994 23:30:04 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        ba.internet,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: 2/22/94 530pm ARPAnet History: Origins of the Internet  (@SUN B6)

In article <CL8LnA.F7x@nas.nasa.gov> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
>As one of the early "children" of the ARPAnet, I recommend this talk to
>computing history buffs.  You should also have some very interesting people
>in the audience contributing as well.  Alas, I cannot make this.
>Peter will probably tape it, and Larry might describe early broadcast of
>seminars notices between MIT and Stanford.  Note followups. --enm]
>
>From: Peter.Nurkse@Eng.Sun.COM (Peter Nurkse)
>
>         * please forward this announcement within the Bay area *
>             * and post to any appropriate internal aliases *
>
>                  Bay Area Computer History Perspectives
>
>	        "ARPAnet History: Origins of the Internet"
>
>	 		     Larry Roberts
>                    5:30 PM, Tuesday, February 22
>                             Stanford Room
>                        Sun Microsystems Bldg. 6
>                            2750 Coast Ave.
>                               Mt. View
>
[ good stuff deleted here ]


	Any chance that someone at Sun could put this out via the
MBONE with real-time audio and video ??  This seems of sufficiently
general interest to be worth multicasting.

Ran
atkinson@itd.nrl.navy.mil

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 17:24:20 -0800
From:      jayarama@phakt.usc.edu (Prakash Jayaraman)
To:        comp.protocols.tcp-ip
Subject:   Help needed: How to implement a networking protocol in UNIX ?

Hi
	How do you implement IPX/SPX protocol on UNIX ?
I think Consensys Unix does not support IPX/SPX.

	WHat are the modifications that I should make in configuration 
files ? And which configuration files ?

	Where should I place the object program of the DDI/DKI driver ?

	How can I go about doing it with STREAMS ?

	Can anybody help me ?

	I could not find answers for these questions in AT&T manuals.

	Thank you very much.


	- J. Prakash

-------------------------------------------------------------------------------
Prakash Jayaraman

USC Computer Center uses a program to create login name from the First 
name and the Last name. The login name is always 8 characters long. It 
starts with the last name and continues with the first name. In my 
case, the login name is jayarama. So my email address is 
jayarama@usc.edu.
----------------------------------------------------------------------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 04:22:01 GMT
From:      gwright@world.std.com (Gary R Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <2jofl7$9gm@crl2.crl.com>, Robert A. Gravley <rag@crl.com> wrote:
>My boss, a very technical traditional mainframer, dropped an article on 
>my desk that stated APPC is faster than TCP/IP in file transfers, etc.  
 
>"And APPC blew the doors off TCP.  In fact, it ran well over 350 percent
>faster at the top end (TCP/IP topped out at 3.78 Mbit/s; APPC hit 14.11
>Mbit/s)."

Why don't you drop a copy of Gigabit Networking by Craig Partridge on
your his desk?  You could even mark page 240:

	For example, Cray's standard TCP/IP implementation has been
	measured sending data 790 Mb/s.

That is 55 times faster than "APPC"! :-)

It doesn't sound like the article compared protocols but instead
compared platforms and implementations.  I doesn't surprise me that
APPC over an IBM channel adapter would be faster than TCP/IP between
286s on Ethernet.  Of course it really doesn't tell me anything useful
either.

(Gigabit Networking, Addison-Wesley 1994 ISBN 0-201-56333-9)

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 17:49:11 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Timed out NFS hangs ls

Have a NFS problem:

I've noticed on several occastions the following problems in a multi-machine
(Intel UnixWare SVR4.2v1.0 and DEC Alpha OSF1) where file systems from
many boxes are cross mounted every which way where if one box goes down
and you ls the directory that contains the mount point or do a df or
dfspace that these local box filesystem operations HANG forever waiting
on presumably the NFS client to return the requested info.  Well WHY
doesn't the local NFS client figure out/time out and return "no-got-info"
to the local file system manager??  Instead the user's command hangs??

This is also true on the OSF1v1.3 box.  

This morning was funny/agravating; as one would construct a house of cards,
I put other machines local script bin dirs in the $PATH of several machines. 
This hangs running any exe that is found after the down machines' bins.
Another screw up was putting the following at the end of /etc/profile:
".   /another_machine/.../script"  to import project environment variables
into the local machine's login environ.  Even a if [ -r /another_mahine... ]
would hang..

Is this totally broke, or is this the wonderful world of NFS the stateless
wonder??

Thanks

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 04:36:19 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <2jofl7$9gm@crl2.crl.com>, Robert A. Gravley <rag@crl.com> wrote:
}My boss, a very technical traditional mainframer, dropped an article on...
 
}Has anyone else seen this?  Does everyone agree that as the article states: 
} 
}"And APPC blew the doors off TCP.  In fact, it ran well over 350 percent
}faster at the top end (TCP/IP topped out at 3.78 Mbit/s; APPC hit 14.11
}Mbit/s)."

Hmmm, FTP seems pretty peppy here:

   6057672 bytes received in 2.5 seconds (2.4e+03 Kbytes/s)

Sounds like a classic case of ``lies, damn lies, and statistics''...

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 05:35:17 GMT
From:      ajohnson@moose.uvm.edu (Adam A. Johnson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In article <2jo67l$p3t@solaris.cc.vt.edu> timbuck@borg.lib.vt.edu (Tim Buck) writes:


   Is it possible to connect 2 PC's with 10BaseT directly to one another
   (without a hub)?  Twisted pair cable seems to be cheaper than coax (not
   to mention easier to run along walls, etc.).  This would be to connect
   2 PC's at home.

Yes, but you'll need a crossover cable. 


   Ask for it at your nearest computer/networking supplies store or 
   catalog.  Here is what I found in an Inmac catalog (1-800-547-5444):

[price info deleted from a previous message, but from ~$6 - ~25
 depending on length, I think] 

Actually, if you have access to some wire, RJ45 connector ends, and a
crimper, the  pinouts are as follows:
( End view of connector  )
( The little o's are the )
( ends of the wires      )
( visible thru the clear )
( plastic                )

    87654321       Pin   1 TX+     to make a crossover, connect 1<->3
   -||||||||-            2 TX-                                  2<->6
   |oooooooo|            3 RX+
   |        |            6 RX-      That's all there is to it.  I used
    ~|____|~                        one last night that I had made.
       || _                          
         |\
           \this little tab is what you press on to release the
            connector from the jack

--
========================================================================
Adam A. Johnson                                     Adam.Johnson@uvm.edu   
             "Facts are negotiable, opinions aren't"

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 11:07:35
From:      todd.young@stpaul.ncr.com (Todd Young)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In article <2jo67l$p3t@solaris.cc.vt.edu> timbuck@borg.lib.vt.edu (Tim Buck) writes:
>From: timbuck@borg.lib.vt.edu (Tim Buck)
>Subject: 10BaseT connected directly?
>Date: 14 Feb 1994 15:43:49 GMT
 
>Is it possible to connect 2 PC's with 10BaseT directly to one another
>(without a hub)?  Twisted pair cable seems to be cheaper than coax (not
>to mention easier to run along walls, etc.).  This would be to connect
>2 PC's at home.
>-- 
 
>Timothy Buck              / timbuck@borg.lib.vt.edu  -  Phone (703) 231-4159
>Timbuck128@aol.com        / Recognition Research, Inc. -  Fax (703) 231-3568
>rri!tim@vtserf.cc.vt.edu  / 1872 Pratt Dr, Suite 1200, Blacksburg, VA  24060


Yup... 

Is far as I can tell this is possible by making one board 
an 'In' board and the other an 'Out' board. 

This involves crossing the send/receive pairs much like a 
null modem cable. On a RJ45 Jack (not plug) my wiring 
diagram shows pins:

Out End of cable 
---           
1 - Outgoing data 1 (+)
2 - Outgoing data 2 (-)
3 - Incoming data 1 (+)
6 - Incoming data 2 (-)

In end of cable
---

1 - Incoming data 1 (+)
2 - Incoming data 2 (-)
3 - Outgoing data 1 (+)
6 - Outgoing data 2 (-)




Todd Young           EMAIL: Todd.Young@StPaul.NCR.com
AT&T/NCR Corp.       COMPUSERVE: 72662,274
St. Paul MN.          


-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 06:22:43 GMT
From:      brian@dn.itg.telecom.com.au (Brian Miller)
To:        comp.protocols.nfs,ieee.pcnfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS server to use with PC/TCP ???

u1@syscon.ee.unsw.edu.au writes:

>In article <2ittqb$c67@belfort.daimi.aau.dk> eks@vki68.aar-vki.dk (Eigil Krogh Sorensen) writes:
>>Is there a NFS server that can be used on PCs and run together with
>>PC/TCP so PC disk(partitions) can be exported from the PC and
>>mounted on other computers ?
 
>>We use both DOS and Windows.
 
>>If so would you please inform me the name of the product and evt.
>>where I can get it.


>>Thank you in advance
 
>>Eigil Krogh Sorensen
 
>>---------------------------------------------------------------------
>>        Address:       Water Quality Institute
>>                        Science Park Aarhus
>>                        10, Gustav Wieds Vej
>>                        DK-8000 Aarhus C
>>                        DENMARK.
 
>>        Phone:          +45   86 20 20 00    or
>>                        +45   86 20 20 11  local  2114
 
>>        Fax:            +45   86 19 75 11
 
>>       E-mail:         eks@aar-vki.dk
>>----------------------------------------------------------------------
>There is a product called "idrive" which is a product of FTP software Inc. -
>the same people who produce PC/TCP.
 
>Regards,
>	- jeff
>	J.Lee@unsw.edu.au

I have come accross a product, but haven't used it yet, that will turn a PC
running DOS, into an NFS Server.  i.e. it will export all or parts of its
hard disk.  The product is called SOSS and requires a dedicated PC.

Some info from one of the README files:

NAME
     soss Son of Stan's Server

SYNOPSIS
     soss [-rtv] [-b blocksize]

DESCRIPTION
     SOSS is a file server conforming to SUN Microsystems' NFS protocol
     version 2. It will run on IBM-PC compatibles under Microsoft
     MS-DOS, using any Ethernet interface supported by Clarkson
     University's packet drivers.  Performance and reliability have been
     significantly enhanced over the original SOS released in 1989.


...and where to get it:

System                         Directory        Contact
------------                   ---------        -------
spdcc.com                       pub/sos         rbraun    (MA)
sun.soe.clarkson.edu            pub/ka9q        nelson    (NY)
grape.ecs.clarkson.edu          pub/msdos/tcpip nelson    (NY)
cs.ep.utexas.edu                pub/sos         pwesley   (TX)
garbo.uwasa.fi                  pc/comm         hv        (Finland)
kirk.bu.oz.au                   pub/pc/net/soss bambi     (Australia)
nestroy.wu-wien.ac.at           pub/src/PCtcp/soss  mah   (Austria)


Hope this is of some help to you.

Brian
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brian Miller                            Telstra  (Telecom Australia)
CDN Product Group                       30/242 Exhibition Street
ITG Data Networks                       Melbourne, VIC 3000
brian@netboss.dn.itg.telecom.com.au     Australia
Tel: +61-3-632-3883                     FAX: +61-3-632-3857
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 17:38:35 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

i just ran a routine ftp between two machines on our Fore ATM switch, and got 90Mbps 
without even trying (i didn't even bother settign MTUs optimally)

these folks who quote protocol performances ought to just ask their neighbours first

also, what does this APPC do on a WAN - any congestion control?


-- 
jon crowcroft (hmmm...)

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 08:06:47 GMT
From:      maas@wi.leidenuniv.nl  (F.H.Maas)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! Sending e-mail to an IP address.

obyrne@iol.ie (Chris O'Byrne) writes:
>
>Help!  I want to send e-mail to a machine which is on the net (ie has a
>working IP address) but which is not listed in the nameserver database.
>Is there a gateway or a syntax I can use??

You have a number of options:

(1) send mail to "user@[xxx.yyy.zzz.aaa]" (without the "" and replace x..a
    with the IP number.
    NOTE: Not all maildelivery agents accept this form of addressing

(2) send mail to a gateway for this machine (ie. a machine that knows the
    name of your respondent and that is itself in the nameserver). Send
    mail to "user%not.listed.machine@gateway.machine" (again without the "")

(3) Just add the machine to your local hosttable

Frank


-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 17:03:16 -0500
From:      barr@pop.psu.edu (David Barr)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: HELP!  Sending e-mail to an IP address.

In article <1994Feb15.212240.4292@twg.com>, David Herron <david@twg.com> wrote:
>That and your other bounce are MMDF error messages.  MMDF generally does not
>support `domain literals' ...

It doesn't?  Domain literals are required to be supported, according
to RFC 1123 "Requirements for Internet Hosts".  (Now 3.5 years old)

--Dave
-- 
"Liberty means responsibility.  That is why most men dread it."
- George Bernard Shaw

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 10:20:07 GMT
From:      catcim@eig.unige.ch
To:        comp.protocols.tcp-ip
Subject:   Header Prediction hits


Netters Hi!

On our host, a unix box, we have some statistics concerning TCP/IP. 
Concerning TCP we got the following information:

	121253 Prediction Hits (of 341256 total received packets)
		(35,53% hit rate)

Can anybody explain me this measure, what it means, and if it is normal ?


				Christian ALT
				Engineering School Geneva
				phone +41 22 344 77 50
				fax   +41 67 22 10 52


-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 10:26:08 -0000
From:      obyrne@iol.ie (Chris O'Byrne)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: HELP!  Sending e-mail to an IP address.

Thanks for all who replied. Most of the replies were of the form

"try user@[p.q.r.s]"

Unfortunately, it doesn't work. When I try it on my local machine, I get

-------- 8= --------- Cut -------- 8= --------- 8= -------- Cut ------
Trouble sending mail on ulysses.iol.ie:

============ Transcript follows ============

(BHST) Unknown host/domain name in "obyrne@"[160.6.5.1]""
Submit error: [ No such file or directory ] No valid addresses

============== Message follows =============
-------- 8= --------- Cut -------- 8= --------- 8= -------- Cut ------

When I try routing through a machine running sendmail (epona.physics.ucg.ie -
just up the road), I get :-

-------- 8= --------- Cut -------- 8= --------- 8= -------- Cut ------
    Your message could not be delivered to
'"echo%[192.67.6.2]"@epona.physics.ucg.ie (host: epona.physics.ucg.ie)
(queue: smtp)' for the following
reason:  ' <"echo%[192.67.6.2]"@epona.physics.ucg.ie>... User unknown'


    Your message follows:

Subject: Test (to echo at ip via epona)
To: echo%[192.67.6.2]@epona.physics.ucg.ie
Date: Tue, 15 Feb 1994 08:54:55 +0000 (GMT)
From: Chris O'Byrne <obyrne@iol.ie>
Organization: Ireland On-Line Ltd
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 69        
Message-ID:  <9402150854.aa02245@ulysses.iol.ie>

To echo%[192.67.6.2]@epona...
-- 
Chris O'Byrne      (obyrne@iol.ie)
-------- 8= --------- Cut -------- 8= --------- 8= -------- Cut ------

So, I don't know what's going on. It nearly looks as if the local (MMDF)
mailer is asking the remote mailer "do you have a username
obyrne%[193.120.234.34] on your system" before sending out the mail!

Cheers,
Chris.
--
Chris O'Byrne      (obyrne@iol.ie)

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 94 12:51:23 GMT
From:      mspivey@zserv2.dsac.dla.mil (Michael L. Spivey)
To:        comp.protocols.tcp-ip
Subject:   FTPing to MVS/XA mainframe

I'm wasn't sure where to post this.  I am using PC-NFS 5.0 to upload
to a mainframe so I thought this is as good as place to post as any.

My problem is as follows.  When I upload (via ftp) to our MVS/XA 
mainframe into a PDS (Partitioned Dataset) statistics for the newly
created/updated member are missing.  

Does anyone know of a way to force stats to show after the upload
is completed.

Please email any responses.

Thanks,Michael L. Spivey 
DLA Systems Automation Center


-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 13:00:04 GMT
From:      ecl6ql@gps.leeds.ac.uk (Q Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Effciency

I would use Protocol Efficiency in this case.
Network Efficiency should be some thing about how
the network as a whole is performing under all reasonable
conditions.

Qin

In article <1842136160@to.mobil.com>, davel@to.mobil.com (Dave Linthicum) writes:
> A question.  If network efficiency can be roughly 
> estimated using the following formula:
> 
> E = M/(M+O)
> 
> where:
> 
> M = Message size
> O = Overhead needed to send one message
>   = (Px delay x speed) + ACK size + H
> P = NUMBER OF PACKETS SENT
> H = HEADER SIZE 
> ACK = Acknowlegment message of meassage received
> 
> And IEEE 802.3 uses this formula such as:
> 
> E = 100/(100 + 30 + 64 + 2(64) = 31%
> 
> What is 30, 64, and 2(64)?  This is in a network modeling book, 
> I can't figure it out.
> 
>     --Dave


-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 14:15:27 GMT
From:      Ankur.Shah@launchpad.unc.edu (Ankur Harshvadan Shah)
To:        comp.protocols.tcp-ip
Subject:   Re: RFI: Firewall s/w wanted forgw

In article <CL82zv.Lx2@csn.org>, Jim Foss <jfoss@csn.org> wrote:
>
>I am looking for some software, or a firm that can take my current setup 
>with a SCO 3.2 firewall and modify it.
>
>Jim Foss
>Mind Extension University
>jfoss@meu.edu
>

Look into ftp.tis.com. They have a firewall toolkit for free. They may help you
do whatever you wishes to do.

Ankur Shah

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 94 14:24:35 GMT
From:      martyn@cs.man.ac.uk (Martyn Spink)
To:        uk.events,uk.announce,comp.protocols.tcp-ip
Subject:   TCP/IP Course

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

		TCP/IP Protocols: A Practical Introduction
			   [Code:  TCP/IP-1]

			   Dr. Andy Carpenter

			  8th & 9th March 1994
			     Cost : #320.00
                    [discount available for academics]

                                PEVE Unit
                       Department of Computer Science
                         University of Manchester 

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

For Further Details:

Please contact Ursula Hayes or Helen Sheehy via:

Phone:  061-275-6172

Email:  uhayes@cs.man.ac.uk
	hsheehy@cs.man.ac.uk

Fax:    061-275-6200

Post:   PEVE Unit
	Department of Computer Science 
        University of Manchester
	Oxford Road 
        Manchester M13 9PL

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

Aim:

This course is intended to give a comprehensive introduction to the
TCP/IP protocols that are used on many Local Area and Wide Area
networks, and to impart an understanding of the problems in
establishing, managing, and resolving problems in such networks.

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

Course Outline:

The first day starts by reviewing the Internet and the sort of
services that it has to provide.  Various terms and concepts are
introduced, in particular, the idea of protocol stacks and
addresses.  The rest of the day looks at the telnet and TCP
protocols, and RFCs.

The second day starts by examining other protocols central to the
operation of a TCP/IP network; e.g. UDP, IP and ICMP.  Various
aspects related to the operation of the protocols on particular
physical networks are then considered; for example, the need for ARP
on broadcast networks to discover the network address associated with
a particular IP address.  The course concludes with sections on
routing and advanced services.

The telnet protocol discussion covers the definition of the Network
Virtual Terminal (NVT) and the use of option negotiation to alter the
characteristics of an end-to-end connection.  Various problems of
remote terminal emulation are examined; for example, the perceived
delayed effect of control-C operations due to data buffering within a
network.  This section concludes with a paper exercise to decode a
telnet session, including option negotiation.

The section on the TCP protocol starts by examining the way in which
a reliable byte stream is obtained from a potentially unreliable
network.  Other aspects of the protocol covered are: establishing a
connection, sequence numbers, data transfers, flow control and the
format of the TCP header.  This section contains an exercise to
extract the data from a series of TCP packets and predict the
acknowledgements that are sent.

The IP protocol discussion primarily covers the format of the IP
header, the fragmentation and reassembly of packets that cross
networks, and the use of IP options.  In contrast, the section on UDP
and ICMP protocols concentrates on the uses of these protocols.  As
part of this section there are two paper exercises.  One of these is
on IP packet fragmentation; while the other requires the decoding of
the data passed in a telnet session from a dump of the packets
passing across a physical network.

Routing starts by examining the various IP address classes that are
defined, i.e. A, B and C, and their use.  It then goes on to look at
the routing gateway protocols that are available.  An example of the
operation of a dynamic gateway protocol is used to illustrate this.
The section concludes with a section on subnetting.

The advanced services section covers global naming and network
management.  The naming section covers the need for machine
registration, including the mechanisms involved, and name and domain
name servers.  The network management section introduces the
protocols used, e.g. SNMP and CMOT, and the need for object
identification.  Object identification leads onto network databases;
e.g. MIB.

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

Course Delegates:

The course is suitable for network specialists who intend to become
involved in setting up TCP/IP-based computer networks, in maintaining
and trouble-shooting these networks, or in writing protocol code.

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



--

-----------------------------------------------------------------
Martyn Spink, Room IT209, Department of Computer Science,
University of Manchester, Oxford Road, Manchester, M13 9PL, U.K.
Tel: (+44) 61-275 6157         FAX: (+44) 61-275-6200
ARPA: mspink@cs.man.ac.uk   
JANET: mspink@cs.man.ac.uk    UUCP: ..!mcsun!uknet!mucs!mspink
-----------------------------------------------------------------

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 94 15:01:00 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

In article <1994Feb13.171030.71213@ucl.ac.uk> ucacjon@ucl.ac.uk (Jon Crowcroft) writes:
>In article <g91s9798.761139845@alpha.ru.ac.za>, g91s9798@alpha.ru.ac.za (Graham Smith) writes:
>
>2 options not three:
>i. CLNP with an NSAP allocation scheme designed to fit the problem and
> existing router implementations....albeit costly in hosts
>ii. SIPP, with a simplified, better IP header and multicast and real 
> time and >mobility and smart policy routes and mobile hosts, with 
> pilot host impleemtatins, but not much i nthe way of routers yet.
>

Don't worry about us router vendors ... as soon as IP:ng is blessed,
it'll hit the streets.  My prediction is perhaps as soon as 3 months
after the approval.  Remember, we have a LOT of experience implementing
protocols.

>well, my point of view, for what its worth (0:-) is that there is no competition:
>CLNP exists, so we might as well admit it,
>but there are issues of ownershipw of change control, 
>so select SIPP as the IPng (IP Next Generation) but recommend people route both
>and go with the multiprotocol internet we've come to know and love...

No no no!  You're losing the briliance of the Internet concept here -
the issue is NOT whether CLNP or SIPP (or CATNIP, whatever THAT is) is
the better protocol.  TCP/IP didn't beat out OSI because of arcane
technical merit (altho it was better in many ways); it won because the
fundamental assumption of the Internet was that it was a "Catenet" - a
common infrastructure based on a common network protocol.  OSI lacks
this, and it turned out to be fatal.

What you propose is to create multiple user communities that are not
interoperable.  If I (SIPP) want to send you (CLNP) email, how do I
address it?  You have a different addressing format, and my DNS will not
be able to resolve it!  We'll have to live separated by a million
protocol-translating gateways, and the community will break down.
(for interesting perspective on gateways - from the LAST time the
Internet community went through this problem - see RFC 875, "Gateways,
Architectures, and Heffalumps").

Whatever solution is approved will have to meet two criteria that have
absolutely nothing to do with technical issues: everyone (EVERYONE) will
be supported (including older hosts), and the phase-in will be able to
be performed over 10 years.

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 94 20:01:17
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

OK, I've read the two articles in question, and would like to give a
bit of an apologia.  Not that I'm endorsing their conclusions, but I
think people are giving them a much worse flaming than they deserve.

   True, the world consists of a lot more than just OS/2-based personal
   computers talking to each other, which is (incredibly) the only platform
   used in the tests!

One article notes that they wanted to run a Unix-to-Unix test, but
they were unable to find an implementation of APPC for Unix.  Whether
we consider this a deficit in APPC or not is an interesting question.
And the *second* article did a larger series of tests, with maybe a
dozen MS-Windows implementations and four OS/2 implementations.

But large corporate networks are overwhelmingly dominated by PC's,
with some Mac's, a few IBM 360's, and a miniscule number of Unix
machines.  For their readers, Unix simply isn't an issue.

   Tolly dings the TCP/IP protocol for a variety of
   failures which are (most likely) the result of problems in the _single_
   implementation of TCP/IP used. 

Actually, none of the dozen implementations achieved the sorts of
performance that APPC achieved.

The issue that people should examine more carefully is the measure of
performance that they used -- total throughput in sending
multi-megabyte files by FTP.  The implication is that this is an
*important* measure of performance to the people reading the magazine.
I suspect that no TCP/IP vendor has looked into optimizing his
implementation for that use!

Remember, the sort of ubiquitous network connectivity that Unix
hackers take for granted (many low-volume connections open
simultaneously by a dozen daemons) is *not* the norm in corporate
LANs.

And it's not entirely fair to say that the competition was
out-of-the-box configurations.  In the second article, they carefully
tuned the dozen implementations.  In some cases, performance went up
by a factor of 5 or more.  But remember that if you're going to
install a networking package on 10,000 machines, you're not going to
want to tune each one individually.  And I'd be willing to bet that
the installation instructions of most networking packages does not
give simple, clear instructions for tuning the software for different
situations.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
If you want to resist the relentless tax-and-spend philosophy, it's
simple:  Call up your legislature and say "You know all those programs
which help me?  Well, I don't think you should be taxing people to pay
for them."

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 15:07:16 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: RFI: Firewall s/w wanted forgw

>Look into ftp.tis.com. They have a firewall toolkit for free. They may help you
>do whatever you wishes to do.

	The TIS firewall toolkit will run on SCO (we just ported it over)
with some changes that will be included in the next release, in a week
or so. Making it run on SCO entails a little fiddling with the Makefiles
because of the socket libraries, and some fiddling with the use of
SIGUSR1 instead of SIGOOB.

mjr.
-- 

                 ->> One-time pad available upon request <<-

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 15:20:59 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   SMTP "Apparently-To:"??

I am writing an SMTP daemon and incoming mail is getting the 'To:' field
in the message changed to 'Apparently-To:'.  What am I doing wrong?  I
have not found this in the RFCs.


-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 15:22:02 GMT
From:      bankler@sheltie.ece.cmu.edu (Brian Bankler)
To:        comp.protocols.tcp-ip
Subject:   Repost: Q: FTP guest access setup? HELP!


Yes, you all did see this same post a couple weeks ago.  Since I didn't
get _any_ response to my question, I'm going to try it one more time:

I'm trying to set up user ftp accounts along the following guidelines:
	- Accounts are available via ftp _only_
	- Users should sign on with user code and password
	- Users MUST be restricted to their directory (chroot)
	- Users may not access accounts via telnet

We are currently using the wuarchive ftpd server version 2.1c on a 
SCO unix system.  I noted an entry in the ftpaccess man pages:
	guestgroup <groupname> [<groupname> ...]
	     If a REAL user is a member of any of <groupname>, the
	     session is set up exactly as with anonymous FTP.   In
	     other  words,  a chroot() is done, and the user is no
	     longer permitted to issue the USER and PASS commands.
	     <groupname>  is  a  valid  group  from /etc/group (or
	     wherever your getgrent() call looks).

This _sounds_ like it should do what I'm looking for, but I can't seem
to get it working.  The account either behaves like a normal ftp account
without the chroot, or else I get a "can't set uid" error.  

Is anyone familiar with this command/setup?  Can someone tell me what 
I'm doing wrong or what I should be doing?  Or can anyone suggest an 
alternate method to accomplish the required setup?

Again, I'd appreciate any help.  Actually, I'd appreciate even just
getting a _response_.  Post or e-mail, I'll be keeping an eye out.
(e-mail to: liz@tox.nlm.nih.gov)

Thanks,
--Liz

---------------------------------------------------------------------------
"Women should be obscene and not heard."     | Elisabeth Kornya
                                             | Sentient Systems, Inc.
liz@tox.nlm.nih.gov                          | Kensington, MD
---------------------------------------------------------------------------
work: (301) 929-7600 x727,   FAX: (301) 929-7680,   home: (301) 208-0783
      1-800-966-9419 x727


-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 94 20:34:58
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article I write:
   In article <2jpjg3$kla@news.iastate.edu> john@iastate.edu (John Hascall) writes:
      }"And APPC blew the doors off TCP.  In fact, it ran well over 350 percent
      }faster at the top end (TCP/IP topped out at 3.78 Mbit/s; APPC hit 14.11
      }Mbit/s)."

      Hmmm, FTP seems pretty peppy here:

	 6057672 bytes received in 2.5 seconds (2.4e+03 Kbytes/s)

      Sounds like a classic case of ``lies, damn lies, and statistics''...

   Eh?  The article quoted 472 Kbytes/sec (3.78 Mbits/sec), whereas you're
   quoting 24 Kbytes/sec, which is considerably worse.  In what sense is
   that "peppy"?

2.4e+03 Kbytes/s = 2.4 Mbytes/s

Gaak.  Open mouth; insert foot.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Don't LOOK at anything in a physics lab.
Don't TASTE anything in a chemistry lab.
Don't SMELL anything in a biology lab.
Don't TOUCH anything in a medical lab.
and, most importantly,
Don't LISTEN to anything in a philosophy department.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 15:47:42 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Header Prediction hits

<catcim@eig.unige.ch> wrote:
}On our host, a unix box, we have some statistics concerning TCP/IP. 
}Concerning TCP we got the following information:
}	121253 Prediction Hits (of 341256 total received packets)
}		(35,53% hit rate)
}Can anybody explain me this measure, what it means, and if it is normal ?

   It is a (newish) TCP optimization to assume/predict that the
   next packet on a connection is just the one you are looking for.

   So, it checks that first (as opposed to checking for all the oddball
   occurrences first).

   This stat appears to be saying that the assumption is true 35%
   of the time on your system.  (my uninformed, gut feeling is
   that sounds rather low)

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 15:56:03 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

These three proposals for IPng all relate to The Internet.  
This is good, and the Internet should be the focus of attention.

But there is another key factor which may have an impact on the price
and availability of any replacements for IPv4.  This factor is that 
there is now a **very** substantial quantity of networked users, using
TCP/IP who are not connected to the Internet.  (Some of them think they
may be some day and have applied for NIC address space - but are not
actually connected, some definitely don't want to be connected, many
small organisations don't care and some haven't even thought about it,
they just have TCP/IP).

Just looking at the PC (and MAC) market for the moment...

This wall of money which is continuing to buy shrink-wrapped TCP/IP 
packages will keep current TCP/IP packages prices low and will almost 
certainly ensure that any of the three alternatives will generally 
be more expensive than the basic equivalent TCP/IP package.

The problem for companies selling an IPng shrink-wrapped version
is whether to offer any benefits to these non-Internet-connected users.

IMHO, TUBA offers no benefits, only problems and reduced performance,
due to longer packets.  Plus some hassles over DNS, and name servers,
routing tables, NSAP address allocation, 9542 addres configuration etc.

Therefore there will be no marginal market there.  Also I don't think 
the TUBA vendors would bother to try to sell their product to these 
outsiders... (unless they sell it cheaper than the TCP/IP version?)

SIPP would offer some benefits to them, so the SIPP camp could start 
selling their packages with definite advantages (over IP) and 
(if the price margin was right) gain market share quite rapidly.

Correct me if I'm wrong, but I can't see what CATNIP can offer the
non-Internet-connected user, other than bigger addresses and
better routing across a wide diameter network - neither of which
this type of user needs.

I suppose there are two messages here:

1.	TCP/IP vendors, forget the non-Internet-connected market 
	at your peril.

2.	The non-Internet-connected market will keep the current
	generation of IP packages running (and selling) for years yet.


Phil

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-986

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 16:05:17 GMT
From:      sun@cs.concordia.ca (SUN tao)
To:        comp.protocols.tcp-ip
Subject:   question about socket programming

Hi, all:

   I am a new graduate without experience and I am working on a
project of setting up the communication between UNIX and PC by
TCP-IP ( socket ). 

   With the function call "connect()", there is an error " WSAETIMEDOUT".
How can I know where to set up this TIMEOUT ?

   From the PC side, If the network connection is broken and I am still
trying to connect the host(UNIX), how can I know the network is down ?
In this case, "connect()" call will be pending there forever.

   Appreciate in advance for any help...




e-mail address:        sun@cs.concordia.ca
                or     tao_s@ceo.sts-systems.ca

 




-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 16:49:08 GMT
From:      wf@d255s295.mch.sni.de (Wolfgang Fischer)
To:        comp.protocols.tcp-ip
Subject:   IP header flags


I ran into a problem with a Sun running Solaris 2.3 mounting a NFS
filesystem without restricting rsize/wsize to 1024. Snoop shows
that the IP header has following flags set:

IP:   Flags = 0x6
IP:         .1.. .... = do not fragment
IP:         ..1. .... = more fragments

The receiving side does not like this and replys with an ICMP packet
type 12 (bad IP header). Our current understanding is, that the
receiving side chokes, because of "do not fragment" and "this UDP packet
is fragmented", which seems to be a contradiction.

So my question is, what exactly are those two flags supposed to mean?

--
Wolfgang Fischer		e-mail: Wolfgang.Fischer@mch.sni.de
		S26361-K139-V2L ist eine Ratte!

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 19:09:28 GMT
From:      greene@brtph93.bnr.ca (Paul Greene)
To:        comp.protocols.tcp-ip
Subject:   rarp

Can anyone point me in the direction of the RFC for the rarp protocol?
Just the RFC number would be great!

Thanks!

Paul Greene (greene@bnr.ca)

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 19:39:08 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        alt.security,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Both ACK and ICMP UNREACH (Re: icmp (bombs))

Darren Reed (avalon@cairo.anu.edu.au) wrote:

: RFC 1122, 3.2.2.1:
 
:             A Destination Unreachable message that is received MUST be
:             reported to the transport layer.  The transport layer SHOULD
:             use the information appropriately; for example, see Sections
:             4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
:             that has its own mechanism for notifying the sender that a
:             port is unreachable (e.g., TCP, which sends RST segments)
:             MUST nevertheless accept an ICMP Port Unreachable for the
:             same purpose.
 
: And therein lies the flaw.  What would make more sense is to examine
: the header found in the ICMP packet closely, check all port numbers
: and all the seq/ack numbers and accept if they're inside the window
: since the error 'must' be from a recent packet.  I'm not sure what
: the wisdom is of having two packets with the same meaning, however,
: such as the case of RSTs and port unreachables.

Or if the seq represents a packet which we are still holding pending a
retransmit.
i.e. should you retransmit this packet, this and all subsequent packets,
just wait and allow the packets to be retransmitted by having waited to
long for an ACK.

:             A Destination Unreachable message that is received with code
:             0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
:             routing transient and MUST therefore be interpreted as only
:             a hint, not proof, that the specified destination is
:             unreachable [IP:11].  For example, it MUST NOT be used as
:             proof of a dead gateway (see Section 3.3.1).
 
: (NOTE: this doesn't counter Port or Protocol `unreachables'.  One might
:        wonder, however, at the wisdom of accepting and acting upon a
:        "Protocol Unreachable" message after the connection has been
:        established.)
 
: But, the good-ol 4.3BSD doesn't seem to regard Host unreachables as a
: hint, and closes it in the same manner as a port unreachable.

It also dosn't take any notice of the state of the connection.

:   It seems, there is nothing which can be done in the case of port
: unreachables, they are required as part of compliance with the
: requirements for Internet hosts to be there and act with the same
: power as the TCP RST flag, although nearly all unix platforms will
: send a TCP RST rather than a port unreachable, should a problem
: arise (such as it being rebooted while the TCP connection is dormant).

Is it not the case that effectivly port unreachables are a more genric
version of TCP RST, or could be considered as such.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 19:40:40 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: rarp

In article <1994Feb15.190928.11100@brtph560.bnr.ca>, greene@brtph93.bnr.ca (Paul Greene) writes:
|> Can anyone point me in the direction of the RFC for the rarp protocol?
|> Just the RFC number would be great!
|> 
|> Thanks!
|> 
|> Paul Greene (greene@bnr.ca)

RFC 903.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 19:57:46 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.security.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: NFS authentication non-existent ??

Darren Reed (avalon@cairo.anu.edu.au) wrote:

: Still, who needs to be root when /usr/spool/mail is mounted from the mail
: server, is writeable and you can create any file with any perms you like ?
: setgid is usually required too so that all mail files are group mail.

Alternativly set the 'sticky bit' on the directory and arrange for 'empty'
files to be truncated to zero length.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 20:00:56 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on X.25 efficiency

Martin Tirion (cv1540@capvolmac.nl) wrote:
: Hi,
 
: I am looking for people with experience in using TCP/IP on top of X.25. We are
: thinking of implementing this but we would like to exchange some thoughts with
: people who have actually seen this work and have done measurements on
: performance. We have tried to do a benchmark and it seemed as if a FTP of a 
: small file (around 4 kbytes) took TWICE ! as many packets as when bare X.25 was 
: used. This got less worse when the files grew larger but the number of packets 
: was still considerably larger in comparison to bare X.25. Since we are paying 
: per (fixed size) packet this is not a nice thing to have.

Try lookig at the JIP's documentation.
Available on src.doc.ic.ac.uk.
There are also some e-mail addresses in here.

: With this experience in mind we would like to do some more tests, but we would 
: like to hear some results from others as well. Is this phenomenon in line with 
: what others see or have we done something wrong completely wrong here ? What 
: about TCP/IP header-compression, is that possible and does it help ?

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 20:07:30 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Nuking CLOSING entries in netstat on SS2 4.1.3?

Russell Mosemann (mose@ns.ccsn.edu) wrote:
:    How does one get entries to go away which show up in netstat -f inet
: as CLOSING on a SS2 running SunOS 4.1.3?  They seem to mostly involve
: PC's which telnet in and for some reason the connection never closes
: down properly.  The Sun then waits forever.  It could be the TCP/IP
: implementation on the PC, someone may just power down the PC at the
: wrong time, or there might be some other strange reason.\

It sounds to me as though something IS broken somewhere. I would expect there
to be some timeout of closing sockets, something like a few hours.

:   In any case, how can I get the silly things to timeout and go away?
: Rebooting, of course, cures a multitude of problems, but I'm looking for
: another solution.  Thanks.
 

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 20:13:14 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP "Apparently-To:"??

Steven Lawson (lawson@netcom.com) wrote:
: I am writing an SMTP daemon and incoming mail is getting the 'To:' field
: in the message changed to 'Apparently-To:'.  What am I doing wrong?  I
: have not found this in the RFCs.

Possibly the mailer is using the DNS to verify hostnames and it is
detecting is discrepency.

e.g. you are sending to an alias.



-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 10:32:11 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <DRW.94Feb15200117@jordan.mit.edu> drw@jordan.mit.edu (Dale R. Worley) writes:
>OK, I've read the two articles in question, and would like to give a
>bit of an apologia.  Not that I'm endorsing their conclusions, but I
>think people are giving them a much worse flaming than they deserve.

  Maybe, maybe not. 

>
>One article notes that they wanted to run a Unix-to-Unix test, but
>they were unable to find an implementation of APPC for Unix.  Whether
>we consider this a deficit in APPC or not is an interesting question.

   I'd certainly consider it a "deficit" in the knowledge of someone
   like Tolly who claims to be such a guru, not to know where to
   get Unix LU 6.2.  Strange that he's never heard of Brixton, SSI, or
   XCOM 6.2.

>But large corporate networks are overwhelmingly dominated by PC's,
>with some Mac's, a few IBM 360's, and a miniscule number of Unix
>machines.  For their readers, Unix simply isn't an issue.

   But it pretty much moots any real worth in the test.  All it means
   is that a specific implementation of tcp/ip sucks compared to a
   specific implementation of appc.  Given that the environment of the
   test was from a vendor with lotsa experience in appc and not that
   much in tcp/ip, what would you expect?  

>Actually, none of the dozen implementations achieved the sorts of
>performance that APPC achieved.

   Honestly not surprising, the protocol stack is a bit leaner and
   does a few different things at different layers.  Not only that,
   but if they had really cheated and run the full IBM DLC layer
   on a TI TMS380C16, and run Data Flow Control and Path Control on a
   coprocessor, it would have been even faster. 
>
>The issue that people should examine more carefully is the measure of
>performance that they used -- total throughput in sending
>multi-megabyte files by FTP.  The implication is that this is an
>*important* measure of performance to the people reading the magazine.
>I suspect that no TCP/IP vendor has looked into optimizing his
>implementation for that use!

  Not a good suspicion by any means.  

>
>Remember, the sort of ubiquitous network connectivity that Unix
>hackers take for granted (many low-volume connections open
>simultaneously by a dozen daemons) is *not* the norm in corporate
>LANs.
>
   Its a lot more "norm" than you would think. 



-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 21:22:35 GMT
From:      "David Herron" <david@twg.com>
To:        comp.mail.misc,comp.protocols.tcp-ip Chris O'Byrne <obyrne@iol.ie>
Subject:   Re: HELP!  Sending e-mail to an IP address.

>Thanks for all who replied. Most of the replies were of the form
>
>"try user@[p.q.r.s]"
>
>Unfortunately, it doesn't work. When I try it on my local machine, I get
>
>-------- 8= --------- Cut -------- 8= --------- 8= -------- Cut ------
>Trouble sending mail on ulysses.iol.ie:
>
>============ Transcript follows ============
>
>(BHST) Unknown host/domain name in "obyrne@"[160.6.5.1]""
>Submit error: [ No such file or directory ] No valid addresses
>
>============== Message follows =============
>-------- 8= --------- Cut -------- 8= --------- 8= -------- Cut ------

That and your other bounce are MMDF error messages.  MMDF generally does not
support `domain literals' ...

	David

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 21:38:44 GMT
From:      ced@bcstec.ca.boeing.com (Charles Derykus)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP!  Sending e-mail to an IP address.

In article <2jnobs$f18@ulysses.iol.ie>, Chris O'Byrne <obyrne@iol.ie> wrote:
>Help!  I want to send e-mail to a machine which is on the net (ie has a
>working IP address) but which is not listed in the nameserver database.
>Is there a gateway or a syntax I can use??
>
>Thanks,
>Chris
>--
>Chris O'Byrne          (obyrne@iol.ie)

I've had luck with the format: somebody@'[his_ip]'

The quotes were necessary too for some arcane reason that
escapes me  (no pun intended).


-- 
Charles DeRykus				Internet:   ced@carios2.ca.boeing.com
Boeing Computer Services		UUCP:	    ...!uunet!bcstec!ced

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 22:02:39 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: Concerned about tcp checksum notice, please help

In article <2j8erg$2e5@pandora.sdsu.edu> papowell@dickory.sdsu.edu (Patrick Powell) writes:
>Steve Prowten (sprowt@world.std.com) wrote:
>
>: Howdy, all -- We occasionally see the checksum message:
 
>:     NOTICE: tcp sum: src 80A9D08C, sum 00000010
 
>: on the console of our SCO Unix 3.2.4.2 Intel box.  The hex value
>: is never the same twice.  We've got an SMC network card, using the
>: SCO wdn drivers.  Can anybody tell me what this might be and whether
>: it should cause concern?
 
>: Many thanks,
 
>: S. Prowten   sprowt@world.std.com
>: -- 
>: Steven Prowten   sprowt@world.std.com
>
>
>1.  You have got a runt packet in,  which just HAPPENS to look OK to the
>Ethernet interface.  Rare,  but it happens.  I have seen it twice in
>a week here.
>
>2.  You have a flakey interface card, with a bad memory chip.  Replace
>the card IMMEDIATELY.   You may get some VERY strange errors if you
>do not do this NOW!  You have been warned!
>
I can add a third one. You have a SPARC in the next office running
PPP and you dial into it from your PC at home running Chameleon
and use it as a gateway to run telnet on your SCO box...

..which is exactly what I am doing right now.

I will have a fistful of errors tomorrow. Never happens on Ethernet.

Only when the SPARC is gatewaying to PPP.

Who knows?


-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Feb 1994 23:14:25 GMT
From:      edwin@cs.ruu.nl (Edwin Kremer)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   [Q] drawing LAN presentation sheets. What do you use?

  Frequently, I have to draw images that represent (part of) our LAN and
WAN connections; to include in some paper being written or to print on a
sheet  for a presentation. Till now, I've been struggling with a generic
drawing package and some poorly scanned TIFF images  on  a  NeXTstation.
This is no longer considered sufficient, let alone "state of the art"...

  What  I'd like to have is an easy-to-use drawing package that includes
(or can import) a wide range of LAN-related images,  like  workstations,
servers, routers, LAN's, WAN's, PC's, repeater, bridges, etc. Eventually
wiring, cabling, ... The package should  be  able  to  generate  (color)
PostScript  and preferably runs on a UNIX workstation (SGI, HPs700, Sun-
SPARC).

  If you know of  any software that can assist me in doing this, be it a
complete package or just a clip-art library that can be easily  imported
in  another  publishing  package,  please  let  me know. If you reply by
email, I will post a summary of responses some other time. If you choose
to follow-up, I'll probably summarize anyway ;-)

Thanks for your time.

						--[ Edwin ]--
--
Edwin H. Kremer, systems- and network manager.    [NIC-Whois handle: EHK3]
  Department of Computer Science,    Utrecht University,   The Netherlands
  Internet: Edwin.Kremer@cs.ruu.nl   NeXTmail: Edwin.Kremer@edge.cs.ruu.nl
  X.400   : G=Edwin;S=Kremer;OU=cs;O=ruu;PRMD=surf;ADMD=400net;C=nl

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 13:28:23 -0800
From:      xorcist@crl.com (Peter Stone)
To:        comp.protocols.tcp-ip
Subject:   [INFO NEEDED] v.35 -> router -> TCP/IP for mac/pc/etc

Greetings.

I am faced with a situation which demands the change of my current system.

I would like to know if there is a router out there that takes a 56K
v.35 connection, and had an Ethernet port on the back for hooking up
a Mac or PC or whatever to it so they can all operate TCP/IP.

Basically, I need to break my Internet Provider line (56K) so that
I can hook up a few Mac's and a PC to it to run different servers.

I don't want to go a PC running KA9Q as it's too unreliable.

If anyone knows of a cheap router that will allow this, please email me...
or post it here too so others can know.

Peter

-- 
xorcist@cyberden.sf.ca.us
415.472.5527 - The CyberDen - Worldwide Alternative Music Network


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 08:29:44 -0500
From:      mdtanx@cs.umd.edu (Michael D. Tan)
To:        csd.grad,comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.unix.internals
Subject:   TCP/IP and Ethernet Performance Papers



Has anyone seen a paper or book which does a performance study of
TCP/IP over Ethernet (10Mb/s (not research Ethernet)) using multiple
hosts?  I've seen the Boggs, Mogul, and Kent [1988] paper, which does
performance studies for Ethernet *only*.

Please send replies via email to

Michael Tan
mdtanx@cs.umd.edu


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 00:10:53 GMT
From:      ching@angelo.amd.com (Mike Ching)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In article <2jo67l$p3t@solaris.cc.vt.edu> timbuck@borg.lib.vt.edu (Tim Buck) writes:
>Is it possible to connect 2 PC's with 10BaseT directly to one another
>(without a hub)?  Twisted pair cable seems to be cheaper than coax (not
>to mention easier to run along walls, etc.).  This would be to connect
>2 PC's at home.
>-- 
>

It'll work under some conditions. If the protocol is half-duplex like
ftp transfers, it works fine. If there are a lot of collisions because
both nodes are trying to transmit, it fails miserably. This is because
there is no hub to manage the collisions and both nodes will transmit
not knowing the other node is not able to receive. An application like
the game Doom that sends broadcast packets won't work.

Mike Ching

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 08:46:42 -0500
From:      mdtanx@cs.umd.edu (Michael D. Tan)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   TCP weirdness: 10MB msg beats 100KB msgs



I have three Sparc2's which each attempt to send 10MB to a fourth
machine (a Sparc10).  They are connected by 10Mb/s Ethernet.  The
transfers are done using TCP/IP.  If each of the senders does a 
	write (sockfd, ptr, 10000000)

all 10MB get written and the total transfer time (30MB) takes about 33
seconds.  However, when each of the senders tries to send their 10MB
in messages of 100KB, the code looks something like this:

	for (i = 0; i < (10000000/100000); i++)
		write(sockfd,ptr, 100000);

This transfer (30MB (again)) consistently takes about 40 seconds.  I
have runs these tests many times, with the same results.

Does anyone know why this is happening?

TCP_NODELAY *is* set...

Michael Tan
mdtanx@cs.umd.edu


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 01:32:56 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

Dale R. Worley <drw@jordan.mit.edu> wrote:
}john@iastate.edu (John Hascall) writes:
}   }"And APPC blew the doors off TCP.  In fact, it ran well over 350 percent
}   }faster at the top end (TCP/IP topped out at 3.78 Mbit/s; APPC hit 14.11
}   }Mbit/s)."
}   Hmmm, FTP seems pretty peppy here:
}      6057672 bytes received in 2.5 seconds (2.4e+03 Kbytes/s)
 
}Eh?  The article quoted 472 Kbytes/sec (3.78 Mbits/sec), whereas you're
}quoting 24 Kbytes/sec, which is considerably worse.  In what sense is
}that "peppy"?
}Dale Worley		Dept. of Math., MIT		drw@math.mit.edu

    What a sad comment on the ``Dept. of Math., MIT''...

               3
       2.4 x 10  = 2400

    Yes, that's 2400Kb/s = 19.2Mbits/sec.


John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1994 13:05:47 +0800
From:      peter@ncrpda.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

minich@a.cs.okstate.edu (Robert J Minich) writes:

>by billy@utdallas.edu (Billy Barron):
>> Talk about a UNIX centric view of the world.  To make this
>> proposal work, you need to specify how Novell, VMS, VM, etc
>> translate their permissions into [UNIX] format. [...]
 
>I think Billy is missing the point. The proposal is trying to specify a
>machine interpretable format for LIST output. If you agree that UNIX is
>the most common OS to find on the server end of an FTP session, then
>standardizing around that format for LIST output can be a reasonable
>proposition since most existing server software will remain almost exactly
>the same! Of course, that's not to say I _like_ format.

Agreed on all points.  If you want to move on to designing a new FTP
list command, that's fine we can do that, but it still leaves the proposal
I originally made as something to think about, since we have to write clients
in the mean time.  So far I haven't really got any "constructive" comments
on how to improve the proposal, most comments explain the bad points of 
the proposal without offering any solutions that will be workable in the near
future (anything that requires modifications to existing servers is
not going to be useful for years).

Now, on to a proposal for a new structured FTP list command.

>I assert that what most FTP client software would like to know is:
 
>	1. What's the object's name?
>	2. Can I CWD into it?
>	3. Do I have permission to retrieve it?
>	4. How many bytes would you send if I retrieved it?

The date is also quite relevent, as well as comonly available.  I'd also
suggest that the size be assumed to be approximate, since it is nearly
impossible or very expensive to accurately calculate the size of a large
file.  The size is needed so a modem user can see whether the file she
wants to download is 10k or 10Meg.  Knowing whether a file is text or
binary would also be nice, since it is generally the server that knows this,
not the client.

>	XMRL <PATH=.> <ATTRIBUTES=NAME,TYPE,SIZE,CAN_READ>

A bit of consistency with the rest of the FTP spec would be a good idea.

How about two commands:

XMRA NAME,TYPE,SIZE,CAN_READ
XMRL path

That would also let you know if the XMRL extensions are available before you
try to list the directory (opening ports and such), as well as letting you
easily back off to the LIST command if the XMRA command is not implemented
or doesn't support the required attributes.

>	<.,directory,512,true>

Size for directories should be omitted, they don't make any sense even
under unix, and they make even less for most other platforms.  Just leave
the field blank for directories.

Also, this stuff has to go over a network, ans it's suppose to be machine
readable, so we might as well use some compression on the fields.  Use
d&f or d&- for directory and file, and 1&0 for true&false.  Should the .
and .. even appear?  Should they be supported in the path?  These are
unix only things, although I did support them on my Mac server.

>	<..,directory,512,true>
>	<README,file,2374,true>
>	<name with spaces,file,31,true>
>	<name with \> bracket,file,0,true>
>	<name with\, uh\, commas,file,0,true>
>	<name with back slash\\,file,0,true>

Perhaps use MIME = encoding instead of backslashing.  That way any strange
characters can me encoded (including linefeeds and such).  (MIME uses =
followed by two hex characters to encode strange characters, including = ).

>an example for UNIX-specific info:
 
>	XMRL <PATH=/> <ATTRIBUTES=NAME,<UNIX=MODE>>

Why not just UNIX-MODE as an attribute name?  If the server doesn't support
it, then either it gives an error, or it leaves it blank (we need to
define which of course).  Also, I don't like the way you've done the
nested < >, it's going to make things much more confusing, why not just

XMRA NAME,TYPE,MAC-TYPE,MAC-CREATOR
XMRL
gives:
Readme,f,TEXT,MACA
Some file.sit,f,SIT!,SIT!
Subdirectory,d,,

>And last, an example for errors:
 
>	XMRL <PATH=.> <ATTRIBUTE=NAME,<UNIX=MODE>>
>	### Unknown attribute: <UNIX=MODE>

Perhaps:

XMRA NAME,UNIX-MODE
500 UNIX-MODE Unknown attribute

(so the attribute can be parsed from the error response).

>conversions. Also, for each OS, there should be a standard set of
>attributes for interoperability.

Where possible, there should be a standard attribute and the OS should convert.
For example, permissions for a file are generally read/write and for 
directories canchange/canlist/canmodify. Unix's rwx are sufficient for
these, so perhaps a MODE attribute might return these three flags
for most all OSs, and then UNIX-MODE might include all 9. OWNER & GROUP
might be standard attributes.

>I propose that a minimal XMRL implementation would support the following
>attributes:
 
>	NAME      The name of the file with '\' '>' and ',' escaped.
 lose the >
>	SIZE      The number of bytes (approximately) that this file would
>	          would occupy if retrieved in the current mode.
 approximately being important.
>	TYPE      One of "file" or "directory", where the latter may be
>		  used only for objects that are valid arguments to CWD.
some sort of "other" for things that can neither be retrieved nor 
changed into?  Or should they simply not be listed (this is after
all (as you pointed out) a file transfer protocol, not a file system.
>	CAN_READ  Either "true" or "false".
MODDATE - ISO format for date (what the hell is an ISO date anyway?)

>Server specific attributes would be designated as a tuple of
><os_name=attribute_list> in a recursive manner. Note that an
>implementation could support more than one OS.

Why bother with that?  Simple use "-" as a valid attribute name character,
and then UNIX-, MAC-, MSDOS-, etc.

>This is by no means a formal (or even well thought) out proposal, but I'd
>love to hear others' thoughts on the above.

Well, it would be nice if there was something like this, but as I said before,
it doesn't get around the need for a way of parsing the LIST format
that is currently sent by the thousands of servers out there.
   Peter.
-- 
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 02:44:26 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?


In article <CLAJ66.2oC@amd.com>, ching@angelo.amd.com (Mike Ching) writes:
|In article <2jo67l$p3t@solaris.cc.vt.edu> timbuck@borg.lib.vt.edu (Tim Buck) writes:
|>Is it possible to connect 2 PC's with 10BaseT directly to one another
|>(without a hub)?  Twisted pair cable seems to be cheaper than coax (not
|>to mention easier to run along walls, etc.).  This would be to connect
|>2 PC's at home.
|>-- 
|>
|
|It'll work under some conditions. If the protocol is half-duplex like
|ftp transfers, it works fine. If there are a lot of collisions because
|both nodes are trying to transmit, it fails miserably. 

No no no no no.

Connecting two 10baseT DTE's via a crossover UTP cable is perfectly
legal and works fine in all circumstances (assuming the hardware is
OK.)  (This question is, by the way, probably the #1
comp.dcom.lans.ethernet FAQ.)

|This is because
|there is no hub to manage the collisions and both nodes will transmit
|not knowing the other node is not able to receive. An application like
|the game Doom that sends broadcast packets won't work.

Hubs don't manage collisions.  Think of a ThinWire Ethernet: who 
manages the collisions there?  In Ethernet, there is no intelligence
in the network; it's all in the DTEs.  (Unlike 100baseVG-AnyLAN
or whatever it's called.)

Followups to comp.dcom.lans.ethernet.

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 02:44:34 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25

I was wondering if anybody could provide me information about the performance
of TCP/IP over X.25.  How can one make sure one is getting the maximum through
put or better response times?  Is there a white paper that discusses the
performance of TCP/IP over various WAN protocols such as X.25, Frame relay,
FDDI, ATM, etc?  Thanks in advance.  My email address brama@ncratl.AtlantaGA.NCR.COM.
-- 

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 02:50:18 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Replacing IP as the bottom layer of the internet

In article <761327763snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk writes:
    But there is another key factor which may have an impact on the price
    and availability of any replacements for IPv4.  This factor is that 
    there is now a **very** substantial quantity of networked users, using
    TCP/IP who are not connected to the Internet.  (Some of them think they
    may be some day and have applied for NIC address space - but are not
    actually connected, some definitely don't want to be connected, many
    small organisations don't care and some haven't even thought about it,
    they just have TCP/IP).
    
    Just looking at the PC (and MAC) market for the moment...
    
    This wall of money which is continuing to buy shrink-wrapped TCP/IP 
    packages will keep current TCP/IP packages prices low and will almost 
    certainly ensure that any of the three alternatives will generally 
    be more expensive than the basic equivalent TCP/IP package.
    
    The problem for companies selling an IPng shrink-wrapped version
    is whether to offer any benefits to these non-Internet-connected users.
    
Why is this a problem?  The vendors implement IPng as part of their package
and away you go....

    IMHO, TUBA offers no benefits, only problems and reduced performance,
    due to longer packets.  Plus some hassles over DNS, and name servers,
    routing tables, NSAP address allocation, 9542 addres configuration etc.
    
The same can be said of SIPP.

    Therefore there will be no marginal market there.  Also I don't think 
    the TUBA vendors would bother to try to sell their product to these 
    outsiders... (unless they sell it cheaper than the TCP/IP version?)
    
Why not?  I suspect that you are thinking about IPng as re-engineering the
entire stack.  It need not be.  The incremental cost of implementing IPng
is probably not going to be all that high.  Consider this: for a host
vendor to implement TUBA, they have to add some code to generate CLNP
headers.  They need to generalize their code to use IPv4 or CLNP headers
depending on what the application requests, and then they need to modify
their DNS resolver.  This is not "throw it all out, start over".

    SIPP would offer some benefits to them, so the SIPP camp could start 
    selling their packages with definite advantages (over IP) and 
    (if the price margin was right) gain market share quite rapidly.

Well, what benefits does SIPP have over TUBA that would convince you to buy
it over IPv4?  Where's the carrot?  The only carrots that _I_ can see are
ones that apply to both proposals: bigger address spaces, easier mobility,
security....  There's no "consumer level differentiator".
    
    Correct me if I'm wrong, but I can't see what CATNIP can offer the
    non-Internet-connected user, other than bigger addresses and
    better routing across a wide diameter network - neither of which
    this type of user needs.
    
CATNIP allows you to merge the "global" IPX address space into the IPng
address space.  Speaking about that wall of money....

Tony

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 02:51:40 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   Broadcast File Transfer

Are there any broadcast file transfer packages or a broadcast file transfer
protocol?  What I want to be able to do is send a file to set of machines
instead of having to specify a rcp for each machine or remsh for each machine
to execute a given command.
-- 

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 04:04:25 GMT
From:      mjr@tis.com (Marcus J. Ranum -- Crash Test Dummy for the Information Superhighway)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

>Are there any broadcast file transfer packages or a broadcast file transfer
>protocol?

	NNTP

mjr.
-- 
One-time pad available upon request

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 06:15:34 GMT
From:      piggy@hilbert.maths.utas.edu.au (La Monte Yarroll)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: HELP! Sending e-mail to an IP address.

obyrne@iol.ie (Chris O'Byrne) writes:

>Thanks for all who replied. Most of the replies were of the form
 
>"try user@[p.q.r.s]"
 
>Unfortunately, it doesn't work. When I try it on my local machine, I get

Are you sure that the IP address is not properly entered in the DNS?
Here are reverse lookups for every IP address mentioned in your article:

160.6.5.1	dunksink.dunksink.dias.ie
192.67.6.2	psi.com
193.120.234.34	ulysses.iol.ie (OK, your probably know your own IP
		address :-)

If your local mailer does not handle the user@[p.q.r.s] syntax, you
can always fall back to speaking SMTP by hand.

$ telnet p.q.r.s 25
HELO ulysses.io.ie		# Introduce yourself.
MAIL FROM: obyrne@iol.ie	# Errors go back to this address.
RCPT TO: user			# Deliver to this (local) address.
DATA				# You need to build your own headers.
From: "Chris O'Byrne" <obyrne@iol.ie>
To: "Whomever" <user@[p.q.r.s]>
Subject: Hand constructed message

Body of message goes here.  In this example, Date and Message-ID
headers should be inserted by the  destination machine
.				# End with a . by itself.
QUIT				# Hang up.
--
La Monte H. Yarroll	Home:		piggy@baqaqi.chi.il.us
   Work:		piggy@hilbert.maths.utas.edu.au
   If you remember nothing else:  piggy@acm.org		NIC Handle: LY
   GPL - "Just give source a chance."

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 18:10:40 -0600
From:      miltonm@bga.com (Milton D. Miller II)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

I know there is a RFC for at least one protocol.  The author
was using it to distribute boot images to workstations as
a replacement for TFTP.

milton
--
Milton Miller  KB5TKF  miltonm@bga.com

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 08:34:58 GMT
From:      maas@wi.leidenuniv.nl  (F.H.Maas)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP "Apparently-To:"??

lawson@netcom.com (Steven Lawson) writes:
>
>I am writing an SMTP daemon and incoming mail is getting the 'To:' field
>in the message changed to 'Apparently-To:'.  What am I doing wrong?  I
>have not found this in the RFCs.
>

As far as I know this happens when you specify an envelope address (RCPT TO:)
but leave out a header-To: address (in the DATA - . block).

Frank

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 09:10:10 GMT
From:      system@asuvax.eas.asu.edu (Marc Lesure)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Looking for multi-session telnet source

I'm looking for source (Unix BSD) to a telnet program that allows
multiple sessions.  I can't use job control and need to have more
than one connection than the current version allows.  Does a
multi-session telnet exist?

-----------------------------------------------------------------------
Marc Lesure / Arizona State University / Tempe, AZ
"Between the world of men and make-believe, I can be found..."
"False faces and meaningless chases, I travel alone..."
"And where do you go when you come to the end of your dream?"

UUCP:       ...!ncar!noao!asuvax!lesure  
Internet:   lesure@asuvax.eas.asu.edu

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 15:30:27
From:      mscarton@mudshark.sunquest.com (Mark A. Scarton)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP connection break

There was some discussion back at the end of January about how connection
breaks in the form of network failures are not reflected back to the 
application if keepalives are enabled.  We seem to have a problem that could 
be a ramification of this.  We have PC clients communicating with AIX servers,
normally Sybase with ODBC and NetLIB as intermediary layers.  If a PC
hangs, the Sybase server task doesn't seem to recognize that the connection
has been abnormally terminated.

Could someone please explain when connection failure is reflected to client and
server tasks (and when it is not)?  If this is well documented somewhere, a 
reference would be appreciated.  I did try to do my homework, but didn't find 
anything appropriate in my books (mainly Stevens and Comer's books).

In particular, if there is a technique that can be used to force notification 
of the failure of the connection to the applications communicating, I'd very 
my like to use it.  PC's and Windows is not the most robust client platform in 
the world; I'm expecting applications to often fail to terminate gracefully. 

Thanks!

========================================================================
Mark A. Scarton, ABD                 | Sunquest Information Systems
801/278-7597, fax 278-0192           | 4525 S. Wasatch Blvd Suite 335
mscarton@mudshark.sunquest.com       | Salt Lake City, Utah  84124
========================================================================
"Ski Utah...The greatest snow on Earth!"

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 20:05:11 -0500
From:      syklb@osiris.giss.nasa.gov (Ken Bell)
To:        comp.protocols.tcp-ip
Subject:   Certain /etc/motd contents cause hang on rlogin -- sound familiar?

This is an update to the problem reported earlier this month.

The problem is observable when one does the following:

	(a) login to "Host-A", an RS/6000 running AIX 3.2.2,
	(b) rlogin to "Host-B", a Sun running SunOS 4.1.1,
	(c) rlogin back to Host-A.

		             (b)
		(a) ----> A ----> B
		          |       |
		          + <---- +
		             (c)

Apparently, dependent on the contents of /etc/motd, this scenario works
or hangs.  In particular, the following contents will cause a hang:


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

where the asterisks are left-aligned (the first character on each
line is an asterisk).  The character need not be an asterisk, a
period, alternating "minus" and "equals", and others, yield the
same result.

If, on the other hand, the spaces in the above box are replaced
with, for example, the character 'a', e.g.,

	*****************************************************
	*aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa*
	*aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa*
	*****************************************************

then there is no problem.

Does anyone happen to recall such a problem?  I vaguely remember
reading about a rather old gateway that ascribed significance to
specific patterns of data, with similar results, but the reference
escapes me.  What I do know about the two endpoints is that they
are connected via a pair of Cisco IGS-R routers (running software
release 8.2(2)), through a 56Kbps serial line.  The two hosts are
6 hops away from one another.

If the routing from Host-A to Host-B is changed, such that outbound
packets travel a much greater distance, and 16 hops, then the problem
disappears.  (In the first case, the routing is within local New York
State, and in the second case it is from New York to Maryland and back
to New York.)

How would one trace such a problem to its source (assuming of course
that there is "a source" and not just a serendipitous timing anomaly
along the first route)?

By the way, I understand that the scenario described is not typical
of a useful application, but it is the most reliable way to demonstrate
a similar, intermittent, problem that was brought to my attention.

If this is not the best group to post this problem to, I would much
appreciate pointers to a more appropriate newsgroup.

-- 
Ken Bell
syklb@nasagiss.giss.nasa.gov / syklb@nasagiss.bitnet / (212)-678-5545

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 21:06:35 -0500
From:      kevin@serve.tech.mis.cfc.com (Kevin Darcy)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

(NOTE: This article mostly addresses what I consider misperceptions of what
happens on a "large corporate network". There isn't terribly much technical
content).

In article <DRW.94Feb15200117@jordan.mit.edu>,
Dale R. Worley <drw@jordan.mit.edu> wrote:
>OK, I've read the two articles in question, and would like to give a
>bit of an apologia.  Not that I'm endorsing their conclusions, but I
>think people are giving them a much worse flaming than they deserve.
>
>   True, the world consists of a lot more than just OS/2-based personal
>   computers talking to each other, which is (incredibly) the only platform
>   used in the tests!
>
>One article notes that they wanted to run a Unix-to-Unix test, but
>they were unable to find an implementation of APPC for Unix.  

In my experience, most APPC for Unix sucks rocks anyway. Mainframebrains 
don't seem to grok Unix much more than us Unix Eunuchs grok mainframes. Good 
implementations of APPC for Unix are thus quite rare.

>Whether
>we consider this a deficit in APPC or not is an interesting question.
>And the *second* article did a larger series of tests, with maybe a
>dozen MS-Windows implementations and four OS/2 implementations.

MS-What? OS/What?

>But large corporate networks are overwhelmingly dominated by PC's,
>with some Mac's, a few IBM 360's, and a miniscule number of Unix
>machines.  For their readers, Unix simply isn't an issue.

Please be wary of glib generalizations. *OUR* "large corporate network"
(Chrysler Financial's) is dominated by Unix machines, with a few mainframes,
and only a few dozen or so MS-DOS/Windows PC's hanging out in the Home Office.

>   Tolly dings the TCP/IP protocol for a variety of
>   failures which are (most likely) the result of problems in the _single_
>   implementation of TCP/IP used. 
>
>Actually, none of the dozen implementations achieved the sorts of
>performance that APPC achieved.
>
>The issue that people should examine more carefully is the measure of
>performance that they used -- total throughput in sending
>multi-megabyte files by FTP.  The implication is that this is an
>*important* measure of performance to the people reading the magazine.
>I suspect that no TCP/IP vendor has looked into optimizing his
>implementation for that use!
>
>Remember, the sort of ubiquitous network connectivity that Unix
>hackers take for granted (many low-volume connections open
>simultaneously by a dozen daemons) is *not* the norm in corporate
>LANs.

It is in our LAN/WAN.

>And it's not entirely fair to say that the competition was
>out-of-the-box configurations.  In the second article, they carefully
>tuned the dozen implementations.  In some cases, performance went up
>by a factor of 5 or more.  But remember that if you're going to
>install a networking package on 10,000 machines, you're not going to
>want to tune each one individually.  

Correct. You tune *ONE*, and then replicate that image to all the others 
using whatever serves as your Software Distribution System. On a large
corporate network, the Software Distribution System is a *MUST*, not just
for OS stuff, but all of those applications (canned and custom) that the 
users are going to run too...

>And I'd be willing to bet that
>the installation instructions of most networking packages does not
>give simple, clear instructions for tuning the software for different
>situations.

Correct. Your Technical Support staff, not the end-user, develops the tuning 
parameters necessary to achieve optimum performance.

--------------------------------------------------------------------------------
kevin@cfc.com <-- (ASCII only please)  | Kevin Darcy, UNIX Systems Admin (CFC)
kevin@tech.mis.cfc.com <-- (mute       | Technical Services
Voice: (810) 759-7140 	    NeXTmail   | Chrysler Corporation
Fax:   (810) 758-8173       welcome)   | Center Line, Michigan, MIS Complex
--------------------------------------------------------------------------------

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 12:52:07 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP port sharing

> In one of R. Stevens earlier books he talks about a parameter to
> setsockopt (SO_REUSEPORT) which would allow multiple processes to each
> receive a copy of a broadcast or multicast message. It doesn't appear to
> be in my implementation (QNX4.2) or even on the bsd mirror at iastate.edu.
> Is there now a different technique to achieve this?

SO_REUSEPORT is a 4.4BSD-ism.  One other system that supports multicasting
(Solaris 2.x) that I've used, uses SO_REUSEADDR for the same purpose.  I
don't think you'll find SO_REUSEPORT in POSIX.12 either.  Realize that
unless your kernel supports multicasting, it's normally impossible for
two UDP endpoints to have identical <local,addr, local-port>.

	Rich Stevens

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 14:35:01 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

Marcus J. Ranum -- Crash Test Dummy for the Information Superhighway
<mjr@tis.com> wrote:
}>Are there any broadcast file transfer packages or a broadcast file transfer
}>protocol?
}
}	NNTP

  I'm guessing the original poster meant `broadcast' as in
  broadcast packets (i.e., with IP address 255:255:255:255).

John ``55 Mb/s, it's not just a good idea, it's the law'' Hascall
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 14:58:13 GMT
From:      mattias@shogun (Mattias Olsson)
To:        comp.protocols.tcp-ip
Subject:   Telnet for windows

Hello !
The University if Stockholm , Sweden ,needs...
An telnet client for windows with A with a circle,
A with two dotts , O with two dotts !
Or if there is an telnet client that you can configure your self ?
Sharewares of cource.
If you can help me please contact me at mattias@shogun.tele.su.se
Thanks in advance !

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 15:32:00 GMT
From:      wat@ewi.ch (Wacker Thomas)
To:        comp.protocols.tcp-ip
Subject:   Network Cost Accounting Anyone?

[ Article crossposted from comp.dcom.sys.wellfleet ]
[ Author was Wacker Thomas ]
[ Posted on Wed, 16 Feb 1994 13:20:11 GMT ]


I am interested in _Accounting_Models_ and Tools for Networking Costs
that are actually _in_use_today_. Special focus is on connectionless
network protocols such as IP or DECnet, since with these cost
accounting down to user-level is not feasible.

To what granularity do you account?
  - Interface ports
  - Network address (IP-Subnet, DECnet-Area)
  - Host address

What do you charge?
  - Time of connect
  - Bandwidth consumed
  - Distance
  - Flat rate per LAN connection, per user, ...

Which network entity collects the network usage data?
  - routers (products?)
  - LAN sniffers (products?)
  - Endsystems (database application, ...)

How do you process the network usage data?
  - self-written SW
  - commercial SW (which?)


All help, info and hints are highly welcome!

				Thomas
-- 
----------------------------------------------------------------------------
___         .   Thomas Wacker                  |Phone       ++41 1 385 31 57
__   / / /  |   Internetworking Consultant     |Fax         ++41 1 385 24 25
___   / /   |   wat@ewi.ch     /g=Thomas/s=Wacker/o=EWI/p=EUNET/a=ARCOM/c=CH
-- 
----------------------------------------------------------------------------
___         .   Thomas Wacker                  |Phone       ++41 1 385 31 57
__   / / /  |   Internetworking Consultant     |Fax         ++41 1 385 24 25
___   / /   |   wat@ewi.ch     /g=Thomas/s=Wacker/o=EWI/p=EUNET/a=ARCOM/c=CH

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 15:51:53 GMT
From:      Heemstra@rc.rug.nl (Mente H. Heemstra)
To:        comp.protocols.nfs,ieee.pcnfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NFS server to use with PC/TCP ???

Eigil Krogh Sorensen (eks@vki68.aar-vki.dk) wrote:
> Is there a NFS server that can be used on PCs and run together with
> PC/TCP so PC disk(partitions) can be exported from the PC and
> mounted on other computers ?
>
> We use both DOS and Windows.
>
> If so would you please inform me the name of the product and evt.
> where I can get it.
>
I'm not sure, but it's worth the try.
You could try PKTMUX on top of the packet driver, and on to of that two
packet drivers: one for PC/TCP's kernel and one for running SOSS.

Mente.


 _______________________________ ____________________________________________
|                               |                                            |
| Mente H. Heemstra             |                                            |
| State University Groningen    |    Email : M.H.Heemstra@rc.RuG.nl          |
| Computing Centre              |    X.400 : C=NL; ADMD=400net; PRMD=SURF;   |
| Network Management            |            O=RuG; OU=RC; S=Heemstra; I=MH; |
| P.O. Box 800                  |    Phone : + 31 50 633433/638080           |
| 9700 AV  Groningen            |    Fax   : + 31 50 633406                  |
| Netherlands                   |                                            |
|_______________________________|____________________________________________|


-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 17:12:42 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP header flags

In article <2jque4$29q@horus.mch.sni.de> wf@d255s295.mch.sni.de (Wolfgang Fischer) writes:
>I ran into a problem with a Sun running Solaris 2.3 mounting a NFS
>filesystem without restricting rsize/wsize to 1024. Snoop shows
>that the IP header has following flags set:
>
>IP:   Flags = 0x6
>IP:         .1.. .... = do not fragment
>IP:         ..1. .... = more fragments
>
>The receiving side does not like this and replys with an ICMP packet
>type 12 (bad IP header). Our current understanding is, that the
>receiving side chokes, because of "do not fragment" and "this UDP packet
>is fragmented", which seems to be a contradiction.
>
>So my question is, what exactly are those two flags supposed to mean?

While this is a very unusual combination, I don't think that it is
strictly illegal.  This is a packet that has been fragmented, but marked
to disallow further fragmentation.  The "Don't Fragment" bit (DF) states
that this datagram should not be subjected to IP fragmentation.  The
"More Fragments" bit (MF) indicates that this is only a fragment of the
original IP datagram.  Either the source host fragmented the packet
and then set the DF bits, or someone ignored the DF bit and improperly
fragmented a DF packet.

Art


-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 17:19:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP header flags

In article <2jque4$29q@horus.mch.sni.de> wf@d255s295.mch.sni.de (Wolfgang Fischer) writes:
>IP:   Flags = 0x6
>IP:         .1.. .... = do not fragment
>IP:         ..1. .... = more fragments
>
>The receiving side does not like this and replys with an ICMP packet
>type 12 (bad IP header). Our current understanding is, that the
>receiving side chokes, because of "do not fragment" and "this UDP packet
>is fragmented", which seems to be a contradiction.
>
>So my question is, what exactly are those two flags supposed to mean?

"Do not fragment" is a command to routers, telling them they may not
fragment that packet.  While the above combination seems unusual, I don't
think it's contradictory, and I don't think the receiver should reject it.
The sender is probably setting the DNF flag as part of Path MTU Discovery.
But it's also fragmenting the packet at the source, because it's trying to
send the typical 8K NFS data packets, which are too large for most
networks.

If you can disable Path MTU Discovery, that would probably get rid of the
problem.  It's a useful facility, but not critical.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 17:33:23 GMT
From:      hurtta@dionysos.Fmi.FI (Kari E. Hurtta)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: SMTP "Apparently-To:"??

[Added comp.mail.sendmail as receiver.]

lawson@netcom.com (Steven Lawson) writes:
>I am writing an SMTP daemon and incoming mail is getting the 'To:' field
>in the message changed to 'Apparently-To:'.  What am I doing wrong?  I
>have not found this in the RFCs.

I don't understand. 'Apparently-To:' is sendmailism.

Quote from sendmail's manual:
| If a message comes in with no recipients listed in the message
| (in a To:, Cc:, or Bcc: line) then sendmail will add an "Apparently-To:"
| header line for any recipients it is aware of.  This is not put in as a 
| standard recipient line to warn any recipients that the list is not complete.
 
| At least one recipient line is required under RFC 822.
--
- Kari E. Hurtta                             /  Elämä on monimutkaista
  Kari.Hurtta@Fmi.FI

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 17:55:55 GMT
From:      rdk@cc.gatech.edu (Bobby Krupczak)
To:        csd.grad,comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.unix.internals
Subject:   Re: TCP/IP and Ethernet Performance Papers

One paper you may want to check out is "Experimental Evaluation of SunOS IPC and
TCP/IP Protocol Implementation" by Papdopoulos and Parulkar in IEEE/ACM
Transactions on Networking.  I include a bibtex entry for it below.  Its pretty
good about evaluating the performance of TCP/IP itself.

Bobby

@article{parulkar:eval,
   author = "Papadopoulos, Christos and Parulkar, Gurudatta",
   title = "Experimental Evaluation of SUNOS IPC and TCP/IP Protocol
            Implementation",
   journal = "IEEE/ACM Transactions on Networking",
   volume = "1",
   number = "2",
   month = "April",
   year = "1993",
   pages = "199-216"}

In article <2jt748$6aj@poptart.cs.umd.edu>, mdtanx@cs.umd.edu (Michael D. Tan) writes:
|> 
|> 
|> Has anyone seen a paper or book which does a performance study of
|> TCP/IP over Ethernet (10Mb/s (not research Ethernet)) using multiple
|> hosts?  I've seen the Boggs, Mogul, and Kent [1988] paper, which does
|> performance studies for Ethernet *only*.
|> 
|> Please send replies via email to
|> 
|> Michael Tan
|> mdtanx@cs.umd.edu




-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 19:12:20 GMT
From:      hc05@rexago8.uucp (Beirne Konarski)
To:        comp.protocols.tcp-ip
Subject:   Subnetting question

I have been learning more about TCP/IP recently and have been trying to figure 
out subnetting.  I think I understand the basic concepts, but I need
clarification on a few items.

If I have a router at site A, a connection to a router at site B, and 1 
computer attached to router B, do I have 2 subnets requiring 4 addresses?

Assuming that I have 2 subnets, which I believe is the correct answer, can I
have the router connections (A-B) use a different mask than the router feeding 
the computer at site B?  I would like to use 4 bits of host address for the
computer (there will be more devices in the future), but hate to waste 14
addresses on each router-router connection.  I would like to maybe leave two
bits for the addresses between routers.

And finally, can subnets be hierarchical, i.e. if I have a class B, can I use a
mask of FF.FF.F0.00 to divide addresses among different parts of the company
and then let the parts subnet from there?  For example, could one of the
subnets off of this mask create their own mask of FF.FF.FF.00?  If so, how is
this defined at the site that needs to talk to both sides?


Thanks,
Beirne
-- 
-------------------------------------------------------------------------------
Beirne Konarski			|
beirnek@summitis.com 		| I am not a free man, I am a number. 
"Untouched by scandal"		|

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 20:35:35 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting question

>If I have a router at site A, a connection to a router at site B, and 1 
>computer attached to router B, do I have 2 subnets requiring 4 addresses?

Your picture is a bit unclear, so let me restate your scenario.  Two routers
interconnected by some link.  One LAN segment attached to each router with user
machines attached to these segements.

For proper routing you will need 2 or more subnets.  For cisco routers using
'unnumbered' interfaces (on the dedicated line between routers), 2 subnets would
be sufficient -- the link would not be assigned a subnet.  If the router does
not feature 'unnumbered' interfaces, then a third subnet would be assigned to
the link.

>Assuming that I have 2 subnets, which I believe is the correct answer, can I
>have the router connections (A-B) use a different mask than the router feeding 
>the computer at site B?  I would like to use 4 bits of host address for the
>computer (there will be more devices in the future), but hate to waste 14
>addresses on each router-router connection.  I would like to maybe leave two
>bits for the addresses between routers.

If your routers support variable-length subnet masks, as defined in RFC 1247 --
OSPF, version 2, then you will be able to make the most efficient use of your
address space and allocate the minimum number of addresses to a point-to-point
link (4) with a maximum length subnet mask.  Note 00 and 11 are reserved, leaving
01 and 10 for the interface addresses (numbers are binary).

>And finally, can subnets be hierarchical, i.e. if I have a class B, can I use a
>mask of FF.FF.F0.00 to divide addresses among different parts of the company
>and then let the parts subnet from there?  For example, could one of the
>subnets off of this mask create their own mask of FF.FF.FF.00?  If so, how is
>this defined at the site that needs to talk to both sides?

Yes, again your routers must support variable-length subnet masks...  Assigning
the masks and subnets will be dependent on the routers you use.

>Thanks,
>Beirne
>-- 
>-------------------------------------------------------------------------------
>Beirne Konarski			|
>beirnek@summitis.com 		| I am not a free man, I am a number. 
>"Untouched by scandal"		|

John Brady
Network Management Consultant
SunNetworks, A Sun Microsystems, Inc. Business
(703) 204-4859
john.brady@East.Sun.Com





-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 21:18:18 GMT
From:      rleary@UMASSD.EDU
To:        comp.protocols.tcp-ip
Subject:   IEEE hex representation?


   The IEEE 802 standard defines two ways of representing LAN MAC addresses.
The binary representation displays a 48-bit MAC address as a string of
six octets, the octets being displayed from left to right in the order they
are transmitted on the LAN. For example, the following:

   Octet 0    Octet 1    Octet 2    Octet 3    Octet 4    Octet 5
  0011 0101  0111 1011  0001 0010  0000 0000  0000 0000  0000 0001

represents a 48-bit LAN MAC address, the leftmost bit (the I/G bit), the
first bit transmitted on the LAN medium, being 0 in this case.

  All well and good.

  Then IEEE also defines the "illustrative (in hexadecimal)" representation.
In this representation, the above address would be:

                      AC-DE-48-00-00-80


Now I understand how the mapping is done (RFC 1340 describes the above
representation as "bits transmitted right-to-left within octets, octets
transmitted left-to-right") but I have always felt that this was an
infernal representation. I guess it makes sense from a "memory perspective"
rather than a "wire perspective".

   My question is, is the IEEE illustrative representation also used
as the standard Internet hex represenation for MAC addresses? And if so,
is this representation used consistently in Internet standards?



-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 94 22:27:06 GMT
From:      conbvs@melupl (Bill VerSteeg (Contract))
To:        comp.protocols.tcp-ip
Subject:   need inexpensive token ring->enet router

I am writing a token ring driver for an embeddeded system
SNMP agent. I have done quite a few ethernet projects lately,
so all of my lab equipment is ethernet based.

Rather than convert all of my test gear to token ring, I want
to just convert some of it, and keep my existing ethernet
lab as is. I would then use a token ring -> ethernet router
to tickle my new hardware.

So- 
Is there a cheap router with token ring support?. Last time
I checked, pcroute was ony ethernet and SLIP/PPP. Is there
anything similiar with token ring support? KA9Q maybe? 
Windows NT? A PC software package? Failing that, who
sells a good low-end router with token ring support? 

I have a slew of PC token ring and ethernet cards, so I am looking
for something in the class of a PC with a token ring card and an ethernet card.

Please note the reply-to address is bvs@ver.com

Bill VerSteeg

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 23:01:11 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

In article <CLAqM5.9B3@ncratl.AtlantaGA.NCR.COM>, brama@ncratl.AtlantaGA.NCR.COM
	 (Bhyravabho Rama) writes:
B.Rama|> Are there any broadcast file transfer packages or a broadcast file transfer
B.Rama|> protocol? What I want to be able to do is send a file to set of machines
B.Rama|> instead of having to specify a rcp for each machine or remsh for each machine
B.Rama|> to execute a given command.

What you want is Multicast support on the host from where you are transferring the
file and the destination hosts as well as any intermediate routers. Then you can
add the destination hosts to a multicast group and ftp to that multicast address.
There is a lot more to be said about this issue but you can pick up the code
for multicast support from Stanford and other sites. Please use archie to get
the right addresses.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 23:09:24 GMT
From:      jime@well.sf.ca.us (Jim Eberle)
To:        comp.protocols.tcp-ip
Subject:   SO_REUSEADDR and listeners

    In order to restart a listener at a given port, I'm doing a setsockopt
    SO_REUSEADDR before the bind(). This way, any stragglers
    (TIMED_WAIT's) or hangers-on (TIMED_WAIT_2's) will be ignored and will
    the bind will succeed, i.e. { tcp, host, service, *, * } is OK.

    I'm suprised and concerned that this step is not covered in any of the
    literature I've come across. Oddly though, I can't see any danger in
    doing this and it eliminates a major headache/limitation. Without this
    step, all clients that have not gracefully closed their sockets (sent
    a FIN) would need to power down or go into a console program to
    manually delete their end of the connection. I believe it is safe
    because it only ignores the remote end of the existing connections.
    Therefore, it is impossible to start two listeners at a given port.

    In the collective Internet mind, is this an acceptable and safe
    technique?
    Many thanks for a restful sleep. 
    
    Jim Eberle  jime@well.com
    
     
    

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 23:33:10 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: SMTP "Apparently-To:"??

In article <CLA862.1C6@aston.ac.uk> evansmp@mb48025.aston.ac.uk (Mark
Evans) writes:

:Steven Lawson (lawson@netcom.com) wrote:
:: I am writing an SMTP daemon and incoming mail is getting the 'To:' field
:: in the message changed to 'Apparently-To:'.  What am I doing wrong?  I
:: have not found this in the RFCs.
:
:Possibly the mailer is using the DNS to verify hostnames and it is
:detecting is discrepency.
:
:e.g. you are sending to an alias.

If you don't have a "To:" in the envelope of your message -- the stuff
you'd put after the "data" when you are writing "raw" to a sendmail
daemon, it will add the "Apparently-To:".  Nope, it's not in the RFCs
-- just something that sendmail, even the newer revs, wants to do.

Simple solution, if this bothers you, is to add a "To:" line after "data"
that contains the same contents of your "rcpt to" line (before data).

						...Mike


-- 
 Michael J. O'Connor           |  Internet:  mjo@jobone.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Feb 1994 23:58:32 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP "Apparently-To:"??

Mark Evans (evansmp@mb48025.aston.ac.uk) wrote:
: Steven Lawson (lawson@netcom.com) wrote:
: : I am writing an SMTP daemon and incoming mail is getting the 'To:' field
: : in the message changed to 'Apparently-To:'.  What am I doing wrong?  I
: : have not found this in the RFCs.
 
: Possibly the mailer is using the DNS to verify hostnames and it is
: detecting is discrepency.
 
: e.g. you are sending to an alias.

Something like this could be the case.  More detail:  It happens when I
am using gopher on nic.cerf.net and mail myself things all the way back
to my SLIP-connected system here in the office (it has a dedicated IP
address).  I can see a record when I do a 'whois', but I'll bet that
record is for the login name on nic.cerf.net, not a host name of my
local system.  (the login name and the host name are the same, alpham.

Anyway, I was concerned I was missing something in my implementation
but it looks like I may just be weird in the DNS.  Being a dialup SLIP
host with a dedicated IP address works ok, but appears to have certain
odd characteristics at times.. :-)


-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1994 20:50:14 +0200
From:      paul@frcs.alt.za (Paul Nash)
To:        comp.unix.pc-clone.32bit,comp.unix.admin,comp.protocols.tcp-ip
Subject:   Eicon X.25 router & ESIX -- help needed

I have a client with a _large_ problem.  They are running an ESIX machine
(basically AT&T V.4 on a 486) with Lachmann's TCP/IP.  They have purchased
(at vast expense) an Eicon X.25 card, plus the AT&T V.4/Lachmann IP router
software.  It doesn't work.

It looks as though the installation software does everything but edit the
/etc/strcf file, which means that the IP/X.25 device is never initialised
(or created?), and so cannot be ifconfig'ed.

The local agents' response to date has been "Duuuuh".  Apparently Eicon
themselves have given much the same response.

Before they do things with the card and the agents that will probably put
them in gaol for a good few years, has anyone got any suggestions?  Is it
possible to make this combination work?  If so, _how_?  Or do they just 
write off about 20 000 bucks, and start selling second-hand cars instead?
Or buy a small thermo-nuclear device and detonate it in the immediate 
vicinity of the local Eicon agents?

I'd appreciate email replies, as my newsfeed is _very_ erratic.  However, 
I will keep looking at the news.

Thanks

	paul <paul@frcs.alt.za>
-- 
 Paul Nash                    network grunt and bit-pusher extraordinaire
 paul@frcs.alt.za          PO Box 12475, Onderstepoort, 0110 South Africa

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 00:18:29 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Cost Accounting Anyone?

In article <CLBptF.96y@ewi.ch> wat@ewi.ch writes:

>I am interested in _Accounting_Models_ and Tools for Networking Costs
>that are actually _in_use_today_. Special focus is on connectionless
>network protocols such as IP or DECnet, since with these cost
>accounting down to user-level is not feasible.

Thomas,

I am interested in this subject too, and have just completed an
assignment for a UK Regional Authority.  They commissioned me
to advise on the accounting, charging and billing to use for their
150-plus node X.25 network.  This is due to the UK health sector's 
transition to market economics for internally provided services.
Their "customers" are hospitals, clinics and District Health 
Authorities, who all used to be "owned" by the Region  (ie. they were
part of the old pan-regional management structure.

I came to the reluctant conclusion that to establish an arbitrary
relationship between costs and user-charges was inappropriate
for a health service operating on a shoe-string. (Patient care
is paramount and none of the new commercial services are allowed 
to make a profit.)

In summary, the Regional Authority's costs for the network 
are all fixed (KiloStream rentals, salaries and equipment maintenance).
If we were to select an accounting method based on some "usage-based"
metric (packets, bytes, duration etc.) we would be forced to 
decide some multipliers (eg. 17 pence per Kbyte??? or whatever).

If it tried to breakeven, the Region would risk making either a 
massive profit or a massive loss, depending on the precision of 
its estimates !!!

I advised that this would be invidious, (almost obscene) in the 
health service.

Now I applied this argument to X.25.  However, I believe that the
concept is equally true for connectionless services.  That is,
you must ask youself why you need to separate costs from charges?
Why do you want an arbitrary relationship between fixed costs and 
variable (customer) charges?  If you are operating a genuinely
commercial operation (eg. like the PTTs) then there is some argument.
(But have you ever calculated the mark up which a PTT makes on
a fixed link used in an X.25 network?  A single 64 kb/s KiloStream 
carrying X.25 traffic at 60% capacity for a few hours per day could
generate over 100k UK pounds per annum!)

Another issue, which, following the above argument, is less 
significant, but which may be significant to you, is that metrics 
for charging where connectionless protocols are used are even 
more difficult to establish than for connection mode.

You are certainly asking detailed questions, but I think they
may be the wrong ones.  However, I'll make some comments which
I hope will help:

>To what granularity do you account?
>  - Interface ports
>  - Network address (IP-Subnet, DECnet-Area)
>  - Host address

To whatever the "cost centre" wants.  If a "department" is a cost centre 
and "owns" N connection points (interfaces?), then you need to give them 
an itemised bill showing what each interface used (in the chosen metric(s)).

>What do you charge?
>  - Time of connect
>  - Bandwidth consumed
>  - Distance
>  - Flat rate per LAN connection, per user, ...

Each of these is very difficult to measure for connectionless
network protocols.  One criterion for the choice is whether the users
thought it was "fair" (judged by whatever metric they thought 
represented fairness :-).   (Your small but distant branch offices
would be gutted if you charged on distance, or flat rate.)

>Which network entity collects the network usage data?
>  - routers (products?)
>  - LAN sniffers (products?)
>  - Endsystems (database application, ...)

I don't know.  This decision should follow on from your first decision
on WHAT basis to charge on.

>How do you process the network usage data?
>  - self-written SW
>  - commercial SW (which?)

I guess this decision is even further downstream.
However, I am not aware of there being any commercial accounting, 
charging and billing packages designed for connectionless protocols.

Our final decision has been to charge on the basis of a flat rate
per item of equipment supplied on the premises (nodes, PADs,
gateways etc.) PLUS a "support charge" set for three categories
(low user, medium user and high user).  Thus each "customer" gets
a **predictable** annual bill which varies with the amount of kit
installed on his site(s) PLUS a single support charge, which 
**bears some relationship** to his usage of shared resources on the 
network.

>All help, info and hints are highly welcome!
>
>                                Thomas
>-- 
>----------------------------------------------------------------------------
>___         .   Thomas Wacker                  |Phone       ++41 1 385 31 57
>__   / / /  |   Internetworking Consultant     |Fax         ++41 1 385 24 25
>___   / /   |   wat@ewi.ch     /g=Thomas/s=Wacker/o=EWI/p=EUNET/a=ARCOM/c=CH
>-- 

Regards,

Phil R.

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-986

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 00:38:52 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <DRW.94Feb15200117@jordan.mit.edu> drw@jordan.mit.edu (Dale R. Worley) writes:

> ...
>The issue that people should examine more carefully is the measure of
>performance that they used -- total throughput in sending
>multi-megabyte files by FTP.  The implication is that this is an
>*important* measure of performance to the people reading the magazine.
>I suspect that no TCP/IP vendor has looked into optimizing his
>implementation for that use!
> ...

I could say authoritatively that at least one UNIX workstation vendor has
looked at its FTP performance, and done things like ensuring buffers are
page aligned and large so that "page flipping" over FDDI happens, since
I did the work.

Still, your underlying point that FTP performance on large files is not
very interesting is a good one.  I've seen more than a few organizations
that use FTP to move multi-MB files among UNIX machines and "super
computers" in production code, but I hope and believe they are a minority.
The usual excuse for using FTP instead of something more appropriate is
some form of "our mainframe can't do anything else."


Vernon Schryver    vjs@rhyolite.com

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 00:45:31 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Timed out NFS hangs ls

In article <2jru2n$7bn@crl2.crl.com> cgi@crl.com (Paul Smith) writes:
> ...
>Is this totally broke, or is this the wonderful world of NFS the stateless
>wonder??


Before deciding that everyone else has had terrible problems with something
that has been in large scale commercial use for 10 years, it pays to stop,
think, and look for alternatives, especially consider the possibility that
major problems are personal problems.

Reading The Friendly Manual is often useful.

In this particular case, read any NFS primer or `man mount` or `man fstab`
on any reasonable system, and look for the words "hard," "soft," and
(perhaps) "spongy" in the same sentance as the word "mount."


Vernon Schryver    vjs@rhyolite.com

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 03:18:36 GMT
From:      samson@iohk.com (Samson Luk)
To:        comp.protocols.tcp-ip
Subject:   IP Traffic

Is there such a utility for collecting ip traffic passing through a certain
ip hosts?

netstat only report the no. of packets passing through a particular route
but what I need is no. of bytes instead of packets.

Samson Luk

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 04:00:06 GMT
From:      edward@e0sun29.ccl.itri.org.tw (Chao-Chi Yang 37h3100)
To:        comp.protocols.tcp-ip
Subject:   How to watch the traffic flow on FDDI ?


Hi,
      How can I check if any traffic flow on NP-FDDI ?  Where
  can I find any network utilities like 'etherfind' or
  'nfswatch' that can display network status on a specific
  FDDI LAN ?

  Thanks for your response.

--
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
| __ ___                                                |
|  |||           ´­´Â¦N                                 |
|__|||_          Chao Chi Yang (Edward)                 |
|                                                       |
|   at Advance Tech. Center, CCL, ITRI, Taiwan          |
|       						|
|   TEL 	886-35-917178                           |
|   FAX 	886-35-820098                           |
|   Email       edward@e0sun3.ccl.itri.org.tw           |
|                                                       |
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 04:43:05 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: New Group?

Bob Sutterfield (bob@MorningStar.Com) wrote:
: In article <1994Feb9.134158.27728@newsgate.sps.mot.com> maislin@hermes3.sps.mot.com (David Maislin) writes:
:    What is be a good idea to start a comp.protocals.slip group?  I
:    seem to see discussions on about six different group concerning
:    SLIP.
 
: I've lost the charter article (Ed?), but during the discussions (early
: April 1991) leading to the creation of comp.protocols.ppp, it was
: clear that the newsgroup was intended to carry discussions related to
: all point-to-point networking protocols.  

I looked on
	ftp.uu.net:/usenet/news.announce.newgroups/comp/
but I guess it was before the time that the charters of the groups were
regularly kept.

As it happens, the main topics of discussion with most SLIP or PPP
questions are not protocol level interoperability concerns (those are
mostly, though not entirely, sorted out right now); it's the pesky
details of each implementation that need the most discussion.  So
you will see MacSLIP questions in comp.sys.mac.comm, Trumpet questions
in alt.winsock, etc.

--Ed

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 04:47:33 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP header flags

In article <1994Feb16.171242.11408@acc.com> art@acc.com (Art Berggreen) writes:
>>IP:   Flags = 0x6
>>IP:         .1.. .... = do not fragment
>>IP:         ..1. .... = more fragments


>While this is a very unusual combination, I don't think that it is
>strictly illegal.  This is a packet that has been fragmented, but marked
>to disallow further fragmentation.  The "Don't Fragment" bit (DF) states
>that this datagram should not be subjected to IP fragmentation.  The
>"More Fragments" bit (MF) indicates that this is only a fragment of the
>original IP datagram.  Either the source host fragmented the packet
>and then set the DF bits, or someone ignored the DF bit and improperly
>fragmented a DF packet.

What if the sender is trying to do MTU discovery for NFS/UDP?  Wouldn't
it have to use exactly that combination for the first half dozen IP
fragments of the typical 8K NFS/UDP datagrame.

I continue to maintain that MTU discovery for UDP based applications is
hopeless because of 2 or 3 insurmountable practical problems, but not
because of this oddity.


Vernon Schryver    vjs@rhyolite.com

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 07:10:45 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Uni-directional firewalls - why not?

I was just wondering why sites implement full IP firewalls for their
Internet connectivity.  I know of many commercial sites which are
content with more functional uni-directional firewalls.  I was wondering
if there was a reason why people don't always implement these.

Without going into a lot of detail, the basics of a uni-directional 
firewall are:

A Internet connected router that implements IP packet filtering which only 
allows packets originating from the Internet to come in if those packets 
have UDP or TCP port numbers greater than 1023. The firewall may also 
allow packets destined for the SMTP and DNS ports to certain machines 
as well.

All packets originating from within the organization will be allowed out
to the Internet.

This scheme thus prevents any Internet host to communicate with any
server within the organization. 
-- 

______________________________________________________________________

 Phil Trubey                 | 
 NetPartners                 |
                             | Providing independent consulting in the    
 E-mail: ptrubey@netcom.com  |   application of Internet technology        
 Phone:  714-759-1641        |                                             
 Fax:    714-644-0577        |
______________________________________________________________________

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 13:42:01
From:      Chaplaincy@vuw.ac.nz (VUW Chaplaincy)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc
Subject:   Re: Internet Talk client for DOS/Windows?

In article <12FEB94.03040565.0013@lafibm.lafayette.edu> Thayer York <YT50@lafibm.lafayette.edu> writes:

>Anyone out there seen (or written) a program for DOS or (preferably)
>Windows that will emulate an Internet Talk session?  Our school's

try elf.com, /pub/wintalk or something similar.

A new version should be out soon.

Jack.


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 09:40:20 GMT
From:      tsuda@mtc.telcom.oki.CO.JP (<M.Tsuda>)
To:        comp.protocols.tcp-ip
Subject:   Q:about Dual Stack

Hi.

I'm looking for a literature about "Dual Stack" for OSI and
TCP/IP protocol.
Please tell me any information about the above.
--
Masahiko Tsuda        tsuda@mtc.telcom.oki.co.jp

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 12:51:37 GMT
From:      stevef@aom.bt.co.uk (Steve Fosdick)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP LIST Specification proposal

Robert J Minich (minich@a.cs.okstate.edu) wrote:

> I assert that what most FTP client software would like to know is:
 
> 	1. What's the object's name?
> 	2. Can I CWD into it?
> 	3. Do I have permission to retrieve it?
> 	4. How many bytes would you send if I retrieved it?
 
> All the rest is gravy. I would suggest some sort of query like the
> following: (note that XMRL = X-Machine-readable-list
 
> 	XMRL <PATH=.> <ATTRIBUTES=NAME,TYPE,SIZE,CAN_READ>

[stuff deleted]

I like the idea of a new XMRL command.  I would like to see the above
list extented but I think we are absolulty on the right to track in
considering a file (or directory's) attributes in terms of what ftp
commands will work on it.  One could compile an attribute string
something like 'gpcdr' short for can I:

	g	GET the file
	p	PUT the file
	c	CWD to the directory
	d	DELE the file.
	r	REN the file. (or whatever the rename command is)

Each character could be present if the command would work absent if
not. (or replaced with '-' if not).

It would be nice to have the size in terms of the number of bytes that
would be transferred but this may not be easy to calculate.  Perhaps
this could just be very aproximate, i.e. the difference between text
and binary modes could be ignored and it could be quite accepatble to
round up to the nearest file system block.

--
Steve Fosdick                           Post:   Room 210, B67, BT Labs,
E-mail: stevef@aom.bt.co.uk                     Martlesham Heath,
Tel:    +44 473 642987                          IPSWICH   IP5 7RE
Fax:    +44 473 644607                          England

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 13:21:00 GMT
From:      patel_a@watson.bms.com (Andy R. Patel)
To:        comp.protocols.tcp-ip
Subject:   Compaq 66Mhz-DeskproM

Exceed/w allows login to Sparc 10 Model 51, but when running SAS screen 
randomly freezes. We have been able to maintain a connection anywhere from 1 
min to 2.5 hrs.... If somebody out there has same problems or a solution... 
Help us out...Thanks in advance.... 


-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 14:06:40 -0000
From:      devore@maths.tcd.ie (Tom Murphy)
To:        comp.protocols.tcp-ip
Subject:   Please send me FAQ

Can somebody mail me the FAQ for this group (or similar file).
I don't have FTP access and would like to know more about 
TCP-IP.

I have experience on other types of protocols , just not this one.

a speedy reply would be appreciated as I have an interview to swot up
for. 

Thanks.

Tom Murphy.







-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 14:18:52 GMT
From:      arieli@mot.com (Moshe Arieli)
To:        comp.protocols.tcp-ip
Subject:   Questions related to the Mobile wireless IP


   I would be interested to better understand the various aspects related to the 
   implementation of the TCP/IP protocol suite on a wireless network, that provide
   the host migration transparency to the application and, if possible, to the TCP too.

   I understand that there is a group of the IETF that works on this subject, called
   "Mobile IP".        
                                                                         
   I have the following questions: 
     1. what is the status of the mobile IP?
     2. what are the latest documents related to it?
     3. does the "mobile IP" issue cover the wireless communication?

   I possess the following two documents:

   "Protocols for supporting mobile IP hosts" by J.Ioannidis et al., June 92

   "The virtual network protocol for host mobility" by F.Teraoka et al., July 93
   Both these two drafts are expired.

   I also have the RFC #1541:
   "Dynamic Host Configuration Protocol" by R. Droms, October 1993


   Thank you in advance for your time.

   [ Moshe Arieli                                                     ] 
   [ E-mail: arieli@mcil.comm.mot.com  Motorola Communications Israel ]
   [                                   Fixed & Data Products Division ]
   [ Phone:  972 (3) 565-8730          3 Kremenetski Street           ]
   [ Fax:    972 (3) 565-8356          67899  Tel-Aviv,  ISRAEL       ]

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 14:44:42 GMT
From:      bab@wg2.waii.com (Brian Button)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and multicasting questions

I'm playing around with using multicasting facilities on Solaris 2.3
for my current project, and I have some conceptual questions about it.

Can someone point me to a magazine, book, or resource of some type
where I can learn about multicasting? I've looked in Stevens' first
and second books, and there is not much in there about actually using
multicasting, and those are about the only resources we have available
here.

Any help will be appreciated :)

Thanks,
bab
-- 
Brian Button	| email : button@wg2.waii.com	   | voice : (713)964-6221
Design Engineer	|         71023.276@compuserve.com |

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 14:46:06 GMT
From:      mjr@tis.com (Marcus J. Ranum -- Crash Test Dummy for the Information Superhighway)
To:        comp.protocols.tcp-ip
Subject:   Re: Uni-directional firewalls - why not?

>I was just wondering why sites implement full IP firewalls for their
>Internet connectivity.  I know of many commercial sites which are
>content with more functional uni-directional firewalls.  I was wondering
>if there was a reason why people don't always implement these.

	Yes -- some people don't feel that uni-directional firewalls
are necessarily strong enough for what they're doing. It depends on
what you're trying to accomplish from a security standpoint.

	One problem with the "uni-directional" firewall approach
is that it still permits (sometimes, as you describe below) traffic
to come "in" on port ranges higher than certain values. That's a
real risk if you wind up running services that use dynamic IP
addresses, or are above the range and you forget to protect them.
Another issue is that some organizations want an audit trail of
traffic -- router based firewalls are not especially strong in
this regard.

	Lastly, there's the issue of where you want to place your
trust boundary. "uni-directional" firewalls implicitly assume that
users and applications on the internal network are trustworthy. In
a paranoid example, suppose someone ships an application into your
network that opens an outgoing reverse telnet connection to an
attacking host? Unlikely, but some people worry about things like
that because some people have a lot to lose and can't afford to
take chances.

>Without going into a lot of detail, the basics of a uni-directional 
>firewall are:
>
>A Internet connected router that implements IP packet filtering which only 
>allows packets originating from the Internet to come in if those packets 
>have UDP or TCP port numbers greater than 1023. The firewall may also 
>allow packets destined for the SMTP and DNS ports to certain machines 
>as well.
>
>All packets originating from within the organization will be allowed out
>to the Internet.
>
>This scheme thus prevents any Internet host to communicate with any
>server within the organization. 

	No, it doesn't. It prevents any internet host from communicating
with any server within the organization if the packets have UDP or TCP
port numbers less than 1023. That means that X windows, sybase data
servers, and so for are wide open to attack. Not exactly what I'd call
"bet your business security" but your actual mileage may vary.

	The kind of firewall described is in fairly widespread use
around the 'net. I'm not saying it doesn't work -- but it's not
quite as simple as it sounds -- you need to spend a lot of time
figuring out what ports to let through and what ports to block and
thrashing around trying to make FTP and other braindead protocols
work.

	All firewalls are is an attempt to reduce the risk inherent
in a network connection. As such, they need to be of a strength that
is appropriate to what you've got to lose. A "uni-directional" firewall
that consists of nothing more than a screening router is fine for
most folks -- if I were running a small company, I might be comfortable
with that. If I were running a major financial institution, with lots
of sensitive information online, I might be more cautious.

	There's good discussion on this topic and related issues in
the firewalls archives, which are maintained by Brent Chapman on
ftp.greatcircle.com

mjr.
-- 
One-time pad available upon request

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 15:06:38 GMT
From:      lchutson@netcom.com (Lawrence Hutson)
To:        comp.protocols.tcp-ip
Subject:   RPC: Unknown protocol ???


Hi Netters, RPC guru's, and Norwegian Folklore Specialists,

This is quite a trivial question for a RPC Guru, but it is
breaking my program!

I wrote a small RPC "hello world" program, and it compiled!!
I followed the example like a good programmer should, but when I
started the client I get the error: RPC Unknown protocol.

Could this be a Norwegian (elf, nolm)? What were those little
creatures that come out of the snow, you know, the ones that you
should consult if you are going to build a barn in Norway?

Any help on these matters will be greatly appreciated.

Thx
Lawrence Hutson


-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 15:25:18 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

In article <1994Feb16.175316@bbn.com> adiwan@bbn.com (Arif Diwan) writes:
>In article <CLAqM5.9B3@ncratl.AtlantaGA.NCR.COM>, brama@ncratl.AtlantaGA.NCR.COM
>	 (Bhyravabho Rama) writes:
>> Are there any broadcast file transfer packages or a broadcast file transfer
>> protocol? What I want to be able to do is send a file to set of machines
>> instead of having to specify a rcp for each machine or remsh for each machine
>> to execute a given command.
>
> What you want is Multicast support on the host from where you are
> transferring the
> file and the destination hosts as well as any intermediate routers. ....
> Then you can
> add the destination hosts to a multicast group and ftp to that
> multicast address.
> There is a lot more to be said about this issue but you can pick
> up the code
> for multicast support from Stanford and other sites. Please use
> archie to get
> the right addresses.

(What was the strange "Followups-to: 31242" line?)

Multicast UDP/IP packets are useless for FTP.  FTP uses TCP.  Multicast
UDP/IP packets are equally useless for TFTP, although TFTP does use unicast
UDP/IP.

Consider what a "file transfer" entails.  You must assume that some packets
will not make it from the source(s) to at least some of the destinations,
because that's the nature of networking.  You must have some kind of "error
recovery" or "retransmission" mechanism.  That is easy between a simple
pair of hosts, and has been done in various ways for 3 or 4 decades.  You
use some kind of ACK or NAK wherein the receiver tells the sender what
did or did not arrive, based on time and/or extra information in each
packet (analogous to the page number of a book).

The FTP sender and receiver rely upon the ACK's built into TCP/IP.  The
TFTP receiver does its own thing using timers.

Now consider the implications of multicasting.  It is not practical to
have every receiver tell the sender "I got packet #1234", because that
could entail too many ACKs for the receiver and/or the network to handle.
In a non-trival network, when one packet is does not make it to one
receiver, you have a good chance that it didn't make it to others as well,
and so you would like to arrange things so that only one "I didn't get
packet #543" message is sent to the sender, again to avoid loading the
network and the sender.  (If you're not careful, whatever ACK or NAK scheme
you use can be unstable, so that the system oscillates between moving data
and moving ACKs or NAKs).  You probably want to arrange things so that
the sender does not go faster than slowest receiver (and the links to that
receiver), since otherwise everything will be transmitted at least twice.
Since you cannot have an ACK from every receiver, you cannot compute the
RTT or do "slow start" or "congestion avoidance" on the sender for every
receiver, even if that would not be an intolerable burden for the sender
when it is sending to hundreds of receivers.

Depending on exactly what you are trying to do, including whether or not
you care if a few packets are lost now and then (e.g. "file transfer" vs.
"video conferencing"), whether it matters if some receiver misses most of
the packets, whether a receiver can join a multicast group after a lot of
data has been transmitted ("file transfer" vs. "video conference"), how
many receivers there are, what kinds of physical links in your network,
the nature of your routing protocol, and so on and so forth, these problems
have solutions of varying elegance.  The general solution is still a
research topic.

The quickest solution is probably a simple, manual hierarchy of rdist's
or rcp's.  A somewhat more elegant solution would be to use a flooding
algorithm like that in netnews--I would start with C news and use rcp as
the transport.  (NNTP is an incredibly bad botch of a protocol for moving
bits.)


Vernon Schryver    vjs@rhyolite.com

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 15:36:23 GMT
From:      catcim@eig.unige.ch
To:        comp.protocols.tcp-ip
Subject:   FTP server for Netware


Hi Netters,

Can we use a server from Netware (Novell 3.11) as an FTP server. What
additional software do we need ? We currently use Netware TCP/IP. 

We want to transfer files from a unix host to our Novell server....



Thanks for the answer

				Christiian ALT
				Engineering School Geneva
				phone +41 22 344 77 50
exit







-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 94 20:49:05
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <CLCF4t.1BI@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
   Still, your underlying point that FTP performance on large files is not
   very interesting is a good one.  I've seen more than a few organizations
   that use FTP to move multi-MB files among UNIX machines and "super
   computers" in production code, but I hope and believe they are a minority.
   The usual excuse for using FTP instead of something more appropriate is
   some form of "our mainframe can't do anything else."

I suspect you've hit it -- the simplest way to have a "client" access
data on a "server" is to have the server grind out a an appropriate
database-subset, and then download it to the client.  It would
certainly be easier to modify a humongous Cobol program to produce a
new file of output than it would be to turn it into a genuine server
capable of handling TCP or UDP transactions with many clients
simultaneously.  The idea of implementing a DNS name server on an MVS
mainframe causes my brain to seize up...

Unfortunately, what this implies is that in the huge corporations,
FTPing huge files is going to be the norm, even though it's not very
interesting.  And any sort of performance bottleneck will show up
severely, since the client will be down until the FTP is finished.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
"If you could have any amount of money... How much would you want?"
"All of it."
-- "Cerebus"

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 94 20:50:47
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Certain /etc/motd contents cause hang on rlogin -- sound familiar?

In article <2jufs7$18cd@osiris.giss.nasa.gov> syklb@osiris.giss.nasa.gov (Ken Bell) writes:
   Apparently, dependent on the contents of /etc/motd, this scenario works
   or hangs.  In particular, the following contents will cause a hang:


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

   Does anyone happen to recall such a problem?  I vaguely remember
   reading about a rather old gateway that ascribed significance to
   specific patterns of data, with similar results, but the reference
   escapes me.

I seem to remember that it was a bug (or perhaps a testing "feature")
that was triggered in a router by a packet that too many of some
particular character as the data portion.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
We Americans live in a nation where the medical-care system is
second to none in the world, unless you count maybe 25 or 30 little
scuzzball countries like Scotland that we could vaporize in seconds
if we felt like it.
-- Dave Barry

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 16:25:35 GMT
From:      adelman@tgv.com (Kenneth Adelman)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: TCP weirdness: 10MB msg beats 100KB msgs

In article <2jt842$6h6@poptart.cs.umd.edu>, mdtanx@cs.umd.edu (Michael D. Tan) writes...
>
>
>I have three Sparc2's which each attempt to send 10MB to a fourth
>machine (a Sparc10).  They are connected by 10Mb/s Ethernet.  The
>transfers are done using TCP/IP.  If each of the senders does a
>	write (sockfd, ptr, 10000000)
>
>all 10MB get written and the total transfer time (30MB) takes about 33
>seconds.  However, when each of the senders tries to send their 10MB
>in messages of 100KB, the code looks something like this:
>
>	for (i = 0; i < (10000000/100000); i++)
>		write(sockfd,ptr, 100000);
>
>This transfer (30MB (again)) consistently takes about 40 seconds.  I
>have runs these tests many times, with the same results.
>
>Does anyone know why this is happening?
>
>TCP_NODELAY *is* set...

    The the later case you're going to have instances where the amount
of data in the socket goes to zero and your program needs to be
scheduled and run to refill the socket before TCP can resume
transmitting.

    Odder yet I've observed the following interesting phenomenon
regarding TCP transmit speeds (using 4.3bsd-tahoe) -- sometimes
reducing the write size will INCREASE performance. Optimal value
seems to be doing 16KB writes into a 32KB window. If the write size
equals the window size, TCP's buffers will completely drain before
the process is scheduled to produce more data, resulting in idle
network time. If the write size is larger than the window size, then
this just happens less often. But if the write size is an integer
submultiple of the window size, the process is scheduled when TCP's
buffers are only 1/2 empty, and if the scheduling takes place fast
enough it will complete before TCP's buffers drain all the way resulting
in little to no idle time.

							    Ken

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 17:14:32 GMT
From:      pab@dsc.com (Phillip A. Brooker)
To:        comp.protocols.tcp-ip
Subject:   IP Aliasing

Does anyone know of any TCP/IP gateway implementations which can perform IP 
aliasing (address translation)?  Any information would be appreciated.

Phil

-- 

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 94 18:13:52 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: Uni-directional firewalls - why not?

In article <ptrubeyCLCx9x.6yG@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>I was just wondering why sites implement full IP firewalls for their
>Internet connectivity.  I know of many commercial sites which are
>content with more functional uni-directional firewalls.  I was wondering
>if there was a reason why people don't always implement these.
>
>Without going into a lot of detail, the basics of a uni-directional 
>firewall are:
>
>A Internet connected router that implements IP packet filtering which only 
>allows packets originating from the Internet to come in if those packets 
>have UDP or TCP port numbers greater than 1023. The firewall may also 
>allow packets destined for the SMTP and DNS ports to certain machines 
>as well.
>
>All packets originating from within the organization will be allowed out
>to the Internet.
>
>This scheme thus prevents any Internet host to communicate with any
>server within the organization. 

Including email, unless I happen to send email out to them first.


The real problem with this strategy, though, is that it assumes that
everyone has a trivial access policy.  In reality, things are more
complex (so what else is new?).

For example, suppose my organization has a router connected to the
Internet.  I may want to do other things with this router than just
shoveling bits to and from my T1.  I might want to hang the accounting
department on a separate ethernet so I can restrict access to the
financial databases (even tho we're all good employees of NSC here, I
have no need to know what my co-workers earn each year).

I may have more confidence in certain hosts with more robust security
measures, and want to allow them better access to the Internet.

I might want to allow unrestricted access to PARTS of the Internet, such
as wholy-owned subsidiaries (such as NSC's Vitalink unit).

This is just scratching the surface.  Now your mileage may indeed vary,
but there are a wealth of possibilities for you to implement.  I think
the problem up until reciently is that nobody has understood the
situation well enough to provide robust enough solutions.  That's
changing VERY rapidly now.

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 94 00:52:32
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

I don't know much of anything about APPC, but I thought I'd throw out the
following comment anyway:

A conforming, but slightly out-of-date TCP implementation (which probably
describes most PC TCP implementations) is likely to use a packet size of
576 bytes if it suspects the TCP connection might go through a router.

An IBM-like program on token ring is likely to use a packet size of about
8192 bytes or so, even if it "knows" the packets must go through a
Source-route bridge or two.

That distinction can account for a LOT of performance difference.  The
mainframe people ALWAYS want to use bigger packets, since the per-packet
overhead can be immense.  TCPs are not particularly supportive of such
desires, and PC TCP implementations in particular may use smaller packets
and windows in an attempt to save shared memory.

BillW


-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 20:37:34 GMT
From:      leroy@expert.cc.purdue.edu (Leroy)
To:        comp.protocols.tcp-ip
Subject:   How do I get Trumpet to work?

I just downloaded Trumpet, because I need it to run Cello.  So how
do I set up everything (ie. tcp-ip address, other pertinent info)

Thanks in advance.

						Jeff

-- 
*********************************************************************
* 			This space intentionally		    *	
*			  	left blank			    *
*********************************************************************

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 21:06:51 GMT
From:      alun@internet.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP server for Netware

In article <1994Feb17.173623.1@eig.unige.ch> catcim@eig.unige.ch writes:
>
>Hi Netters,
>
>Can we use a server from Netware (Novell 3.11) as an FTP server. What
>additional software do we need ? We currently use Netware TCP/IP. 
>
>We want to transfer files from a unix host to our Novell server....

We've been using the FTPSERV.NLM for some time now with great success.
I'm not sure, though, if it came with Netware TCP/IP, since I don't
have anything to do with its administration.

Alun.
~~~~

-- 
The above is a personal opinion, and may not necessarily represent the
opinions of Welcom Software Technology, its management, its staff, or
its Margarita machine.
======================================================================

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 21:26:58 GMT
From:      pab@dsc.com (Phillip A. Brooker)
To:        comp.protocols.tcp-ip
Subject:   TCP Routing


Does anyone know of a router which can route on TCP port number (either
source or destination)?

Phil

-- 

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 21:33:55 GMT
From:      nagamati@netcom.com (Romklau Nagamati)
To:        comp.protocols.tcp-ip
Subject:   Finding out destination address of a packet.

Does anyone know whether and how I can find out what is the destination
address of a UDP packet? Specificly, I want to know whether a packet I
got was sent to me by
	1.) Got it because it was addressed directly to me.
	2.) Got it because it was a broadcast packet.
	3.) Got it because I was a member of a Multicast-IP group.

How the packet get to me going to determine what I should do with it...
I could open a raw socket and process a packet myself but it's...

Could someone give me a pointer to any relevant references, please?
I'll appreciate any help.

Ron Nagamati
nagamati@netcom.com


-- 
     |o+------------------------+                                       |o|
     |o|  Ron Nagamati          |  Censorship:                          |o|
     |o|  nagamati@netcom.com   |  Art made tongue-tied by authority.   |o|
     |o+------------------------+               William Shakespeare     |o|

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1994 21:34:37 GMT
From:      brims@bnkl01.astro.ucla.edu (George Brims)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   FTP Software Inc - need phone #

Does anyone have a current phone #/address for FTP Software Inc, makers of 
PC/TCP? I need to buy a current copy of this software.


-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Feb 1994 23:18:29 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and multicasting questions

In article <BAB.94Feb17084442@se40.wg2.waii.com> bab@wg2.waii.com (Brian Button) writes:
>I'm playing around with using multicasting facilities on Solaris 2.3
>for my current project, and I have some conceptual questions about it.
>
>Can someone point me to a magazine, book, or resource of some type
>where I can learn about multicasting? 

I believe there is a FAQ about this at ISI.  You might ftp to isi.edu
and see if it is lying around there.  It might be in a directory named
"mbone" but I'm not sure off hand.

Ran



-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 00:08:24 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding out destination address of a packet.

> Does anyone know whether and how I can find out what is the destination
> address of a UDP packet? Specificly, I want to know whether a packet I
> got was sent to me by
> 	1.) Got it because it was addressed directly to me.
> 	2.) Got it because it was a broadcast packet.
> 	3.) Got it because I was a member of a Multicast-IP group.
> 
> How the packet get to me going to determine what I should do with it...
> I could open a raw socket and process a packet myself but it's...

4.3BSD Reno and above do provide this capability.  You must use
recvmsg() to read the datagram, and you must have set the socket
option IP_RECVDSTADDR.  The destination address is returned as
"control data" through the msg_control pointer in the msghdr
structure.  Of course, once you have the destination IP address
from the datagram, determining whether it's a broadcast address
is non-trivial ... but all versions of tftpd should use this :-)

I've seen a few vendor systems that provide this feature: AIX 3.2
and OSF/1.  There may well be others?

	Rich Stevens

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1994 01:01:15 GMT
From:      piggy@hilbert.maths.utas.edu.au (La Monte Yarroll)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: HELP! Sending e-mail to an IP address.

I wrote:
>Are you sure that the IP address is not properly entered in the DNS?
>Here are reverse lookups for every IP address mentioned in your article:
 160.6.5.1
>160.6.5.1	dunksink.dunksink.dias.ie
...

It seems there was a slight problem with cut/paste :-).  The correct
hostname is:

Name: dunsink.dunsink.dias.ie
Address: 160.6.5.1
Aliases:

(Thanks to Ric Nauen...)
--
La Monte H. Yarroll	Home:		piggy@baqaqi.chi.il.us
   Work:		piggy@hilbert.maths.utas.edu.au
   If you remember nothing else:  piggy@acm.org		NIC Handle: LY
   GPL - "Just give source a chance."

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 01:58:08 GMT
From:      al012@un.seqeb.gov.au ( ANTHONY LEE)
To:        comp.protocols.tcp-ip
Subject:   Telnet's protocol treatment of <CR> <NU>


Recently, I have to develop an application which connects to a
special TCP/IP port on my workstation.  What I notice was that
everytime I have a <CR> character, the workstation (an DECstation
5000/33) would insert a <NU> if the <CR> was not followed by a
<LF>.  I did the test in 8 bit mode.  I notice that when I am using
the program between two workstations then the receiving station would
removed the <NU> before passing the data to the applications.
I like to know which RFCs I can find out more about this.  It doesn't
make sense to me why the <NU> is inserted.  This <NU> causes a problem
to my application.

Any help appreciated.

Anthony
-- 
Anthony Lee				These are my opinions and not SEQEB.
SEQEB					
150 Charlotte Street			
Brisbane

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1994 02:27:13 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: How to watch the traffic flow on FDDI ?

In article <2juq46$hh4@news.csie.nctu.edu.tw> edward@e0sun29.ccl.itri.org.tw (Chao-Chi Yang 37h3100) writes:
>      How can I check if any traffic flow on NP-FDDI ?  Where
>  can I find any network utilities like 'etherfind' or
>  'nfswatch' that can display network status on a specific
>  FDDI LAN ?

"tcpdump" will do it (at least, in more recent versions).  ULTRIX
and OSF/1 (at least, in version 2.0, about to ship to customers)
provide tcpdump along with the operating system.  I don't know if
tcpdump can handle FDDI LANs on other operating systems, but I'm
sure it's not much work to port the publicly-available source code.

-Jeff

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1994 02:31:29 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Traffic

In article <2junmq$hr0@ibridge.iohk.com> samson@iohk.com (Samson Luk) writes:
>Is there such a utility for collecting ip traffic passing through a certain
>ip hosts?
>
>netstat only report the no. of packets passing through a particular route
>but what I need is no. of bytes instead of packets.

You might find that NNstat, a network statistics monitoring package,
will do what you want.  The latest version is available from
	gatekeeper.dec.com:pub/DEC/net/NNStat_3.3beta.tar.Z

-Jeff

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1994 15:55:41 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <CLFGvK.3zB@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>Why bother?  That article was written by someone who tried to make real
>measurements, and (as I recalled) only claimed to be a "user."
>
   Not to mention that Kevin Tolly is a well-known "SNA is GOD" bigot
   anyway.
    
   Worse he did have a point, elsewhere than on top of his head.  LU
   6.2 is a slightly "thinner" protocol stack in terms of complexity
   compared to tcp/ip.  This doesn't mean that token ring tcp/ip 
   developers ALL aren't tuning their implementation, but it is easier
   from the implementations I've seen to get faster BULK one-way
   thruput over a simple LU 6.2 session.         

   In fact, if the hardware and operating system were both "perfect",
   APPC would be faster simply due to the shorter length of the
   FID-2 header compared to the much greater length of the tcp and ip
   headers.  

   Not that this theoretical perfect system has anything to do with a
   practical implementation in the slightest.



-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 94 04:55:48 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Timed out NFS hangs ls

In article <2jru2n$7bn@crl2.crl.com> cgi@crl.com (Paul Smith) writes:
>Have a NFS problem:
>
>I've noticed on several occastions the following problems in a multi-machine
>(Intel UnixWare SVR4.2v1.0 and DEC Alpha OSF1) where file systems from
>many boxes are cross mounted every which way where if one box goes down
>and you ls the directory that contains the mount point or do a df or
>dfspace that these local box filesystem operations HANG forever waiting
>on presumably the NFS client to return the requested info.  Well WHY
>doesn't the local NFS client figure out/time out and return "no-got-info"
>to the local file system manager??  Instead the user's command hangs??
>
>This is also true on the OSF1v1.3 box.  
>
>This morning was funny/agravating; as one would construct a house of cards,
>I put other machines local script bin dirs in the $PATH of several machines. 
>This hangs running any exe that is found after the down machines' bins.
>Another screw up was putting the following at the end of /etc/profile:
>".   /another_machine/.../script"  to import project environment variables
>into the local machine's login environ.  Even a if [ -r /another_mahine... ]
>would hang..
>
>Is this totally broke, or is this the wonderful world of NFS the stateless
>wonder??
>
>Thanks

The hang is a feature, not a bug! :)
Use the soft option to mount, and it will report connection timed out.
E.g. mount -o soft host:/nfs/dir /mnt
           ^^^^^^^ use this to enable "soft" nfs mounts, ie. time out 
instead of hang.
If it is the uninterruptible nature of the hang that bothers you, using intr 
instead of soft will make it wait, but signals can stop the process.
Probably the soft option is what you are looking for though, judging from 
your post.


-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 10:25:56
From:      timmi@ftp.com  (Kitchen Staff Supervisor)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: FTP Software Inc - need phone #

$Does anyone have a current phone #/address for FTP Software Inc, makers of 
$PC/TCP? I need to buy a current copy of this software.

For sales you can either send email to SALES@FTP.COM or call 
(508) 659-4000.   Our fulle address is in the .sig.
--
Timothy G. Reynolds					FTP Software, Inc.
Technical Services					2 High St.
timmi+email@ftp.com					N. Andover, MA
(800) 382-4FTP							01845

		"When are you gonna make up your mind?


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 06:16:29 GMT
From:      ibottema@sce.carleton.ca (Ike Bottema)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and multicasting questions

bab@wg2.waii.com (Brian Button) writes:

>I'm playing around with using multicasting facilities on Solaris 2.3
>for my current project, and I have some conceptual questions about it.
 
>Can someone point me to a magazine, book, or resource of some type
>where I can learn about multicasting? I've looked in Stevens' first
>and second books, and there is not much in there about actually using
>multicasting, and those are about the only resources we have available
>here.

Try files /rfc/rfc1112.txt (The host part) and /rfc/rfc1075.txt (The router
part) at ds.internic.net.  There are other sources, but that's where I get my
RFCs.  

I'm looking at a multicast application myself.  Does anyone know what the 
present state of affairs is in regards to RFC1075 implementation?  I'm not
sure how universally applicable a multicast solution would be at this point
in time.

Ike Bottema


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 13:58:03
From:      timmi@ftp.com  (Kitchen Staff Supervisor)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Correction to FTP Software's Phone number

Boy, is my face red!  I incorrectly posted the phone number for
Hewlett Packard as being FTP's phone number.  FTP can be reached at
(508) 685-4000, *not* 659-4000
--
Timothy G. Reynolds					FTP Software, Inc.
Technical Services					2 High St.
timmi+email@ftp.com					N. Andover, MA
(800) 382-4FTP							01845

		"When are you gonna make up your mind?


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1994 13:11:33 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

In article <CLEDGx.H9C@un.seqeb.gov.au>, al012@un.seqeb.gov.au ( ANTHONY LEE) writes:
|> 
|> Recently, I have to develop an application which connects to a
|> special TCP/IP port on my workstation.  What I notice was that
|> everytime I have a <CR> character, the workstation (an DECstation
|> 5000/33) would insert a <NU> if the <CR> was not followed by a
|> <LF>.  I did the test in 8 bit mode.  I notice that when I am using
|> the program between two workstations then the receiving station would
|> removed the <NU> before passing the data to the applications.
|> I like to know which RFCs I can find out more about this.  It doesn't
|> make sense to me why the <NU> is inserted.  This <NU> causes a problem
|> to my application.

If you're seeing <NUL> after <CR> in TELNET, you're not in 8 bit mode.
See RFC 856.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 94 19:25:29 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

In article <CLEDGx.H9C@un.seqeb.gov.au>, al012@un.seqeb.gov.au ( ANTHONY LEE) writes:
> 
> Recently, I have to develop an application which connects to a
> special TCP/IP port on my workstation.  What I notice was that
> everytime I have a <CR> character, the workstation (an DECstation
> 5000/33) would insert a <NU> if the <CR> was not followed by a
> <LF>.  I did the test in 8 bit mode.  I notice that when I am using
> the program between two workstations then the receiving station would
> removed the <NU> before passing the data to the applications.
> I like to know which RFCs I can find out more about this.  It doesn't
> make sense to me why the <NU> is inserted.  This <NU> causes a problem
> to my application.
> 
> Any help appreciated.
> 
> Anthony
> -- 
> Anthony Lee				These are my opinions and not SEQEB.
> SEQEB					
> 150 Charlotte Street			
> Brisbane
--------------------
	You are looking at the byte stream of a Network Virtual Terminal, NVT,
as used in Telnet. The behavior may be wasteful and slightly peculiar now,
but that's the way the RFCs are written. Please see prime Telnet RFC 854
for the details, and dozens of others which go on to deal with Telnet Options
after Options after... The rule is CR -> CR NULL except CR LF -> CR LF
on the wire, and destuff the NULL upon reception. I hate to suggest this,
but if you are really dealing with a Telnet front end on the other side
then you probably need to engage in that Options stuff too; I wish you lots 
of luck with that chore.
        Joe D.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 14:53:52 GMT
From:      jwl@jlumley.hpl.hp.com (John Lumley)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.sys.isis
Subject:   Withdrawal of the unsupported IP multicast HP-UX 9.01 distribution

Because of concerns for the support consequences of the recent release of
experimental IP multicast extensions of HP-UX 9.01, we are withdrawing this
unsupported version from further general (anon ftp) distribution.

If you would like access to this *unsupported and experimental* release,
primarily intended for support of MBONE work, please contact John Lumley
<jwl@hplb.hpl.hp.com> with a brief note of why you need it and simple details of
the configurations you expect to run it on. We'll then advise you of any
difficulties we might expect and arrange for an ftp access for you to get the
distribution. We ask that you do not pass this distribution on further.

By doing this we'll be able to get a better idea of demand and problems, as well
as give you some directed indication if new versions are made available.

This release is for HP-UX 9.01 only and has been tried only on Ethernet. There
are indications that it doesn't work with FDDI and may have problems on
clusters. To re-emphasise, it is an experimental and completely unsupported
release: machines which run under its kernel are in a completely unsupported
state.

John Lumley
------------------------------------------------------------------
John Lumley                      | Network Technology Dept.
Hewlett-Packard Laboratories     | Phone:  +44 272 228743
Filton Road, Stoke Gifford       | E-mail: jwl@hplb.hpl.hp.com
BRISTOL BS12 6QZ                 | Fax:    +44 272 228924
U.K.                             | Telnet: 312 8743

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1994 15:15:15 GMT
From:      ace@reality-tech.com (Anthony Scandurra)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: FTP Software Inc - need phone #

The phone number is (508)685-4000. Sorry, I don't know what their
toll-free number is offhand.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 15:43:29 GMT
From:      rcw@netrix.com (Ralph C. Wolman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on X.25 efficiency

In article <CL0Foo.514@capvolmac.nl> cv1540@capvolmac.nl (Martin Tirion) writes:

>Hi,
 
>I am looking for people with experience in using TCP/IP on top of X.25. We are
>thinking of implementing this but we would like to exchange some thoughts with
>people who have actually seen this work and have done measurements on
>performance. We have tried to do a benchmark and it seemed as if a FTP of a 
>small file (around 4 kbytes) took TWICE ! as many packets as when bare X.25 was 
>used. This got less worse when the files grew larger but the number of packets 
>was still considerably larger in comparison to bare X.25. Since we are paying 
>per (fixed size) packet this is not a nice thing to have.
 
>With this experience in mind we would like to do some more tests, but we would 
>like to hear some results from others as well. Is this phenomenon in line with 
>what others see or have we done something wrong completely wrong here ? What 
>about TCP/IP header-compression, is that possible and does it help ?
 
>I can't give any specifics about the used software and hardware because I don't 
>have them. I am more interested to find out whether this is a general aspect of 
>putting TCP/IP on X.25. If it is not we can just get some good hard- & software, 
>right ?
 
>Thanks in advance for any information you can share with me.
>______
>Tom van Peer
>Cap Volmac BV, Utrecht, The Netherlands
>tom@capvolmac.nl

Tom,

Some of the overhead can be removed by specifying X.25 packet sizes
that work well with the IP datagram size.  Since a host is supposed
to support  a datagram size of 576 octets (see RFC 1122), an X.25
packet size that is a bit larger to account for X.25 overhead should
make the implementation more efficient. Also, if you can get the X.25
network to support larger packet sizes (say 1024), you could make your
datagram sizes larger and reduce overhead that way.

In addition, the ability to turn off remote ack (from the X.25 point
of view - I think this is called the 'D' bit) is important since TCP
is a reliable transport and doesn't need X.25 to do end-to-end
acknowledgement.

In my years of working on a TCP/IP over X.25 product, I found that FTP
transfers were about as fast as I find today on TCP/IP over frame relay
at the same speeds.  Using X.25 (without remote ack) should not add that
much overhead versus other protocols.

Regards,
Ralph Wolman

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 16:09:20 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <94049.094446HANK@vm.biu.ac.il> Hank Nussbacher <HANK@vm.biu.ac.il> writes:
>After I read the article I sent the following letter to the editor.
>....

Why bother?  That article was written by someone who tried to make real
measurements, and (as I recalled) only claimed to be a "user."

If you want to get irritated, look at the drivel in this week's issue
where the "Comminicatios Week" house expert pontificates at length about
things he obviously does not understand.  Read his nonsense about RPC's
and NFS.  Try to laugh at his concerns about "modifying user-written
applications to communicate using an RPC over TCP/IP." There is also his
complete confusion about PPP and SLIP.

I think he's the same clue-less guru who less than a year ago wrote that
you cannot fetch UNIX from a "bulletin board."  (I trust everyone reading
this knows about 386BSD, NetBSD, FreeBSD, and Linux.)

What puzzles me is why any any vendor of TCP code would take the risk of
of responding to the usual market survey form that I imagine was the basis
for the big table.  On the other hand, the entries in the table look as
if they were taken verbatum from such survey responses, so maybe the risk
was only that the marketeer would fill out the survey wrong.


Vernon Schryver    vjs@rhyolite.com

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 18:15:50 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and multicasting questions

In article <ibottema.761552189@genesis.sce.carleton.ca> ibottema@sce.carleton.ca (Ike Bottema) writes:

>I'm looking at a multicast application myself.  Does anyone know what the 
>present state of affairs is in regards to RFC1075 implementation?  I'm not
>sure how universally applicable a multicast solution would be at this point
>in time.
>
>Ike Bottema

The current DVMRP implementations do not conform to the RFC.  THere is
free DVMRP code, in the form of mrouted(8), available by anonymous
ftp from gregorio.stanford.edu:pub/vmtp-ip

Ran
atkinson@itd.nrl.navy.mil




-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 21:26:07 GMT
From:      szeliga@fluke.forestry.umn.edu (Tim Szeliga - NWS)
To:        comp.protocols.tcp-ip
Subject:   CIDR Addresses instead of Class C


Instead of subnetting our exisiting Class C address, our internet provider
suggested using CIDR (Classless Inter-Domain Routing) numbers.  We turn in
our 192.46.108 and get in return 199.86.20 - 199.86.23, four new networks.
Seems like a good idea on the surface, but are there any drawbacks?  
All we do here is TCP/IP, ftp, telnet, gopher and such, nothing too extreme.
Will any programs fail because of the high address numbers?  Are there
any horror stories I should know?  Is this even the proper newsgroup for this
question?  Worst of all, is this a FAQ?

Tim Szeliga
tim@snow.nohrsc.nws.gov

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Feb 1994 00:05:03 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Timed out NFS hangs ls

In article <1994Feb18.045548.24955@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>In article <2jru2n$7bn@crl2.crl.com> cgi@crl.com (Paul Smith) writes:
>>I've noticed on several occastions the following problems in a multi-machine
>>(Intel UnixWare SVR4.2v1.0 and DEC Alpha OSF1) where file systems from
>>many boxes are cross mounted every which way where if one box goes down
>>and you ls the directory that contains the mount point or do a df or
>>dfspace that these local box filesystem operations HANG forever waiting
>>on presumably the NFS client to return the requested info. ...
 
>The hang is a feature, not a bug! :)

Not to beat a dead horse, but the good humor suggested by that ":)"
should not involve any sarcasm.  Too many, probably most applications
do not recover gracefully from disk errors.  What should the system
normally do, for example, when an editor asks to read or write the
second half of a file and the NFS server is not responding?  The
operating system (and NFS) could just say "sorry" and let the editor
go off into the weeds or loose that data.  Or the system could
wait until the dead server comes back.  You can choose either with NFS.
(Yes, I realize that with client caching, the application will have long
since gone away and not know its data is being lost if with a soft-mount.)

There is another point about unnecessary hang ups with dead servers.  They
can be radically reduced by:
    1. never NFS mount anything directly in /
    2. use an automounter

(1) prevents the most common causes of hiccups, which are caused by various
and surprisingly common uses of the algorithm of `cwd`.

(2) prevents those hiccups and more by not having file system mounted
except when they are actually needed.


Vernon Schryver    vjs@rhyolite.com

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1994 14:27:58 -0800
From:      jahansen@halcyon.com (john a hansen)
To:        comp.protocols.tcp-ip
Subject:   TECH REPORTS AVAILABLE


Re: Tech report availability
Networks Northwes Inc. is pleased to announce the availibility
of two reports that will be of interest to people involved
in providing data communication links between remote location
and a central site, remote clinics,and between offices to
a diagnostics center. The data communication can be 
Billings, medical records, images,or as simple as e-mail.
The reports are
 A: Remote bridging and routing: wide area networking considerations
    Author is Mike Drollman manager application engineering. The 
    40 page report provides an overview of the comparison between
    bridging vs routing and some specific application and
    engineering considerations for each alternative. Specifics
    of various protocols are itemized and problems unique to
    each of the prevailing WAN protocols are discussed (TCP/IP)
     techIPX, LAT, SNA, etc). The paper is primarily discussing 
    ethernet LANS but most of the application information
    also applies to token ring.
B:  General Description of Dial-up Internetworking:
    This is copies of a slide presention used at seminars
    to give a graphical description of Internetworking
    functions as it applies to Dial-Up Data communucations
    over a WAN. Author is Tom Plaster, product marketing
    manager. There is some product information on the
    BREEZE product line in the material.

 C: Technical brochures are available on the 
    BREEZE 1000 a integrated dial-up bridge/router with modem (v.32bis or vfast)
    BREEZE 1100 a bridge/router for rs232 to CSU,Frame relay, SW56, etc.
    BREEZE 2000 a bridge/router 2ports with integrated modem
    BREEZE 2100 a bridge/router 2 ports for sync/async on either port 

Anyone interested in any or all of this information can reach me at
jhansen@networksnw.com
or
1-206-641-8779  tel
1-206-641-8909  fax
1-800-835-9462  tel

or smail
John A Hansen
Director OEM
Networks Northwest Inc.
po Box 40209
Bellevue Wa 98015

Please note: The above information will be sent and 
will not be followed up by our marketing staff
unless you request "follow" in your request to us.
We are trying to be sensitive to the commercialization
of the Internet and not to bother those of you that
only want the info and nothing else.
Best Regards
John A Hansen
ZZ


-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Feb 1994 11:08:42 -0600
From:      sims@sndsn1.sedalia.sinet.slb.com (David Sims)
To:        comp.protocols.tcp-ip
Subject:   Anyone know a TN5250 client for PC or Mac ???

Does anyone know of a robust TN 5250 client for PC or Mac ?? Can a TN 3270
client be used with a re-mapped keyboard ?? If so, has anyone done this
for a PC-TCP client for DOS/Windows or a Brown University TN3270 client
for Macintosh ?? Any help would be most welcome. 

*************************************************************************
David Sims                         *   sims@sugar-land.sinet.slb.com
Schlumberger Information Network   *   Telephone:     1-713-275-7792
%Schlumberger Limited              *   Fax:           1-713-240-7204
205 Industrial Boulevard           *      
Sugar Land, Texas  77478           *        
USA                                *
************************************************************************

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Feb 1994 01:17:18 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.sys.isis
Subject:   Re: Withdrawal of the unsupported IP multicast HP-UX 9.01 distribution

In article <CLFDDs.Dys@hplb.hpl.hp.com> jwl@jlumley.hpl.hp.com (John Lumley) writes:
>Because of concerns for the support consequences of the recent release of
>experimental IP multicast extensions of HP-UX 9.01, we are withdrawing this
>unsupported version from further general (anon ftp) distribution.

Pity this.  I can now guarantee that I will NOT be purchasing an HP
system anytime soon.  Vendors that are this paranoid about "support
consequences" clearly do not want my business.

One of the reasons I have bought Sun in the past is that they give
away lots of unsupported software without HP-like paranoia about
support.  Sounds like Sun will continue to be the better choice in
future.

Ran
atkinson@itd.nrl.navy.mil



-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1994 05:34:30 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_REUSEADDR and listeners

In article <CLCAzp.MqF@well.sf.ca.us> jime@well.sf.ca.us (Jim Eberle) writes:
>    In order to restart a listener at a given port, I'm doing a setsockopt
>    SO_REUSEADDR before the bind().
 ...
>    I'm suprised and concerned that this step is not covered in any of the
>    literature I've come across. 

Have you read "Unix Network Programming"?  I'm not at my office so I can't
verify, but I'd be surprised if it doesn't cover this.

>    In the collective Internet mind, is this an acceptable and safe
>    technique?

It's the standard technique.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1994 05:41:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How to watch the traffic flow on FDDI ?

In article <2k1921$mid@usenet.pa.dec.com> mogul@pa.dec.com (Jeffrey Mogul) writes:
>"tcpdump" will do it (at least, in more recent versions).  ULTRIX
>and OSF/1 (at least, in version 2.0, about to ship to customers)
>provide tcpdump along with the operating system.  I don't know if
>tcpdump can handle FDDI LANs on other operating systems, but I'm
>sure it's not much work to port the publicly-available source code.

It works fine for us under SunOS 4.1.x.

And since tcpdump just uses /dev/nit, I would expect any other NIT-based
tools, such as etherfind and nfswatch, to work just as well.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Feb 1994 12:02:28
From:      fks@ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: FTP Software Inc - need phone #


In article <2k0ntd$s1m@news.mic.ucla.edu> brims@bnkl01.astro.ucla.edu (George Brims) writes:

> Does anyone have a current phone #/address for FTP Software Inc, makers of 
> PC/TCP? I need to buy a current copy of this software.


FTP sales   - info@ftp.com	(508) 685-4000	 (800) 282-4287       
FTP support - support@ftp.com	(508) 685-3600   (800) 382-4387

Both departments are open 8 AM - 8 PM, Eastern Time.


--
Frances K. Selkirk                                        fks@ftp.com
FTP Software, Inc.        Technical Support            (800) 382-4FTP
---------------------------------------------------------------------
Get our support newsletter from       | FTP support - support@ftp.com
ftp.ftp.com or our BBS (508-659-6240) | FTP sales   - info@ftp.com



-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Feb 1994 15:19:00 +1000
From:      Russell.Coker@f363.n633.z3.fidonet.org (Russell Coker)
To:        comp.protocols.tcp-ip
Subject:   Ftp List Specification P

jasonh>I'm glad someone brought this up - recently I've been thinking
jasonh>that the FTP protocol looks well overdue for an overhaul.

   I agree.

jasonh>There are number of "extensions" out there now - ones that
jasonh>allow you to tar and/or compress files on the server before
jasonh>transferring them, as well as things like BinHexing Macintosh
jasonh>files before sending. The format of the LIST command is just
jasonh>the tip of the iceberg...

   Are we talking about the FTP protocol or just implementations of
it?  I think that the current way of transferring TAR files etc is
fine, and there is no need to change the protocol.

jasonh>I find all of these extensions rather useful - but they're just
jasonh>not part of the standard.

   The problem is that some systems can't support these.  Could you
imagine a DOS box dynamically creating a .tar.gz file?

jasonh>Are there any plans afoot to rewrite FTP away from this
jasonh>Unix-centric world to one that's more generic? (e.g. systems
jasonh>like VAX/VMS and Macs have more than one data 'fork' - so how
jasonh>do you transfer two streams at once). It may be that the
jasonh>majority of ftp servers on the Internet are Unix - but the
jasonh>majority of _clients_ aren't... 

   That sounds like a good idea.  Some further possibilities are:
support for transferring time-stamps on files and support for
transferring OS/2 EAs (why stick at just the resource fork of Mac
system?).

  cya
___
 * MR/2 1.57 NR * Windows NT: Vapourware of the desperate and scared.

 * Origin: Multi - 61-3-739-7145 (3:633/363)

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1994 08:09:01 GMT
From:      weng@leland.Stanford.EDU (Chi-Cheong Weng)
To:        comp.protocols.tcp-ip
Subject:   What is TCP/IP - NFS ?

What is TCP/IP NFS ? How does it differeniate from TCP/IP ?

Please email to weng@leland.stanford.edu


-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1994 15:03:14 GMT
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: How to administer IP address space? Database/spreadsheet/?

In article <2jaru5$o12$1@sdl.Warren.MENTORG.COM>, tal@Warren.MENTORG.COM (Tom Limoncelli) writes:
>Many sites do the following:
>1.  Have one master text file (maintained under SCCS or RCS) that
>lists ip address, hostname, aliases, and comments.  After
>editing this file, "make" runs some perl scripts that generate
>the DNS tables, bootptab, etc.  All automaticly.

An excellent tool (at least for the DNS file) is the one described in the
book "DNS and BIND" by Cricket Liu & Paul Albitz (O'Reilly, 1st Edition 
October 1992 418 pages, ISBN: 1-56592-010-4, $29.95, see 
http://nearnet.gnn.com/mkt/ora/catalog/dns.desc.html for details).

It translates an /etc/hosts file in BIND data file, taking care of the PTR
records, creating CNAME for all the names on the same line, etc.
This tool, h2n, is available in ftp.ora.com, like all other software described
in O'Reilly books.

For the IP<->Ethernet mapping, I recommend to use a tool which records 
them automatically. At least in an academic site like mine, it's too much
to expect the users/departemental admins to keep this information up to
date and to transmit it! I wrote such a tool (quite buggy and not well
supported, I admit), using SNMP, which records the ARP tables of main servers 
and routers. If you have a Web client, see:

http://web.cnam.fr/personnes/bortzmeyer/record_ARP_README.html

Otherwise, use ftp:

ftp://ftp.cnam.fr/pub/CNAM/MISC/record_arp.tar.Z

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers
bortzmeyer@cnam.cnam.fr       Laboratoire d'Informatique
                              292, rue Saint-Martin
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand
  

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Feb 1994 22:40:11 GMT
From:      davidmar@cuug.ab.ca (David Martin 233-9333)
To:        comp.protocols.tcp-ip
Subject:   tcpip

Recently I have been developing TCP/IP applications using BSD sockets

under Solaris 1.1 (SunOS 4.1.3).  I have no trouble connecting my clients

to my server, but my server seems unable to determine when my clients
disconnect (i.e. close()).  Some clients run on PC's under MS Windows while

others run on my SPARCstation II clone -- the server fails to "see" a
disconnect from any of them.



I thought that I would get an appropriate value for 'errno' or 'so_errno'

after a read() or recv() or perhaps a SIGURG signal, but I don't.


I would appreciate hearing from someone who could solve this problem.



-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 1994 03:59:47 GMT
From:      samson@iohk.com (Samson Luk)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Traffic

Jeffrey Mogul (mogul@pa.dec.com) wrote:
: >Is there such a utility for collecting ip traffic passing through a certain
: >ip hosts?
: >
: >netstat only report the no. of packets passing through a particular route
: >but what I need is no. of bytes instead of packets.
 
: You might find that NNstat, a network statistics monitoring package,
: will do what you want.  The latest version is available from
: 	gatekeeper.dec.com:pub/DEC/net/NNStat_3.3beta.tar.Z

Jeffrey,

I don't have DEC OSF/1 or Ultrix... I have FreeBSD and a SVR4 (Esix v4.0.4), 
do you think I can use NNStat under these boxes?

Regards
Samson Luk


-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Feb 1994 19:06:14 GMT
From:      msains@sunbird.ru.ac.za (Malcolm Sainsbury)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Source code from W Richard Stevens' book

Is the published source of the examples in W.Richard Stevens book "Unix 
Network Programming" available at any ftp site.  I would like to try out his 
examples but dont have the heart (or fingers) to type them all in.

Regards

Malcolm

--
Malcolm Sainsbury - Dept of Information Systems - Rhodes University
Internet: msains@sunbird.ru.ac.za               Phone: +27 [0]461 22023 xt 244
    uucp: ..!uunet!m2xenix!kudu!sunbird!msains    Fax: +27 [0]461 25049

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 1994 21:16:10 GMT
From:      ahh@cisco.com (Andy Heffernan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Source code from W Richard Stevens' book

In article <msains.286.2D67B4A5@sunbird.ru.ac.za> msains@sunbird.ru.ac.za (Malcolm Sainsbury) writes:
>Is the published source of the examples in W.Richard Stevens book "Unix 
>Network Programming" available at any ftp site.  I would like to try out his 
>examples but dont have the heart (or fingers) to type them all in.

ftp.uu.net
published/books/stevens.netprog.tar.Z

There's other stuff in that directory that you (and others) might be
interested in as well.

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Feb 1994 22:48:41 GMT
From:      al012@un.seqeb.gov.au ( ANTHONY LEE)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>


Joe Doupnik (jrd@cc.usu.edu) wrote:

: 	You are looking at the byte stream of a Network Virtual Terminal, NVT,
: as used in Telnet. The behavior may be wasteful and slightly peculiar now,
: but that's the way the RFCs are written. Please see prime Telnet RFC 854
: for the details, and dozens of others which go on to deal with Telnet Options
: after Options after... The rule is CR -> CR NULL except CR LF -> CR LF
: on the wire, and destuff the NULL upon reception. I hate to suggest this,
: but if you are really dealing with a Telnet front end on the other side
: then you probably need to engage in that Options stuff too; I wish you lots 
: of luck with that chore.
:         Joe D.


Sorry Joe, but I can't see this in my copy of RFC854.  There is section
5 on the IAC character (255) but nothing on CR translation.
-- 
Anthony Lee				These are my opinions and not SEQEB.
SEQEB					
150 Charlotte Street			
Brisbane

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1994 01:47:34 GMT
From:      heathh@cco.caltech.edu (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

al012@un.seqeb.gov.au ( ANTHONY LEE) writes:

>Joe Doupnik (jrd@cc.usu.edu) wrote:
 
>: [Telnet RFC 854 specifies CR -> CR NULL mapping.]


>Sorry Joe, but I can't see this in my copy of RFC854.  There is section
>5 on the IAC character (255) but nothing on CR translation.

Time to read it again.  If it's not in 854 it's in one of the related RFCs
on telnet.  (NVT is not particularly cleanly documented.)  Whatever you
do, don't get the idea that it is ok to send single <CR>s in the NVT data
stream.  So many clients cause major compatibility problems due to this
stupid bug, it is simply amazing.

At my site, we have a custom telnetd to distribute remote users over a 
cluster.  Because of the bugs in NCSA telnet for the Mac, and WinQVT/Net
for Windows, the daemon can be hacked so that only one or the other of
these two work.  WinQVT/Net drops the NULL from CR NULL, and NCSA does
something else that is equally wrong.  We can't be compatibile with
both of them, so we're not.  If only people would read RFCs before they
decide they know how to write TCP/IP applications.

Heath


-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 94 06:57:21
From:      maguire@tristan.electrum.kth.se (Gerald Maguire)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

See if RFC is just what you want:

@Techreport[Ioannidis91a,
	Key=<Ioannidis>,
	Author=<J. Ioannidis and G. Q. Maguire Jr.>,
	Fullauthor=<John Ioannidis and Gerald Q. Maguire Jr.>,
	Title=<The Coherent File Distribution Protocol>,
	Institution=<Network Working Group>,
	Year=<1991>,
        Month=<June>,
	Number=<RFC 1235>,
	comment=<based on earlier Columbia University technical report
		 CUCS-043-90>
]

We used it to send (via radio) a Unix kernel and inital file system to
a whole set of machines which all wanted to boot.

Chip


-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1994 03:07:21 GMT
From:      COATES@UMUC.UMD.EDU (Ellster)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet - Where?

Where can I ftp the NCSA Telnet server PD program.  Please e-mail direct,
TIA.

 ----------------------------------------------------------------------- 
 |                            Elliott Coates                           | 
 |            coates@umuc.umd.edu        coates@umuc.bitnet	       |
 |                            washingtoon, dc                          |
 -----------------------------------------------------------------------

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 94 09:24:10 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

In article <CLJop6.7oH@un.seqeb.gov.au>, al012@un.seqeb.gov.au ( ANTHONY LEE) writes:
> 
> Joe Doupnik (jrd@cc.usu.edu) wrote:
> 
> : 	You are looking at the byte stream of a Network Virtual Terminal, NVT,
> : as used in Telnet. The behavior may be wasteful and slightly peculiar now,
> : but that's the way the RFCs are written. Please see prime Telnet RFC 854
> : for the details, and dozens of others which go on to deal with Telnet Options
> : after Options after... The rule is CR -> CR NULL except CR LF -> CR LF
> : on the wire, and destuff the NULL upon reception. I hate to suggest this,
> : but if you are really dealing with a Telnet front end on the other side
> : then you probably need to engage in that Options stuff too; I wish you lots 
> : of luck with that chore.
> :         Joe D.
> 
> 
> Sorry Joe, but I can't see this in my copy of RFC854.  There is section
> 5 on the IAC character (255) but nothing on CR translation.
> -- 
> Anthony Lee				These are my opinions and not SEQEB.
> SEQEB					
> 150 Charlotte Street			
> Brisbane
-----------
Anthony,
	Here's the rather long excerpt on the matter from RFC854. I
hope it helps clarify the murky waters (and Telnet is nearly opaque).
	Joe D.

      The sequence "CR LF", as defined, will cause the NVT to be
      positioned at the left margin of the next print line (as would,
      for example, the sequence "LF CR").  However, many systems and
      terminals do not treat CR and LF independently, and will have to
      go to some effort to simulate their effect.  (For example, some
      terminals do not have a CR independent of the LF, but on such
      terminals it may be possible to simulate a CR by backspacing.)
      Therefore, the sequence "CR LF" must be treated as a single "new
      line" character and used whenever their combined action is
      intended; the sequence "CR NUL" must be used where a carriage
      return alone is actually desired; and the CR character must be
      avoided in other contexts.  This rule gives assurance to systems
      which must decide whether to perform a "new line" function or a
      multiple-backspace that the TELNET stream contains a character
      following a CR that will allow a rational decision.

         Note that "CR LF" or "CR NUL" is required in both directions


Postel & Reynolds                                              [Page 11]


RFC 854                                                         May 1983


         (in the default ASCII mode), to preserve the symmetry of the
         NVT model.  Even though it may be known in some situations
         (e.g., with remote echo and suppress go ahead options in
         effect) that characters are not being sent to an actual
         printer, nonetheless, for the sake of consistency, the protocol
         requires that a NUL be inserted following a CR not followed by
         a LF in the data stream.  The converse of this is that a NUL
         received in the data stream after a CR (in the absence of
         options negotiations which explicitly specify otherwise) should
         be stripped out prior to applying the NVT to local character
         set mapping.



-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 94 14:15:52 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

In article <2k93rm$703@gap.cco.caltech.edu>, heathh@cco.caltech.edu (Heath Ian Hunnicutt) writes:
> al012@un.seqeb.gov.au ( ANTHONY LEE) writes:
>
>>Joe Doupnik (jrd@cc.usu.edu) wrote:
 
>>: [Telnet RFC 854 specifies CR -> CR NULL mapping.]
>
>
>>Sorry Joe, but I can't see this in my copy of RFC854.  There is section
>>5 on the IAC character (255) but nothing on CR translation.
>
> Time to read it again.  If it's not in 854 it's in one of the related RFCs
> on telnet.  (NVT is not particularly cleanly documented.)  Whatever you
> do, don't get the idea that it is ok to send single <CR>s in the NVT data
> stream.  So many clients cause major compatibility problems due to this
> stupid bug, it is simply amazing.

It's in RFC854 in the paragraph starting at the bottom of page 11.
--
James Harvey   harvey@iupui.edu   IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer:  These are my own opinions.  I do not speak for Indiana University.
He who refuses to read history is doomed to repeat it.

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 08:50:59 GMT
From:      michelg@wang.com (Michel Godfroid)
To:        comp.protocols.tcp-ip
Subject:   HOW : dynamic IP addr assign on Dial-in SLIP

On an AIX RS6K, we want to be able to talk to a number of PC systems running
SLIP. All these systems will establish communications by DIAL-IN. Can I get the AIX system to understand that various different IP addresses will be coming
in on the same (serial) network interface. A solution where all the PC's are
assigned the same IP address is no good ?

Thanks,


---
Michel Godfroid              Wang belgium            michelg@wang.com


-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 09:12:52 GMT
From:      bad@flatlin.ka.sub.org (Christoph Badura)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Source code from W Richard Stevens' book

In <msains.286.2D67B4A5@sunbird.ru.ac.za> msains@sunbird.ru.ac.za (Malcolm Sainsbury) writes:
>Is the published source of the examples in W.Richard Stevens book "Unix 
>Network Programming" available at any ftp site.

As the last paragraph of the preface says, it's available from
ftp.uu.net:publisched/books/stevens.netprog.tar.Z

-- 
Christoph Badura	bad@flatlin.ka.sub.org		+49 721 606137

Es genuegt nicht, keine Gedanken zu haben;
man muss auch unfaehig sein, sie auszudruecken.  - Karl Kraus

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 14:28:07 GMT
From:      mhenders@esoc.bitnet (Matt Henderson)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibm,comp.sys.ibm.pc.hardware.networking
Subject:   DNS - NIS Converter for Mosaic Needed

Hello All,

    I are trying to run Mosaic for Windows under Sun PC-NFS and am having
trouble with IP address resolution. I understand that in order to solve this
problem, I need something called a DNS-NIS converter. If you know where I
can find such software, please send an email. Thank you very much in advance.

    Best regards, Matt
--
Matt Henderson                            email:  mhenders@esoc.bitnet   
European Space Agency                     phone:  (49) 6151-90-3949      
Robert-Bosch Str., 5                      fax:    (49) 6151-90-2972
Darmstadt, Germany                                   

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 17:11:54 GMT
From:      szeliga@fluke.forestry.umn.edu (Tim Szeliga - NWS)
To:        comp.protocols.tcp-ip
Subject:   CIDR Addresses instead of Class C



Instead of subnetting our exisiting Class C address, our internet provider
suggested using CIDR (Classless Inter-Domain Routing) numbers.  We turn in
our 192.46.108 and get in return 199.86.20 - 199.86.23, four new networks.
Seems like a good idea on the surface, but are there any drawbacks?  
All we do here is TCP/IP, ftp, telnet, gopher and such, nothing too extreme.
Will any programs fail because of the high address numbers?  Are there
any horror stories I should know?  Is this even the proper newsgroup for this
question?  Worst of all, is this a FAQ?

Tim Szeliga
tim@snow.nohrsc.nws.gov

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1994 17:52:26 GMT
From:      COATES@UMUC.UMD.EDU (Ellster)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet - Where?

In <2k98h9$b8v@nova.umd.edu> COATES@UMUC.UMD.EDU writes:

> Where can I ftp the NCSA Telnet server PD program.

Thanks to all who responded!  Found it at:  ftp.ncsa.uiuc.edu  /PC/Telnet

 ----------------------------------------------------------------------- 
 |                            Elliott Coates                           | 
 |            coates@umuc.umd.edu        coates@umuc.bitnet	       |
 |                            washingtoon, dc                          |
 -----------------------------------------------------------------------

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 17:59:46 GMT
From:      suzannei@nsa.bt.co.uk (Suzanne Irvine)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   interrupt conflict with netbind

Hiya,

I'm using lanman V1.1 with LP486e ndis drivers 1.01.
When I try to run netbind V1.1 I get the message
PRo0030E interrupt conflict.

Any suggestions would be greatly appreciated.

-Suzie

---
-- 
******************************************************************************
*                                                                            *
* Suzanne Irvine                 E-mail: suzannei@nsa.bt.co.uk               *
*                                                                            *
******************************************************************************


-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 19:29:37 GMT
From:      gerryw@hpwin052.uksr.hp.com (Gerry Winsor)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???

David Sims (sims@sndsn1.sedalia.sinet.slb.com) wrote:
: Does anyone know of a robust TN 5250 client for PC or Mac ?? Can a TN 3270
: client be used with a re-mapped keyboard ?? If so, has anyone done this
: for a PC-TCP client for DOS/Windows or a Brown University TN3270 client
: for Macintosh ?? Any help would be most welcome. 

Hi David,

I understand that the folks at OpenConnect Systems Inc. have a PC TN5250 
product.  Never seen it, played with it though so .............

Contact OCS at (214) 484 5200, or send a mail message to info@oc.com.

GerryW
--
____________________________________________________________________________
**************
**** /_ _ ****   "Please Sir !
*** / //_/ ***                Can I have a new brain, this one is
****  /   ****                overloaded." 		- Larson
**************

Gerry Winsor            HPDESK:      Gerry WINSOR/HP8005/OA
Hewlett-Packard Ltd     UnixMail:    gerryw@hpwin052.uksr.hp.com
Mailstop J1             X.400 :      WINSOR,Gerry/HP8005,OA/HP/GB/GOLD 400/HP
Cain Road, Bracknell    Telephone:   (+44) 344 362384
Berks.  RG12 1HN.       Fax:         (+44) 344 362199
United Kingdom          Telnet:      316-2384
			VoiceMail:   316-2375
____________________________________________________________________________


-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 1994 21:09:20 GMT
From:      w-rolph@ds.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip
Subject:   slip source

Where is the source for slip code for unix machines?

Thanks in advance!


Regards.
 
Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1994 21:30:20 GMT
From:      pld@math.luc.edu (Peter Dordal)
To:        comp.protocols.tcp-ip
Subject:   TCP simulation

Can anyone recommend any package for simulating TCP performance?
I'd really like to simulate sliding windows, and similar stuff.

I've heard of Estelle, but can't find it.
Is it still out there? Or is there something newer?

Sorry if this is a duplicate post for some of you, 
but my first attempt had the wrong distribution.

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1994 21:47:10 GMT
From:      wardc@europa.eng.gtefsd.com (Cliff Ward)
To:        comp.protocols.tcp-ip
Subject:   INT14 Handling: What is needed?

I have seen several NOS's that claim to support INT14.  My question is what 
do they mean by support?

Here's my problem:  I have a PC connected to a LAN using TCP/IP (10BaseT).  I 
also have ProComm on my PC but no modem attached to a serial port.  There 
are, however, modems attached to a terminal server elsewhere on the network.  
I am using SUN PC-NFS on the PC.  What product(s) do I need to allow ProComm 
to see the modem at the other end?

If you have the answer using a different NOS, I would gladly accept it.

Thanks,

Cliff

wardc@europa.eng.gtefsd.com




-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 94 21:55:08 GMT
From:      jbrowne@zaphod.ncsa.uiuc.edu (Jim Browne)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

heathh@cco.caltech.edu (Heath Ian Hunnicutt) writes:

>cluster.  Because of the bugs in NCSA telnet for the Mac, and WinQVT/Net
>for Windows, the daemon can be hacked so that only one or the other of
>these two work.  WinQVT/Net drops the NULL from CR NULL, and NCSA does
>something else that is equally wrong.

Would you care to document this problem or at least mail
mactelnet@ncsa.uiuc.edu?

>If only people would read RFCs before they
>decide they know how to write TCP/IP applications.

No comment.

-- 
Jim Browne                                             | jbrowne@ncsa.uiuc.edu |
Head NCSA Mac Telnet Hacker, SDG System Administrator  | (217) 244-7798        |
<a href="http://www.ncsa.uiuc.edu/SDG/People/jbrowne/jbrowne.html">Click me</a>
                    "Not me, not yet, not that bad."

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1994 22:44:13 GMT
From:      wiltzius@anduin.ocf.llnl.gov (David P Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   Why end-end (TCP) checksums?

I would be interested in any literature (analysis, surveys,
discussion, research etc) on UDP, TCP and IP checksum errors.
My goal is to present a substantial argument for the continued
use of checksums even with much more reliable (and higher
speed) physical media.  Please don't flame since it seems
quite clear to me that end-end checksumming is still useful
(and probably will continue to be until all software can be
certified "perfect").

You can correctly imply from my request that a colleague
maintains that a sufficiently small BER in the physical
layer delivery (even just link-link!) makes end-end
transport level checksums redundant.  The time doing
these checksums is important in Gigabit networks (I am
aware of the OSI TP4-like gigabit network product that was
initially available years ago...).

(I note, for example, on the machine from which this message
is posted that of 50M TCP packets there are 97 checksum errors;
of 150M IP packets there are 2 header checksum errors.)

Please respond via email if possible.  Thanks!

  Dave Wiltzius
  Lawrence Livermore Nat'l Lab
  wiltzius@llnl.gov

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Feb 94 23:43:22 GMT
From:      venkat@cylink.COM (Venkat)
To:        comp.protocols.tcp-ip
Subject:   Public Domain access[TCP/IP] ?


Are there any sites holding (free :-)) TCP/IP software?

Thanks in advance,

-venkat
venkat@cylink.com

PS: include <std/disclaimer.h>

-- 

-------------------------------------------------------------------
Venkat S
venkat@cylink.com

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 02:11:48 GMT
From:      cherkus@unimaster.com (Dave Cherkus)
To:        comp.protocols.tcp-ip
Subject:   TCP, STREAMS Flow Control

Is the STREAMS flow control mechanism the only (direct) mechanism
used to throttle back a TCP transmitter in the SVR4 code path?
By direct, I mean directly in the transmit path, not as a result
of a ICMP source quench or the peer closing its window, etc.

I've looked at the BSD Net2 code and I've seen that drivers can
return ENOBUFS which gets returned back to ip_output and then to
tcp_output, where it is used to throttle back the sender.

I have the source to a STREAMS network driver (but unfortunately
not the source to the kernel) and it seems the drivers rely on
the STREAMS queue for flow control.  I don't see DL_UNITDATA_REQ
messages being returned with DL_SYSERR/ENOBUFS or ENOMEM (or
DL_UDERROR_REQ messages being generated either).  This would
seem to be the way to get the same behavior as BSD.

The reason I care is that I have a device that has a small number
of transmit descriptors and I'd like to be able to throttle back
the sender when the transmit desciptors are all in use.  When 
the sender sends a flood of tiny datagrams (e.g. X rubberbanding,
etc) it is easy for the descriptors to all be in use when the
STREAMS queue is still almost empty.

----
Dave Cherkus          UniMaster, Inc.         cherkus@unimaster.com 

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 02:26:42 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Why end-end (TCP) checksums?

wiltzius@anduin.ocf.llnl.gov (David P Wiltzius) writes:

>I would be interested in any literature (analysis, surveys,
>discussion, research etc) on UDP, TCP and IP checksum errors.
>My goal is to present a substantial argument for the continued
>use of checksums even with much more reliable (and higher
>speed) physical media.  Please don't flame since it seems
>quite clear to me that end-end checksumming is still useful
>(and probably will continue to be until all software can be
>certified "perfect").

Hi Dave:

    Jim Hughes and I have a paper in progress in which we describe an
experiment to test the efficacy of CRC-32 and the TCP checksum for
ATM packet splices (cases in which a group of ATM cells is lost such
that the receiver gets a packet which, at first examination, looks valid
but actually contains data from two packets).

    In brief, we did a simulation that generated 9.2 * 10**10 packet
splices.  CRC-32 caught most of the splices, but accepted 15 of them as
valid.  All of those 15 were detected by the checksum.  We've got more
detailed data about frequency with which the checksum failed, and may
be able to work out exactly how much the checksum protects in addition
to the CRC but we're still working through the numbers.  Right now it
looks like the checksum improves the error detection ability by about
two orders of magnitude, but I'm not prepared to defend that assertion.

Craig

PS: Note that the assertion that a checksum harms performance has been
raised several times on this list, and my sense was the conclusion was
that it depends very heavily on which machine architecture you use.  The
checksum may cost nothing, or may cost something -- but it depends.
(Check the TCP archives from May? 1993).

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 03:04:11 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

In article <CLJop6.7oH@un.seqeb.gov.au> al012@un.seqeb.gov.au ( ANTHONY LEE) writes:
>Sorry Joe, but I can't see this in my copy of RFC854.  There is section
>5 on the IAC character (255) but nothing on CR translation.

From RFC854, pages 11 and 12:

      "The sequence "CR LF", as defined, will cause the NVT to be
      positioned at the left margin of the next print line (as would,
      for example, the sequence "LF CR").  However, many systems and
      terminals do not treat CR and LF independently, and will have to
      go to some effort to simulate their effect.  (For example, some
      terminals do not have a CR independent of the LF, but on such
      terminals it may be possible to simulate a CR by backspacing.)
      Therefore, the sequence "CR LF" must be treated as a single "new
      line" character and used whenever their combined action is
      intended; the sequence "CR NUL" must be used where a carriage
      return alone is actually desired; and the CR character must be
      avoided in other contexts.  This rule gives assurance to systems
      which must decide whether to perform a "new line" function or a
      multiple-backspace that the TELNET stream contains a character
      following a CR that will allow a rational decision.

         Note that "CR LF" or "CR NUL" is required in both directions
         (in the default ASCII mode), to preserve the symmetry of the
         NVT model.  Even though it may be known in some situations
         (e.g., with remote echo and suppress go ahead options in
         effect) that characters are not being sent to an actual
         printer, nonetheless, for the sake of consistency, the protocol
         requires that a NUL be inserted following a CR not followed by
         a LF in the data stream.  The converse of this is that a NUL
         received in the data stream after a CR (in the absence of
         options negotiations which explicitly specify otherwise) should
         be stripped out prior to applying the NVT to local character
         set mapping."

Art

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 05:19:13 GMT
From:      larry@sdsu.edu (larry)
To:        comp.protocols.tcp-ip
Subject:   Re: INT14 Handling: What is needed?

Cliff Ward (wardc@europa.eng.gtefsd.com) wrote:
: I have seen several NOS's that claim to support INT14.  My question is what 
: do they mean by support?
 
: Here's my problem:  I have a PC connected to a LAN using TCP/IP (10BaseT).  I 
: also have ProComm on my PC but no modem attached to a serial port.  There 
: are, however, modems attached to a terminal server elsewhere on the network.  
: I am using SUN PC-NFS on the PC.  What product(s) do I need to allow ProComm 
: to see the modem at the other end?
 
: If you have the answer using a different NOS, I would gladly accept it.
 
: Thanks,
 
: Cliff
 
: wardc@europa.eng.gtefsd.com


Cliff:

I have been looking into this a bit lately, and basically I haven't
found anything in the way of INT14 handlers that utilize TCP/IP to
connect to remote modems. I am considering writing one myself, but
realistically it won't happen soon.

In a Novell or Windows for Workgroups environment, there are some choices.
Some that I have heard about are Message Port, Cross-Connect, and Winport,
all of which are in the current DataComm Warehouse catalog (1-800-328-2261).

Note that I have not personally used any of these products. I have ordered
from DataComm, and not had problems, but your mileage may vary.

Larry Mittag
larry@gondor.sdsu.edu


-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 07:22:03 GMT
From:      phoenix@clt.fx.net (Phoenix)
To:        comp.protocols.tcp-ip
Subject:   ACT for networks over TCP-IP - anyone??

I am looking to see if anyone has ever run ACT! for networks over the 
Internet... Anyone???

Any suggestions would be greatly appreciated :)

Thanks

phoenix@fx.net


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 08:02:59 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpip

In article <CLHtMz.M7u@cuug.ab.ca> davidmar@cuug.ab.ca (David Martin 233-9333) writes:
>Recently I have been developing TCP/IP applications using BSD sockets
>under Solaris 1.1 (SunOS 4.1.3).  I have no trouble connecting my clients
>to my server, but my server seems unable to determine when my clients
>disconnect (i.e. close()).
 ...
>I thought that I would get an appropriate value for 'errno' or 'so_errno'
>after a read() or recv() or perhaps a SIGURG signal, but I don't.

No, when the other end does an ordinary close(), your end will treat it as
an end of file.  read() will return 0.

You should get an error if you try to write() to the socket, though.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 08:55:35 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet's protocol treatment of <CR> <NU>

In article <CLJop6.7oH@un.seqeb.gov.au> al012@un.seqeb.gov.au ( ANTHONY LEE) writes:
>Sorry Joe, but I can't see this in my copy of RFC854.  There is section
>5 on the IAC character (255) but nothing on CR translation.

See the bottom of page 11, where it describes the use of CR LF to represent
newline, and CR NULL to represent CR.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 15:12:20
From:      arvesen@tivoli.com (Ralph Arvesen)
To:        comp.protocols.tcp-ip
Subject:   SMTP specification

Does anyone know where I can get the specification for SMTP? Thanks.
... Ralph Arvesen
... arvesen@tivoli.com


-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 13:13:08 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpip

> > Recently I have been developing TCP/IP applications using BSD sockets
> > under Solaris 1.1 (SunOS 4.1.3).  I have no trouble connecting my clients
> > to my server, but my server seems unable to determine when my clients
> > disconnect (i.e. close()).
> > ..
> > I thought that I would get an appropriate value for 'errno' or 'so_errno'
> > after a read() or recv() or perhaps a SIGURG signal, but I don't.
>
> No, when the other end does an ordinary close(), your end will treat it as
> an end of file.  read() will return 0.
>
> You should get an error if you try to write() to the socket, though.

Be aware that the reception of a FIN by your TCP returns an EOF but
does *not* prevent you from writing to the socket.  Due to TCP's
half-close, your TCP thinks the other end has just said that it's
done sending, but you are allowed to continue sending.

What often happens is that your end receives the FIN, you perform a
write (which returns OK) and that write causes the other end to return
an RST.  If you try another write, you get SIGPIPE, since your end
has received an RST.  You only get this write error if your end has
received an RST.

	Rich Stevens

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 13:29:48 GMT
From:      edm@harpo.dev.uga.edu (Ed Maioriello)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???

In article <CLLA5E.Azn@hpwin052.uksr.hp.com> gerryw@hpwin052.uksr.hp.com (Gerry Winsor) writes:
>David Sims (sims@sndsn1.sedalia.sinet.slb.com) wrote:
>: Does anyone know of a robust TN 5250 client for PC or Mac ?? Can a TN 3270
>: client be used with a re-mapped keyboard ?? If so, has anyone done this
>: for a PC-TCP client for DOS/Windows or a Brown University TN3270 client
>: for Macintosh ?? Any help would be most welcome. 
>

IBM's TCP/IP v.2.0 has a 5250 emulator.  I've not yet used it, but it
comes from big blue for what that's worth.

Ed Maioriello                                         edm@eris.ucns.uga.edu
University Computing & Networking Services            edm@harpo.dev.uga.edu
University of Georgia  ----------------------------------------------------
Athens, Ga. 30602      | First Rule of Troubleshooting: 
(706)-542-6468         |                     If it don't work - plug it in! 




-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 15:27:10 GMT
From:      Steven E. Matkoski <sematkos@syr.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: How to watch the traffic flow on FDDI ?

In article <2juq46$hh4@news.csie.nctu.edu.tw> Chao-Chi Yang 37h3100,
edward@e0sun29.ccl.itri.org.tw writes:
>Hi,
>      How can I check if any traffic flow on NP-FDDI ?  Where
>  can I find any network utilities like 'etherfind' or
>  'nfswatch' that can display network status on a specific
>  FDDI LAN ?
Seems to me that etherfind would work, you have to give it the fddi 
interface. Instead of le0 try using bf0 (or what ever the interface is
defined as in a netstat command).

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 16:05:43 GMT
From:      tannerc@cu18.crl.aecl.ca (Chris Tanner)
To:        comp.protocols.tcp-ip
Subject:   Setting a non-standard netmask

Hi All

We have a number of ethernet networks radiating out from a Wellfleet
router. We have a Class B IP address block assigned to our organization,
but generally configure our ethernet lines (and subnets) with a class C
net mask. 

We wish to set up a subnet that can have 500 hosts on it (instead of the
regular 254 hosts using a class C netmask). From the reading that I have
done, I assume that we set the netmask to 255.255.254.0, and assign 2
adjacent subnets (in this case 116 & 117) to that subnet. 

We were told that we cannot do this if subnet's 0 & 1 are in use
elsewhere in the network. I find this hard to believe. Can anybody
confirm this statement and/or explain it too me.

Thanks very much.

Chris
-- 
Chris Tanner                  Email: tannerc@CU18.CRL.AECL.CA
AECL Research                 Phone: (613) 584-3311 X4053       
Chalk River, Ont.             FAX:   (613) 584-1082
Canada, K0J 1J0

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 17:59:30 GMT
From:      spidey@ralvmg.vnet.ibm.com
To:        comp.protocols.tcp-ip
Subject:   Re: RPC: Unknown protocol ???

In <lchutsonCLDJB2.Bww@netcom.com>, lchutson@netcom.com (Lawrence Hutson) writes:
>
>Hi Netters, RPC guru's, and Norwegian Folklore Specialists,
>
>This is quite a trivial question for a RPC Guru, but it is
>breaking my program!
>
>I wrote a small RPC "hello world" program, and it compiled!!
>I followed the example like a good programmer should, but when I
>started the client I get the error: RPC Unknown protocol.
>
>Could this be a Norwegian (elf, nolm)? What were those little
>creatures that come out of the snow, you know, the ones that you
>should consult if you are going to build a barn in Norway?
>
>Any help on these matters will be greatly appreciated.
>
>Thx
>Lawrence Hutson
>

Lawrence Could be very basic stuff.   In clnt_create are you 
calling it in the form 
   clnt_ptr = clnt_create(server_name,prog_num,ver_num,"tcp");

if say you replace tcp by something weird like adf you would get the
Unknown Protocol error.

Hope this helps!


Jim Sliwa


" When the snake and the mangoose meet the mongoose prevails,
  for it is the jaws with which we speak, not the venom with which we
  say it, that determines our strength."


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 18:38:44 GMT
From:      robert@Sharenet.Edu ()
To:        comp.protocols.tcp-ip
Subject:   2 class c's can't talk?

I have two machines  (a.b.c.250 & a.b.c.251)  From either I can see anywhere
I can see either from  anywhere, however I can not see the other machine
from the other (if that makes sense) neither ping, telnet, traceroute
find each other.  Any ideas ?
thank you very much,    -robert
 
   robert@pei.sharenet.edu


-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 18:56:15 GMT
From:      daved@carbon.forge.tandem.com (Dave Dilena)
To:        comp.protocols.tcp-ip
Subject:   ? PC-based TCP/IP Decode Analyzer?

Anyone know of an Analyzer (S/W only) for the PC that does TCP/IP Decoding.  I'm
looking for inexpensive or free analysis software.  I've tried ETHLOAD but it doesn't
do decoding does it?  Anyone have experience with General Software's (Redmond, WA)
Snooper?  It looks and feels right but the TCP/IP Decodes are incorrect in the versions
that I have used.

Thanks, Dave




-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 20:36:28 GMT
From:      josuna@cra.org (josuna)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Help Running two SLIPs on Sun

I am running cslip-2.6 on SunOS 4.1.3. I have an dial-out SLIP line
functioning fine on sl0. However, when I dial in on sl1 and another
sliplogin process starts, the first sliplogin (on sl0) seems to run
into trouble. 

(One sliplogin is for out-going; other is incoming.)

Question: Should le0, sl0 and sl1 all be assigned the same IP number?

The reason I ask is because of a strange occurence: When the second
sliplogin starts up from a dial-in connection, pinging an Internet host
causes the dial-in modem to flash rather than the dial-out modem. It's
as if routing software is confused about which interface, sl0 or sl1,
to send packets to. Are there any bugs with trying to run two
sliplogins on same machine?

Any suggestions? 

Thanks,

Juan

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 21:11:39 GMT
From:      nachnani@venice.sedd.trw.com (Harish Nachnani)
To:        comp.protocols.tcp-ip
Subject:   In search of IP RFC/Info for wireless lans.



I am looking for IP protocol spec for wireless Lans
or any source of information.
Any suggestions will be appreciated.
thanks
     

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 21:49:54 GMT
From:      Buster Killion <cmkilli@PacBell.COM>
To:        comp.protocols.tcp-ip
Subject:   Dual Stacking Lantastic/Packet

I am working for Pacific Bell trying to get High Schools onto the
Internet.  One of the schools (Fremont High in Oakland) is using
Lantastic NOS with windows.  I need to be able to create a packet driver
interface so they can use Public Domain Packet applications.  I have
asked them to change their proprietary Node Runner drivers to NDIS so I
can install the NDIS Packet Shim, but they are having trouble figuring
out how to do this.  Their local Lantastic dealer basically handed them a
manual and said "good luck".  Has anyone out there successfully
interfaced PD software running on Windows on Lantastic?  We want to use
stuff like Trumpet, Eudora, Hgopher, etc.  Any help you can give would be
greatly appreciated.

Buster Killion   cmkilli@PacBell.COM; FAX (510) 827-2016
Knowledge Network Project   Res/LAB: (510) 674-9122

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 21:55:14 GMT
From:      rbr@dl.ac.uk (R.Bradshaw)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast File Transfer

Vernon Schryver (vjs@calcite.rhyolite.com) wrote:
: In article <1994Feb16.175316@bbn.com> adiwan@bbn.com (Arif Diwan) writes:
: >In article <CLAqM5.9B3@ncratl.AtlantaGA.NCR.COM>, brama@ncratl.AtlantaGA.NCR.COM
: >	 (Bhyravabho Rama) writes:
: >> Are there any broadcast file transfer packages or a broadcast file transfer
: >> protocol? What I want to be able to do is send a file to set of machines
: >> instead of having to specify a rcp for each machine or remsh for each machine
: >> to execute a given command.
: >
: > What you want is Multicast support on the host from where you are
: > transferring the
: > file and the destination hosts as well as any intermediate routers. ....
 
: Multicast UDP/IP packets are useless for FTP.  FTP uses TCP.  Multicast
: UDP/IP packets are equally useless for TFTP, although TFTP does use unicast
: UDP/IP.
: Vernon Schryver    vjs@rhyolite.com

I agree you couldn't use ftp for this; but it might be worth taking a look
at imm which is currently being used to multicast pictures and weather maps.
It seems to have the necessary error handling to make things reliable.

Maybe someone with in-depth knowledge of imm could elaborate :-)

--
Rob Bradshaw       Email: R.Bradshaw@dl.ac.uk       [rb685]
Tel:   +44 925 603226        |        Fax:   +44 925 603230
Networks Group, Daresbury Lab, Warrington, WA4 4AD, England

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 22:22:13 GMT
From:      dennis@westford.ccur.com (Dennis Rockwell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, STREAMS Flow Control

In article <CLLsrp.Kn7@mv.mv.com>, Dave Cherkus <cherkus@UniMaster.COM> wrote:
>Is the STREAMS flow control mechanism the only (direct) mechanism
>used to throttle back a TCP transmitter in the SVR4 code path?
>By direct, I mean directly in the transmit path, not as a result
>of a ICMP source quench or the peer closing its window, etc.

Generally, yes.  The high water mark on the TCP upper write
queue is taken as the amount the user is willing to buffer
locally.

>I have the source to a STREAMS network driver (but unfortunately
>not the source to the kernel) and it seems the drivers rely on
>the STREAMS queue for flow control.  I don't see DL_UNITDATA_REQ
>messages being returned with DL_SYSERR/ENOBUFS or ENOMEM (or
>DL_UDERROR_REQ messages being generated either).  This would
>seem to be the way to get the same behavior as BSD.

This is link-level stuff; DL_UNITDATA_REQ is the *link*
level request to send a packet.  There is no requirement to
return a DL_UDERROR_IND if a packet is dropped.  See below
for cautions on DL_UDERROR_IND.

TCP is supposed to be self-throttling, anyway.  Congestion
in the link-level interface should be treated just like
congestion in a gateway.  It will appear identical from
TCP's point of view, anyway.

>The reason I care is that I have a device that has a small number
>of transmit descriptors and I'd like to be able to throttle back
>the sender when the transmit desciptors are all in use.  When 
>the sender sends a flood of tiny datagrams (e.g. X rubberbanding,
>etc) it is easy for the descriptors to all be in use when the
>STREAMS queue is still almost empty.

These "transmit descriptors" are transmit commands to the
hardware?  Use STREAMs flow control as follows: Configure
the device's high water mark to something quite small (see
next paragraph).  When a descriptor is not available,
enqueue the DL_UNITDATA_REQ on the device's write queue via
putq().  IP's output processing (in TLP4, at least :-)
notices that the queue is full via a call to canputnext()
and sends a faked up source-quench message back upstream.

Tuning the high water mark: try one packet, ten packets,
play with it and see what works best for you.  High water
marks are in bytes, which doesn't help you much.  Remember
that if latency gets too high, throwing the packet away is
the right thing to do; if you have two copies of the same
packet in the queue, one of them is less than worthless.
You will want *some* queuing at the bottom so you can keep
the transmitter busy by having a packet to send when a
descriptor frees up.  A case can be made for keeping the
*last* few packets on this queue...

IP transforms the DL_UDERROR_IND into an N_UDERROR_IND and
passes it upstream; if the error is not ENOSR, TCP calls
in_pcbnotify() with the error field as errno and
tcp_errdiscon() as the notification function, which then
causes a forced disconnect.  This may not be the behavior
you want.  I was surprised to discover it; it looks like
overkill.

In short, TCP ignores DL_UDERROR_IND if it gives ENOSR and
closes the connection otherwise.
-- 
Dennis Rockwell
Concurrent Computer, Westford MA USA

dennis@westford.ccur.com

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Feb 1994 22:24:33 GMT
From:      mark@cyantic.com (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PCNFS over Token Ring (Source Route Bridging)

Data Communications just published a review of TCP/IP products for MS-DOS
and SunSelect's PCNFS came up pretty short in the review.  The review
concentrated on TCP/IP over Token Ring.

Apparently all of the products set the source route bridge flag in the MAC
header as a default.  This makes IP routing quite perilous if not impossible
in many environments.  PC-NFS was the only product that did not allow the
default to be changed so that the flag was not set.

We have a client who is looking at PC-NFS but will not for very long if
this information is accurate and there is no fix in the wind. Has anyone
had any experience in this area with Sun's product?

Thanks
-- 

Mark T. Dornfeld, CYANTIC Systems             Voice: (416) 234-9048
101 Subway Crescent Suite 2103                Facsimile: (416) 234-0477
Etobicoke, Ontario, M9B 6K4 CANADA            Email: mark@cyantic.com

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1994 23:33:30 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting question

In article <1994Feb16.191220.20430@rexago8.uucp>,
                   hc05@rexago8.uucp (Beirne Konarski) writes:
>>>
...
 If I have a router at site A, a connection to a router at site B, and 1
 computer attached to router B, do I have 2 subnets requiring 4 addresses?
...
<<<
Yes, you can have one subnet which connects the two routers and another
for the computer attached to B.

>>>
 Assuming that I have 2 subnets, which I believe is the correct answer, can I
 have the router connections (A-B) use a different mask than the router feeding
 the computer at site B? I would like to use 4 bits of host address for the
 computer (there will be more devices in the future), but hate to waste 14
 addresses on each router-router connection. I would like to maybe leave two
 bits for the addresses between routers.
<<<

What you need is a routing protocol which supports variable mask subnetting.
We use OSPF on Wellfleet and BBN routers (ofcourse, we invented it!), but
Proteon and now Cisco and probably other router vendors support it. For hosts,
you can use an OSPF "listener" with a modified gated for ES-IS for discovering
the optimal router or load balancing etc. But you might be better off with static
default routes or one-way RIP default route broadcast.

>>>
 And finally, can subnets be hierarchical, i.e. if I have a class B, can I use a
 mask of FF.FF.F0.00 to divide addresses among different parts of the company
 and then let the parts subnet from there? For example, could one of the
 subnets off of this mask create their own mask of FF.FF.FF.00? If so, how is
 this defined at the site that needs to talk to both sides?
<<<

Again the above solution coupled with multiple OSPF areas is the way to do it.

I do not believe what you say can be done the way I understand what you said.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 00:48:15 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting a non-standard netmask

In article <1994Feb22.160543.12910@cu23.crl.aecl.ca>,
	 tannerc@cu18.crl.aecl.ca (Chris Tanner) writes:

>>>
 We have a number of ethernet networks radiating out from a Wellfleet
 router. We have a Class B IP address block assigned to our organization,
 but generally configure our ethernet lines (and subnets) with a class C
 net mask.

 We wish to set up a subnet that can have 500 hosts on it (instead of the
 regular 254 hosts using a class C netmask). From the reading that I have
 done, I assume that we set the netmask to 255.255.254.0, and assign 2
 adjacent subnets (in this case 116 & 117) to that subnet.

 We were told that we cannot do this if subnet's 0 & 1 are in use
 elsewhere in the network. I find this hard to believe. Can anybody
 confirm this statement and/or explain it too me.
<<<

You cannot use the first subnet in the range defined by a mask. See below
for explanation.

To use variable length subnet masks in a network you will need a routing
protocol that supports it, such as OSPF. I suppose you have the same
mask in the entire network.

Given that and a mask of 255.255.254.0 you should be able to use
subnets x.x.2,3 thru x.x.253,254 (I believe you can use all 1 bits in the
subnet portion), where the comma signifies that the subnet spans two 
numbers of the third octet in the usual decimal notation. I am sure
you know what I mean here!!!

You cannot use x.x.0,1 as I mentioned earlier because conventionally
the first subnet ("subnet zero") means -this- subnet (e.g. Unix software
such as the route command use that convention) and I believe RFC 1122
(I think that is the correct RFC) disallows it.

What you heard is correct.


-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Feb 1994 01:38:20 GMT
From:      ler@lerami.lerctr.org (Larry Rosenman)
To:        comp.protocols.tcp-ip,comp.unix.amiga
Subject:   PPP/M68K/SVR4.0/Lachman STREAMS IP ???????????????

Anyone know of PPP source code that would compile and 
run in the SVR4.0 Amiga Unix kernel?

We have Lachman STREAMS IP code, and no support from
the vendor.

Any pointers would be appreciated. 

Please E-Mail me, as I don't always read the newsgroups.

Thank You.

PS: I will summarize if asked.


-- 
Larry Rosenman                            Internet: ler@lerami.lerctr.org
ATT: +1 214-399-0210 (voice)              UUCP: ..!utacfd.uta.edu!lerami!ler
US Mail: 900 Lake Isle Circle, Irving, TX 75060-7726

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 02:06:42 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Traffic

In article <2k6n81$eau@ibridge.iohk.com> samson@iohk.com (Samson Luk) writes:
>I don't have DEC OSF/1 or Ultrix... I have FreeBSD and a SVR4 (Esix v4.0.4), 
>do you think I can use NNStat under these boxes?

Probably not without some porting work.  According to the README file,
    We believe that this version should run on
	    DEC MIPS-based workstations running Ultrix V4.0 and later
	    DEC VAX-based workstations running Ultrix V4.0 and later
	    DEC Alpha running OSF/1 V1.3 and later
	    Sun3/Sun4 running SunOS 4.X
	    SunOS 3.X
	    SGI Irix 4.0.5
    and perhaps some other systems.

Note that I do not intend to port this code to anything else.

-Jeff

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Feb 1994 03:13:03 GMT
From:      laird@nettle.ecn.purdue.edu (Kyler Laird)
To:        comp.protocols.tcp-ip
Subject:   ftp with zmodem transfer?

[If this is not the correct place to post this, please e-mail me.]

I've been playing around with ftp.c and sz.c tonight in an exploratory
attempt to merge them.  It seems doable, but I suspect someone else
has already done a much better job than I would/could.

I'd appreciate pointers to Unix software that will allow me to get and
put files from/to remote sites to/from my PC over a dialup using
zmodem.

Thanks!

--kyler

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 15:05:49 -0500
From:      nosilla@pangea.ohionet.org (Andrew J. Templin)
To:        comp.protocols.tcp-ip
Subject:   SLIP over telnet link

I have had this question from one of our users, and I cannot 
supply an answer.  I simply don't know enough about SLIP to
be able to tell them.

Did not see this in the FAQ; forgive me if my eyesight is poor.

We have a leased line running to a Inet provider, who has several
terminal servers set up as modem banks.  You call a term. server,
log into it, and then telnet to our machine.

Assuming that you have managed to telnet successfully, would it 
then be possible to start a SLIP link *over that telnet connection*?
It must be SLIP, and not PPP.

So, to recap:

I dial the terminal server and log in.  I then telnet from the
terminal server to our UNIX host.  I then would like to start
up SLIP (with the UNIX host) over the telnet connection.

Would this work?  Would it be reliable?  Or, is this only possible
over serial lines?  I know that telnet is not a full 8 bit path,
so I can see possible problems in that arena.

Thank you for any help,

						Andrew

nosilla@pangea.ohionet.org
-- 
                           Andrew J. Templin
           Sysadmin - Network junkie - Confused Programmer(tm)
                        OHIONET - Columbus, OH
    "My opinions do not necessarily represent OHIONET - no way, no how..."

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Feb 1994 08:54:56 GMT
From:      spyder@spyder.demon.co.uk (Phil Spencer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In <2jo67l$p3t@solaris.cc.vt.edu>, timbuck@borg.lib.vt.edu (Tim Buck) writes:
>Is it possible to connect 2 PC's with 10BaseT directly to one another
>(without a hub)?  Twisted pair cable seems to be cheaper than coax (not
>to mention easier to run along walls, etc.).  This would be to connect
>2 PC's at home.

You've got to be joking.  I've just set up a small TCP/IP network here and I
went for coax because:

1. The cabling is *much* cheaper though prices seem to vary by about a factor
   of ten from supplier to supplier.  I happen know someone running with a
   cabling company an I got mine at near cost
2. No hub required
3. The coax cable is only marginally thicker than TP and is quite a bit more
   flexible - this surprised me and was probably the deciding factor.  I will
   move my machines around quite a bit an may be connect laptops to the
   network.  The physical flexibility of the coax seemed much more manageble
   for 'non-permanent' cable runs.
4. For most configurations there is a lot less cable required

Incidentally, I had decided to go for twisted pair before I went to order the
cables.  My cable supplier/colleage then showed me a selection of cables, the
costs and he recommended coax for a small network.

Well there's my 2 cents worth

Phil


-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 10:18:18 GMT
From:      mas1@letterbox.rl.ac.uk (Martin Strange)
To:        comp.protocols.tcp-ip
Subject:   MBONE question

An MBONE/Multicast quickie. Am I right in assuming that the latest mroute
software needed for MBONE connection can *only* be run on SunOS 4.1.x
hosts. This is proving to be pretty inconvenient to arrange here, so if
it is possible to run it on anything else I'd very much appreciate hearing
about it.

Thanks,
Martin.


---
+---------------------------------------------------------------------------+
| Martin Strange.                            Email: mas1@letterbox.rl.ac.uk |
| Rutherford Labs, Oxfordshire           Unix talk: mas1@sage.cc.rl.ac.uk   |
| England                                                                   |
+---------------------------------------------------------------------------+



-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 12:17:00 -0000
From:      tim@pipex.net (Tim Goodwin)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP specification

In article <arvesen.374.000F3513@tivoli.com>, Ralph Arvesen
<arvesen@tivoli.com> wrote:
>Does anyone know where I can get the specification for SMTP? Thanks.

STD 10 (currently RFC 821).

You should also look at RFCs 1425 - 1428, which define the SMTP
extensions.

Tim.
-- 
Tim Goodwin | "scanf()... usually does something almost but not
PIPEX Ltd   | completely unlike what you want" -- Chris Torek.

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Feb 1994 21:12:13 -0500
From:      mfawcett@clark.net (Dolphin Communications, Inc.)
To:        comp.protocols.tcp-ip
Subject:   Protocol Engineer Wanted

We are looking for an independent consultant/information engineer with
in-depth expertise in TCP-IP and Kerberos protocols.  Initially we are
looking for preliminary consultation with potential for a long term
engineering project.

Please fax your Resume.

________________________________________________________________________
-  Dolphin Communications, Inc.                    mfawcett@clark.net  -
   Washington DC                                   phone 202.797.7312
                                                     fax 202-797-7716

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 14:06:13 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting a non-standard netmask

In article <1994Feb22.185004@bbn.com>, adiwan@bbn.com (Arif Diwan) writes:

>>>
...
 You cannot use the first subnet in the range defined by a mask. See below
 for explanation.

 To use variable length subnet masks in a network you will need a routing
 protocol that supports it, such as OSPF. I suppose you have the same
 mask in the entire network.

 Given that and a mask of 255.255.254.0 you should be able to use
 subnets x.x.2,3 thru x.x.253,254 (I believe you can use all 1 bits in the
 subnet portion), where the comma signifies that the subnet spans two
 numbers of the third octet in the usual decimal notation. I am sure
 you know what I mean here!!!

 You cannot use x.x.0,1 as I mentioned earlier because conventionally
 the first subnet ("subnet zero") means -this- subnet (e.g. Unix software
 such as the route command use that convention) and I believe RFC 1122
 (I think that is the correct RFC) disallows it.
...
<<

The previous msg was written late at night and is a bit confusing and
has a minor error. A better explanation:

You cannot use a subnet 0 for reasons given in the previous msg.
Assuming you have a constant netmask of 255.255.255.254 in the entire
network then you have subnets  x.x.2, x.x.4, x.x.6, ..., x.x.2n, ... x.x.252
available. You can also use subnet x.x.254 but that is special since it
is half sized for obvious reasons, and I am not sure what the implications are.
I used subnet 254 with your mask in a network with 11 Wellfleet BCNs and BLNs
and it appears to work without problems.




 --

 -- Arif Diwan (adiwan@bbn.com)




		-- Arif Diwan (adiwan@bbn.com)
				617/873-6274

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 14:25:28 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Help Running two SLIPs on Sun

In article <2kdqcc$ebs@news1.digex.net>, josuna@cra.org (josuna) writes:
 I am running cslip-2.6 on SunOS 4.1.3. I have an dial-out SLIP line
 functioning fine on sl0. However, when I dial in on sl1 and another
 sliplogin process starts, the first sliplogin (on sl0) seems to run
 into trouble.

 (One sliplogin is for out-going; other is incoming.)

 Question: Should le0, sl0 and sl1 all be assigned the same IP number?

 The reason I ask is because of a strange occurence: When the second
 sliplogin starts up from a dial-in connection, pinging an Internet host
 causes the dial-in modem to flash rather than the dial-out modem. It's
 as if routing software is confused about which interface, sl0 or sl1,
 to send packets to. Are there any bugs with trying to run two
 sliplogins on same machine?
...

On point-to-point connections it is the remote end's address which is
important. I run Morningstar ppp (in cslip mode) and it creates
multiple interfaces as follows:

le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 128.89.4.202 netmask ffff0000 broadcast 128.89.255.255
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 
du0: flags=51<UP,POINTOPOINT,RUNNING>
        inet 128.89.4.202 --> 128.89.0.86 netmask ffff0000 
du1: flags=51<UP,POINTOPOINT,RUNNING>
        inet 128.89.4.202 --> 128.89.0.87 netmask ffff0000 

Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       2      1679       lo0
128.89.0.86          128.89.4.202         UH       3      3959       du0
128.89.0.87	     128.89.4.202	  UH	   3	  414	     du1
default              128.89.0.1           UG       1      324        le0
128.89.0.0           128.89.4.202         U        33     416094     le0

Notice that the route to the remote end of the slip connection is via
the IP address of le0. These routes and the interface table entries are
automatically added by mst-ppp in both slip and ppp mode. I am not sure how
sliplogin works but you should use your le0 address for the local address
and a different remote address for each interface (ofcourse).

I also have the following in my arp tables so that arp requests get 
satisfied via the le0 interface:

TACTICS.BBN.COM (128.89.0.86) at 8:0:20:b:4a:f0 permanent published
hadrian.bbn.com (128.89.0.87) at 8:0:20:b:4a:f0 permanent published


I am running xrn and xemacs over the slip line very comfortably
with V.32bis modems at this very time.


-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 22:53:54 GMT
From:      jazz@hal.com (Jason Zions)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.sys.isis
Subject:   Re: Withdrawal of the unsupported IP multicast HP-UX 9.01 distribution

In article <CLG68v.3G5@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

   Pity this.  I can now guarantee that I will NOT be purchasing an HP
   system anytime soon.  Vendors that are this paranoid about "support
   consequences" clearly do not want my business.

   One of the reasons I have bought Sun in the past is that they give
   away lots of unsupported software without HP-like paranoia about
   support.  Sounds like Sun will continue to be the better choice in
   future.

For the small number of users who understand the Big Boy license, yes, HP's
support paranoia can be annoying. The fact that you can stil ask for this
stuff, and they'll still give it to you, is a large improvement over HP's
past attitude. 

Unfortunately, many customers who say they're Big Boys turn out to be little
crybabies when the unsupported stuff they grab makes their system shakey.
They get snotty and whine a lot to HP about shoddy bits and how they'll sue
if HP doesn't Make It Work. Apparently no one expects Sun to actually do
that, so the whiners never really get around to doing more than whining on
the net; with HP's reputation, however, the whiners do things like write
nastygrams to board members, file lawsuits, etc.

(For those of you who haven't got a clue: the "Big Boy" license means that
the user is willing to be a big boy about things, read the READMEs,
understand what "unsupported" means, and generally take the bits and use'em
without whining to the provider if they don't work or crash your system or
erase your root partition.)

Past experience bears this difference out: no one expects unsupported
software from Sun to work, but many of HP's customers do in fact expect
unsupported HP software to be, well, supported.

Jazz

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Feb 1994 22:54:16 GMT
From:      scotty@cup.hp.com (Scott Millward)
To:        comp.protocols.tcp-ip
Subject:   TCP Urgent Data


Hello,

I have been experimenting with the use of Urgent Data using HP-UX and I
have some questions on the receipt of urgent data and the use of the 
select() system call in detecting the exceptional condition.

I have looked at the Berkeley 4.3net2 source and at the HP-UX source and
I have come to the following conclusions:

	1) Select() will always detect an exceptional event as long as
           Urgent data has arrived and we are prior to or AT Mark.

	2) Due to 1) you MUST read one byte past the Urgent mark to 
  	   clear the exceptional condition.

When I use the socket option, SO_OOBINLINE, the process of reading the
one byte of urgent data places me one byte past the MARK in the socket
buffer, so the exceptional condition is cleared.

However, if I use the default, out of bound method, tcp_input() will store
the one byte of data in a field in the tcpcb.  The only way to retrieve
this byte is to call recv() with the the MSG_OOB flag set.   This allows
me to read the Urgent byte before reading the data in the socket buffer,
but the exceptional condition is met until I read at least one byte past
the urgent MARK.

Example using SO_OOBINLINE:

    client sends 500 bytes
    client sends 1 Urgent byte
    client sends 500 bytes

If the server does not start until all three packets are received, select()
will detect an READ and EXCEPTION event.  If I call ioctl(FIONREAD) to    
determine the number of bytes on the socket buffer, I will get 1001.  So,
if I attempt to read 1001 bytes, I only read 500 bytes and now the internal
socket structure field so_state will have the SS_RCVATMARK flag set.  The
next select() will detect a READ and EXCEPTION event because now I am 
AT MARK.  At this point, an ioctl(SIOCATMARK) will indicate TRUE.  Then
if I read the one byte of urgent data (using recv() with no flags..), this
resets the so_state flag and the so_oobmark field is also 0, so the
exception condition is cleared.

So, for inline urgent data, it appears a receiving algorithm could be


Loop until DONE (Done not defined, I only want to deminstrate the Urgent Data)
	select(READ and EXCEPTION)
	.
	.

	if (exception event) {
	   if ATMARK {
		recv() one byte
	   } else {
 recv() max bytes and discard(??)
	   }
	} else {
 recv() max bytes.  (good data)
	}
} /* End of loop */


This algorithm does NOT work for urgent data that is truely Out Of Band
(not inline).  The problem is we recv() all the way up to the MARK and
then when ATMARK, the recv() needs to set the MSG_OOB flag to retrieve
the data from the tcpcb.  Once this is done, the socket buffer is still
ATMARK, so the except condition is met.

The question I have is more philosophical in that, should the exception
event be cleared if I am ATMARK and the OOB data has been read ?

This can be detected because there is a tcpcb field, t_oobflags, that is
set to TCPOOB_HAVEDATA or TCPOOB_HADDATA.  When the intial urgent byte
arrives, the byte is stored in the tcpcb field and the t_oobflags field
is set to TCPOOB_HAVEDATA.  After the recv() with the MSG_OOB, the 
t_oobflags field is set to TCPOOB_HADDATA.  If a subsequent recv() with
MSG_OOB is called, the recv() returns with errno set to EINVAL.
      
Any thoughts?

Thanks,

Scott Millward

--
_____________________________________________________________________________
Scott Millward                       |    Hewlett-Packard Company
E-mail:    scotty@cup.hp.com         |    Information Networks Division
Telephone: (408) 447-2069            |    19420 Homestead Road, MS 43LF
FAX:       (408) 447-3660            |    Cupertino, CA 95014
____________________________________________________________________________

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Feb 94 23:06:26 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over telnet link

You need telnet to be 8-bit clean. Negotiate SUPPRESS GO AHEAD, ECHO, and 
BINARY options as needed. Also, turn off the escape character in the client
(usually ctrl ]). That should get it to work.

Some OS will allow slattach to run on the tty siide of a pty (the SLAVE side), 
some restrict SLIP to bonafide serial lines. Linux, for example will let 
you run SLIP on any tty (even a virtual console, but thats disgusting)


-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1994 23:29:59 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In <2jo67l$p3t@solaris.cc.vt.edu>, timbuck@borg.lib.vt.edu (Tim Buck) writes:
>Is it possible to connect 2 PC's with 10BaseT directly to one another
>(without a hub)?

Yes. You need a "cross-over" TP cable.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1994 00:05:00 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question

Martin Strange (mas1@letterbox.rl.ac.uk) wrote:
: An MBONE/Multicast quickie. Am I right in assuming that the latest mroute
: software needed for MBONE connection can *only* be run on SunOS 4.1.x
: hosts. This is proving to be pretty inconvenient to arrange here, so if
: it is possible to run it on anything else I'd very much appreciate hearing
: about it.

No, it's not right.  The release notes from e.g. the latest BSDI release
(v1.1) claim both multicast and multicast routing support; I expect that
other system vendors have something ranging from alpha test use at your
own risk code to something resembling fully functional but not yet shipped
beta test code.

--Ed

(a satisfied BSDI customer, for what it's worth)

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 94 08:14:15 PST
From:      rw@rwsys.wimsey.bc.ca (Randy Wright)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

heading@signal.dra.hmg.gb (Anthony Heading) writes:
> Hello.
>    I'm really puzzled by this. We have several hundred hosts on

I'm having difficulty understanding the mechanisms involved in this as
well. Please post.

--Randy
____________________________________________________________________________
rw@rwsys.wimsey.bc.ca (Randy Wright)                        (604) 581-0518
                ICBM address = 49d 12m 5s N    122d 51m 49s W
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 02:46:28 GMT
From:      laird@pasture.ecn.purdue.edu (Kyler Laird)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

adiwan@bbn.com (Arif Diwan) writes:

>In <2jo67l$p3t@solaris.cc.vt.edu>, timbuck@borg.lib.vt.edu (Tim Buck) writes:
>>Is it possible to connect 2 PC's with 10BaseT directly to one another
>>(without a hub)?
 
>Yes. You need a "cross-over" TP cable.

And if you want to add a few more (via daisy-chain), give Farallon
(510-814-5000) a call.

--kyler

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 94 10:47:16 PST
From:      jpc@tiac.net
To:        comp.protocols.tcp-ip
Subject:   Re: 2 class c's can't talk?


Post your traceroute so that I can see where it dies.

John

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 03:10:34 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question

In article <2kgqvc$dh0@nigel.msen.com> emv@garnet.msen.com (Edward Vielmetti) writes:
>Martin Strange (mas1@letterbox.rl.ac.uk) wrote:
>: An MBONE/Multicast quickie. Am I right in assuming that the latest mroute
>: software needed for MBONE connection can *only* be run on SunOS 4.1.x
>: hosts. This is proving to be pretty inconvenient to arrange here, so if
>: it is possible to run it on anything else I'd very much appreciate hearing
>: about it.
>
>No, it's not right.  The release notes from e.g. the latest BSDI release
>(v1.1) claim both multicast and multicast routing support; I expect that
>other system vendors have something ranging from alpha test use at your
>own risk code to something resembling fully functional but not yet shipped
>beta test code.

Not to mention other UNIX workstation vendors who were shipping mrouted
and multicast support before BSDI was founded.  I'm not complaining about
BSDI's BSD386 1.1, but it's good to keep things in prospective.


Vernon Schryver    vjs@rhyolite.com

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1994 04:41:51 -0000
From:      heading@signal.dra.hmg.gb (Anthony Heading)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   How do multi-homed hosts choose the interface?

Hello.
   I'm really puzzled by this. We have several hundred hosts on
a class B ethernet, and a few on a class C FDDI net, the routing
being done by one of two machines (an OSF/1 alpha and an Ultrix
DECstation) which have interfaces on both networks. The nameserver
has multiple A records for these machines - we hope to avoid 
giving different hostnames to the different interfaces.
  I want the two routing machines to use the FDDI network to
talk to each other, but they steadfastly refuse to use anything
but the ethernet. I've tried setting the interface metrics (which
doesn't work) and reversing the boot time configuration order in
the hope that this might reorder the routing table (without success
- netstat -r lists the class B network first always).
  Resorting to the obvious books, Comer vol.1 doesn't discuss
DNS style multiple addresses at all, and the 4.3BSD book claims
routing is a user-level process and the kernel doesn't try to
do anything smart. This makes me suspect that multiple A records
are used by trying each address in the gethostbyjingo() structure
in turn, but there seems to be no way of making the DNS server
impose order onto those addresses.

Any clues, speculation or even hard answers appreciated...

Thanks

Anthony
-- 

------------------
AJR Heading, DRA UK

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 08:52:01 GMT
From:      pchan@netcom.com (Pochun Chan)
To:        comp.protocols.tcp-ip
Subject:   HELP-Eudora/POP/SMTP


Hi All,

Sorry for the extra bandwidth.  I have a problem with my SLIP conncection 
in using email.  Thanks in advance for your comments and suggestions.

Background Info.
================
1. I have a shell account with netcom.  	(pchan@netcom.com)
2. I also have a SLIP account with netcom.	(Spchan@pchan.slip.netcom.com)
3. I applied a custom/personal domain name	(@company_name.com)
   (it is not working yet)
4. My system is running MS Windoes 3.1 + WinSock 
5. My objective for having the SLIP account is to receive email addressed to:
   "anything@company_name.com" or "anything@pchan.slip.netcom.com".  BTW, 
   I have sent a few emails to "anything@pchan.slip.netcom.com".  They are 
   now somewhere in the cyberspace to be retrived.

I have tried:
=============
6. I have installed PC Eudora Version 1.4 for Windows to my system.
7. In the Eudora program, my POP Account parameter is "pchan@netcom.com" 
   and the SMTP server parameter is "netcom.com".  I believe these two 
   parameters are correct.
8. When logining to netcom, I would receive email addressed to my shell 
   account: "pchan@netcom.com".  But I was expecting emails addressed to 
   my slip account: "anything@pchan.slip.netcom.com".
9. Netcom told me:
   "THESE MESSAGES (email addressed to 'anything@pchan.slip.netcom.com') 
    WILL NOT BE RETRIEVABLE BY POP.  YOU MUST RUN AN SMTP SERVER AND THE 
    SMTP SERVER MUST DELIVER THE MAIL TO A FILE ON YOUR HOST WHICH YOU 
    CAN READ THE MESSAGES FROM USING YOUR OWN MAIL USER AGENT"

My questions:
=============
10. Is it possible at all to receive email addressed to my slip account? 
    (i.e. "anything@pchan.slip.netcom.com")  Either receiving it from my 
    shell account on netcom's UNIX machine or from my PC/SLIP connection 
    will be fine.
11. Where do I run the SMTP server as mentioned in #9?  On netcom's UNIX 
    machine or on my PC.  Is PC Eudora a SMTP server program?  How can I 
    run it as a SMTP server.  If it is not, can anyone recommend me one 
    please.  BTW, is Eudora just an off-line mail reader?
12. What is the Mail User Agent mentioned in #9?

Again, thanks for your net.wisdom.  Look forward to hearing from you.

Regards,

Paul Chan
pchan@netcom.com

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 18:15:00
From:      ace@ics.forth.gr (Andreas C. Enotiadis)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over telnet link

In article <2kgcut$hs@pangea.ohionet.org> nosilla@pangea.ohionet.org (Andrew J. Templin) writes:
>We have a leased line running to a Inet provider, who has several
>terminal servers set up as modem banks.  You call a term. server,
>log into it, and then telnet to our machine.
 
>Assuming that you have managed to telnet successfully, would it 
>then be possible to start a SLIP link *over that telnet connection*?
>It must be SLIP, and not PPP.


>                                                Andrew

The short answer is no. You cannot have a slip ling over anything but a serial 
link.
One suggestion would be to arrange with your terminal server provider to 
support slip on his terminal servers with authentication from your hosts and 
to charge those users differently.
If the terminal servers are CISCO, for example, you could set up a TACACS 
server on your systems to authenticate users logging on to the terminal server 
an allow them slip.
Regards
Andreas
--------------------------------------------------------------------------
Andreas C. Enotiadis
Internetwork Ltd
"Just screwing around - for a living"
ace@ics.forth.gr
ace@iesl.forth.gr
ace@praxis.forth.gr
Snail-Mail :7 Fokidos Str, 11526 Athens, Greece. Tel : 6486222-3, Fax 6486223
--------------------------------------------------------------------------

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 15:27:02 GMT
From:      jku@duesentrieb.rob.cs.tu-bs.de (Joern Kunst)
To:        comp.protocols.tcp-ip
Subject:   Problem with sockets

Hello,

I have a problem with programming sockets.
When I send a couple of bytes, representing floats and bytes, I
have to do it in packages of 4 bytes, because, if I send for example
two floats twp bytes and two floats, the last two float don't reach
the goal right. I have fond out, that the reason is, that I have to
send packages of 4 bytes, for exemple two floats, four bytes two floats.

But why is this so? has anyone an explanation for this ?

thanks for answers,

Joern Kunst


-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 15:54:49 GMT
From:      muk@sunny.hq.interlink.com (Donn Mukensnable)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Is xdr_char numeric?

 I am working on an implementation of xdr on an IBM mainframe.  This
 system utilizes the EBCDIC character set.  The Internet and the
 RPC/XDR representation uses the ASCII character set.  Our version of
 xdr_string does the necessary translations, but I am not sure whether
 translation is needed for xdr_char.  

 From the name ("character") it sounds like the contents are text and
 should be translated, but the definition in the Sun Network Guide and
 RPC Protocol Specification implies that char variables are one-octet
 numerics.  They have both a signed (implicit) and unsigned form and are
 placed into the external form without any padding or translation being
 described.  To be fair, there is nothing in the RPC spec. covering the
 translation between internal and external character sets.

 I am interested in finding out what the correct interpretation should
 be, both from a canonical standpoint as well as what is the most common
 usage of the xdr_char form.

 Thanks,  Donn 

 -----------------------------------------------------------------------
 muk@interlink.com
 I speak for myself; no one else will.


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 17:02:39 GMT
From:      d00n@crash.cts.com (Kevin Spousta)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In <1994Feb23.182543@bbn.com> adiwan@bbn.com (Arif Diwan) writes:

>In <2jo67l$p3t@solaris.cc.vt.edu>, timbuck@borg.lib.vt.edu (Tim Buck) writes:
>>Is it possible to connect 2 PC's with 10BaseT directly to one another
>>(without a hub)?
 
>Yes. You need a "cross-over" TP cable.

Like so:

1 --- 3
2 --- 6
3 --- 1
6 --- 2

on your RJ-45 connectors.



-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1994 18:11:29 GMT
From:      richardw@bolas.co.uk (Richard Whitehead)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpip

From rstevens@noao.edu (W. Richard Stevens)
Subject: Re: tcpip
Date: Tue, 22 Feb 1994 13:13:08 GMT
| 
| > > Recently I have been developing TCP/IP applications using BSD sockets
| > > under Solaris 1.1 (SunOS 4.1.3).  I have no trouble connecting my clients
| > > to my server, but my server seems unable to determine when my clients
| > > disconnect (i.e. close()).
| > > ..
| > > I thought that I would get an appropriate value for 'errno' or 'so_errno'
| > > after a read() or recv() or perhaps a SIGURG signal, but I don't.
| >
| > No, when the other end does an ordinary close(), your end will treat it as
| > an end of file.  read() will return 0.
| >
| > You should get an error if you try to write() to the socket, though.
| 
| Be aware that the reception of a FIN by your TCP returns an EOF but
| does *not* prevent you from writing to the socket.  Due to TCP's
| half-close, your TCP thinks the other end has just said that it's
| done sending, but you are allowed to continue sending.
| 
| What often happens is that your end receives the FIN, you perform a
| write (which returns OK) and that write causes the other end to return
| an RST.  If you try another write, you get SIGPIPE, since your end
| has received an RST.  You only get this write error if your end has
| received an RST.

I don't know how related this is, but I have also encountered a similar
problem.

If my process, having initiated a TCP connection and written all it's data,
then attempts a close(), it will block until completion of the 3-way handshake.
If, instead of a FIN, my socket receives a RST, the close() completes (returning
zero). I can't seem to detect that incomming RST. Any ideas?

Cheers, Richard.
---

------------------------------------------------------------------------------
MMMMMMMMM  Richard Whitehead               <Richard.Whitehead@micromuse.co.uk>
MMMMMMMMM  Micromuse, 90 Putney Bridge Rd                    Tel: 081-875-9500
MMMMMMMMM  London SW18 1DA                                   FAX: 081-875-9995


-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 94 18:16:43 GMT
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.protocols.tcp-ip
Subject:   Is there a SLIP package for DOS -- Dial out and SLIP to remote UNIX


Networking Gurus,

	Is there a PD or a commercial SLIP package for DOS? What I need to do
is to be able to dial out using a modem and connect to a remote UNIX machine
using the SLIP protocol.

	Any and all responses on this matter appreciated.

Thanx,

Raj.
-- 
===============================================================================
  __  __     .
 /   __/    /                               Raj Malhotra.
/   ( /_   /                                voice : 
        __/                                 email : manmetha@gauss.rutgers.edu

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

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 19:19:12 GMT
From:      martin@mrrl.lut.ac.uk (Martin Hamilton)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question

   An MBONE/Multicast quickie. Am I right in assuming that the latest mroute
   software needed for MBONE connection can *only* be run on SunOS 4.1.x
   hosts. This is proving to be pretty inconvenient to arrange here, so if
   it is possible to run it on anything else I'd very much appreciate hearing
   about it.

From the MBONE FAQ (this is probably a little out of date) :

* Which workstation platforms can support the mrouted program?

    The most convenient platform is a Sun SPARCstation simply because
    that is the machine used for mrouted development.  An older
    machine (such as a SPARC-1 or IPC) will provide satisfactory
    performance as long as the tunnel fanout is kept in the 5-10
    range.  The platforms for which software is available:

    Machines             Operating Systems       Network Interfaces
    --------             -----------------       ------------------
    Sun SPARC            SunOS 4.1.1,2,3         ie, le, lo
    Vax or Microvax      4.3+ or 4.3-tahoe       de, qe, lo
    Decstation 3100,5000 Ultrix 3.1c, 4.1, 4.2a  ln, se, lo
    Silicon Graphics     All ship with multicast

    There is an interested group at DEC that may get the software
    running on newer DEC systems with Ultrix and OSF/1.  Also, some
    people have asked about support for the RS-6000 and AIX or other
    platforms.  Those interested could use the mbone list to coordinate
    collaboration on porting the software to these platforms!

    An alternative to running mrouted is to run the experimental MOSPF
    software in a Proteon router (see MOSPF question below).


-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 19:45:44 GMT
From:      les@chinet.chinet.com (Leslie Mikesell)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp with zmodem transfer?

In article <laird.761973183@nettle.ecn.purdue.edu>,
Kyler Laird <laird@nettle.ecn.purdue.edu> wrote:

>I've been playing around with ftp.c and sz.c tonight in an exploratory
>attempt to merge them.  It seems doable, but I suspect someone else
>has already done a much better job than I would/could.
 
>I'd appreciate pointers to Unix software that will allow me to get and
>put files from/to remote sites to/from my PC over a dialup using
>zmodem.

If your ftp will let you specify a pipe as the destination of a "get"
you don't need to make any changes to the software.  Sz will accept
standard input if you use a filename of "-" and it can be given a
filename to pass to the receiving program in the environment variable
ONAME. So, the command
  get theirfilename "|ONAME=myfilename sz -"
should do just what you need.  You can probably use macdef to make something
easier to type if you want.  It would be nice to be able to do this
automatically with "mget", but I'm not sure it's worth the trouble since
you often have to pick a different name for the dos restrictions anyway.

Les Mikesell
  les@chinet.com

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 20:07:24 GMT
From:      mstahl@uoft02.utoledo.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Drive help

Does anyone have (or know where to obtain) a packet drive for TCP/IP for
an AE-2 ethernet board (By Artisoft)???
Thanks in advance
John Stahl
Toledo, OH



-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1994 20:07:29 GMT
From:      rbr@dl.ac.uk (R.Bradshaw)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.sys.isis
Subject:   Re: Withdrawal of the unsupported IP multicast HP-UX 9.01 distribution

Jason Zions (jazz@hal.com) wrote:
: They get snotty and whine a lot to HP about shoddy bits and how they'll sue
: if HP doesn't Make It Work. Apparently no one expects Sun to actually do
: that, so the whiners never really get around to doing more than whining on
: the net; with HP's reputation, however, the whiners do things like write
: nastygrams to board members, file lawsuits, etc.

Not at all multicast related, but the folks in control here decided on a
HP super duper network management system, and I've been lumbered with it.
Initial reactions are unprintable, but I've come to the conclusion that
HPs should come with a stress management course thrown in.

I'd welcome any pointers like where to send nastygrams...

: Jazz

--
Rob Bradshaw       Email: R.Bradshaw@dl.ac.uk       [rb685]
Tel:   +44 925 603226        |        Fax:   +44 925 603230
Networks Group, Daresbury Lab, Warrington, WA4 4AD, England

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 94 20:13:06 GMT
From:      pat@tatung1.cs.ttu.edu (Does the machine ever slow down ?)
To:        comp.protocols.tcp-ip
Subject:   SLIP information

Hi,

	I'd like some basic information on installing a SLIP connection, things
like, what software and hardware it takes to install a SLIP connection etc. Is
there some kinda FAQ with reference to SLIP installation or perhaps informative
documents that may be available at any of the ftp sites ?

I'd appreciate any kind of help in this matter.


Thanx in advance

Parthiban

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1994 21:00:24 GMT
From:      rbr@dl.ac.uk (R.Bradshaw)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

Anthony Heading (heading@signal.dra.hmg.gb) wrote:
: Hello.
:    I'm really puzzled by this. We have several hundred hosts on
: a class B ethernet, and a few on a class C FDDI net, the routing
: being done by one of two machines (an OSF/1 alpha and an Ultrix
: DECstation) which have interfaces on both networks. The nameserver
: has multiple A records for these machines - we hope to avoid 
: giving different hostnames to the different interfaces.

Just to confirm; your network looks like this:

                           FDDI ring
             --------------------------------------
                   | Iaf                  | Iuf
                 Alpha                  Ultrix
                   | Iae                  | Iue
             -------------------------------------
                           ethernet

:   I want the two routing machines to use the FDDI network to
: talk to each other, but they steadfastly refuse to use anything
: but the ethernet. I've tried setting the interface metrics (which
: doesn't work) and reversing the boot time configuration order in

You need to set up explicit routes. If you are using static routes,
then try:
on Alpha:	route add Iue Iuf 1
on Ultrix:	route add Iae Iaf 1
If you are running dynamic routing, you'll need to do the equivalent
in gated/routed/whatever. Your netstat tables should then show these
as host routes.

: Any clues, speculation or even hard answers appreciated...
 
: Thanks
 
: Anthony

--
Rob Bradshaw       Email: R.Bradshaw@dl.ac.uk       [rb685]
Tel:   +44 925 603226        |        Fax:   +44 925 603230
Networks Group, Daresbury Lab, Warrington, WA4 4AD, England

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Feb 1994 21:29:49 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over telnet link

In article <ace.34.0012408A@ics.forth.gr> ace@ics.forth.gr (Andreas C. Enotiadis) writes:
> ....
>The short answer is no. You cannot have a slip ling over anything but a serial 
>link.
>...

Wrong.
The short answer is "yes", because many people run SLIP and PPP over telnet
and rlogin links.  It's weird, strange, and probably useful only in
circumstances where administrative conflicts prevent you from doing the
right thing.  People say it's a little harder to make SLIP over rlogin,
since you must ensure that rlogin doesn't think some bytes are out-of-byte
window size or xon/xoff controls.

Remember that as far as the programs on the remote machine are concerned,
the other end of a Telne or rlogin connection is a "serial link." That
was the basic design principle for both protocols.  That is why there
is such a thing as a "pty" or "psuedo-tty".


Vernon Schryver    vjs@rhyolite.com

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1994 23:42:53 GMT
From:      James G. Speth <speth@end.com>
To:        comp.protocols.tcp-ip
Subject:   Simple code for TCP/IP?

I'm looking for some really simple code that implements TCP and IP.  Could
someone point me toward a source?  Basically, I need easy to read, commented
code so I can get into it and really understand what's going on.  Any good
book recommendations would be welcome as well.

I'd prefer separate source files for TCP and IP, but I assume most are that
way.  Also, I don't need a lot of frills, just the basics will do.

Thanks a bunch!
Jim
_______________________________________________________________________________
james speth           email for pgp-compatible public key         speth@end.com
_______________________________________________________________________________
Our request is in keeping with the preference of the community,    -Post Office
as reflected by local ordinance.                                    Sign

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 01:10:23 GMT
From:      pinstall@rc1.vub.ac.be (Installe P.)
To:        comp.protocols.tcp-ip
Subject:   Frame 802.3 class 11 ? What is it ? Why ?

Hello, 

I have this type of Frame from ISDN cards.
The Frame usually found in ethernet cards is of class 1.

The litterature on tcp/ip in the lab doesn't make any reference
of different classes.

Any pointer ?

Thank you very much by advance.

Patrick Installe (pinstall@dbm.ulb.ac.be)

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 01:44:14 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

In article <2kj4h8$phl@mserv1.dl.ac.uk> rbr@dl.ac.uk (R.Bradshaw) writes:
>Anthony Heading (heading@signal.dra.hmg.gb) wrote:
> ...
>You need to set up explicit routes. If you are using static routes,
>then try:
>on Alpha:	route add Iue Iuf 1
>on Ultrix:	route add Iae Iaf 1
>If you are running dynamic routing, you'll need to do the equivalent
>in gated/routed/whatever. Your netstat tables should then show these
>as host routes.

Static routes are ok if you are already using static routes.

If static routes are not being use, then a good solution is to adjust the
"interface metric" on the Ethernet interfaces.  This will cause traffic
to automatic prefer the FDDI interface when it is alive and fall back to
the Ethernet otherwise.  To see how to use interface metrics, look at the
"ifconfig" man page, and whatever configuration file scheme the system
uses to do things like setting the netmask.  In a BSD style network system,
you would set the interface metric in the same places as the netmask.

There are good reasons for and against each of the common choices, static
routes, router-discovery by snooping on routing protocols, and official
router discovery.  The most common choice by a large margin is snooping
on RIP packets, because that's what happens by default on most UNIX boxes.
The most common choice among those who make a conscious choice is static
routes, sometimes for very good technical and administrative reasons and
sometimes for bad reasons related to the common psychological and
socialogical reasons that cause people to want to decide and control things
in the first place.

There is another scheme that works well for multi-homed servers in a mesh
of networks, where you want to prefer the shortest route regardless of
which interface on the server carries its cannonical name.  For example,
you might have an NFS server with 4 Ethernets and a couple of FDDI
interfaces, and all 6 of those networks are connected to a few dozen other
networks, and you want distant hosts to use the nearest interface on the
server and not only the cannoically named interface.  Arrange to have the
server advertise a point-to-point RIP route to its cannonical address from
all of its interfaces.  This can be done with gated, by modifying routed,
or with the routed standard on at least one UNIX vendor's systems.


Vernon Schryver    vjs@rhyolite.com

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 94 12:41:43 PST
From:      D1CAMERO@bcsc02.gov.bc.ca
To:        comp.protocols.tcp-ip
Subject:   Sockets server on solaris w nis+

I am using my own simple TCP/IP client & server on a Sun Solaris
platform and everytime I issue a CONNECT call to the server I
get "connection refused".  These programs work fine on SCO and AIX
and even having the client on the Sun and the server on SCO.
 
Here are the specifics:
 
* I am NOT using gethostbyname or getservicesbyname, I read the host
  IP address and server port from an INI file. (I know, not the
  greatest practise :-º  )
 
* The Sun is running NIS+.
 
* The system administrator doesn't know if there is a firewall :-?
 
* The IP addresses and ports have been inspected a million times.
 
any ideas, please, help, whine....
 
 
 
 
 
 
 
 
 
Don Cameron
Data Management Branch, BC Ministry of Health
2nd Floor Rotherham, Victoria, B.C., V8W 3C8
(604)952-2362  D1CAMERO@bcsc02.gov.bc.ca

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 94 12:09:15 CST
From:      hens@cray.com (Tom Stephens)
To:        comp.protocols.tcp-ip
Subject:   Re: How do multi-homed hosts choose the interfa

In article 9fl@breeze.dra.hmg.gb, heading@signal.dra.hmg.gb (Anthony Heading) writes:
>Hello.
>   I'm really puzzled by this. We have several hundred hosts on
>a class B ethernet, and a few on a class C FDDI net, the routing
>being done by one of two machines (an OSF/1 alpha and an Ultrix
>DECstation) which have interfaces on both networks. The nameserver
>has multiple A records for these machines - we hope to avoid 
>giving different hostnames to the different interfaces.
>  I want the two routing machines to use the FDDI network to
>talk to each other, but they steadfastly refuse to use anything
>but the ethernet. I've tried setting the interface metrics (which
>doesn't work) and reversing the boot time configuration order in
>the hope that this might reorder the routing table (without success
>- netstat -r lists the class B network first always).
>  Resorting to the obvious books, Comer vol.1 doesn't discuss
>DNS style multiple addresses at all, and the 4.3BSD book claims
>routing is a user-level process and the kernel doesn't try to
>do anything smart. This makes me suspect that multiple A records
>are used by trying each address in the gethostbyjingo() structure
>in turn, but there seems to be no way of making the DNS server
>impose order onto those addresses.


You are right, the interface metric doesn't seem to work on the 
ifconfig command, at least on suns.

Assuming this is rip,


We use gated to accomplish this but we also do one more thing.  We add a 
dead end net to the machines, which is a network (usually the slowest 
interface) connected to nothing.  we plug in a thinnet tranceiver with a t 
and 2 terminators.  We call that the official name of the machine.  Here 
is an example...

dead end net	snipe
ethernet 1	snipe-eth1
ethernet 2	snipe-eth2
fddi 1		snipe-fddi

Always try to contact the name snipe.  There is no reason to contact any 
other of the interfaces.  If there are networks in parallel the metrics 
assigned by gated will determine the path taken.  This works great for 
nfs.  Since you are mounting from snipe, not snipe-eth1 etc., you are not 
tied to a specific interface.  The machine can communicate with you on 
any one of it's other interfaces, if one of them goes down.  If you 
were to mount from, say, snipe-eth1, and ethernet 1 went down on snipe, 
your machine would hang, provided it was a hard, uninterruptable mount.   
I can give more details in email to anyone who would like.  


Tom
---

---------------------------------
Tom Stephens
Corporate Computing and Networks, Chippewa Falls, WI
Cray Research Inc.  hens@cray.com


-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 06:27:44 GMT
From:      phoenix@clt.fx.net (Phoenix)
To:        comp.protocols.tcp-ip
Subject:   Re: ACT for networks over TCP-IP - anyone??

Phoenix (phoenix@clt.fx.net) wrote:
: I am looking to see if anyone has ever run ACT! for networks over the 
: Internet... Anyone???
 
: Any suggestions would be greatly appreciated :)

I have more information now that will fill in some of the pieces.  We 
would like to run ACT! for networks over the Internet.  There will be a 
network "server" machine that has the common database sonnected via high 
speed to the net.  Then there will be multiple "workstation" copies 
connected via SLIP or PPP.  The thing I am concerned about is that we are 
taking alook at the actual software now and the thing sets up like it is 
on a plain ol' LAN.  The main database directory will be mounted on the 
net and the others will access the database from  their workstation 
versions.  If someone at a workstation wants to search for a person's 
name and pull up that file, then the search takes place "through" the 
SLIP/PPP connection (i.e., at 14.4 dila-in - 28.8 at best).  I don't want 
this thing to lag like cold molasses (sp).  If there is something like 
this that runs on tcp/ip so that the search query goes to the main 
database, is processed, and the only thing that comes back is the results 
of the query, I would sing at someone's wedding.  OR, if someone could 
recommend a way to get this to run like I want (I ask for so little ;)...

Anyway, I hope this helps get us some suggestions...wish we had time to 
write this one ourselves but the clock runs fast around here.

Thanks for your time again,

Phoenix 


-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 20:18:46 -0800
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   PC/NFS and DNS


I sure hope this isn't covered in a FAQ (what the heck, I looked and
I couldn't find it).  Is it possible to get PC/NFS from Sun to use
DNS instead of NIS?
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 15:26:00 -0500
From:      ebabin@faatcrl.faa.gov (Ed Babin)
To:        comp.protocols.tcp-ip
Subject:   ftp problems under tcp/ip

I'm running SCO ODT 3.0 and connected a PC as a terminal under TCP/IP.
I can telnet into an account but when I try to transfer a file via
ftp, it hangs after about 2000 bytes transfered.  What utilities do
I have at my disposal to check this out or what may be some possible
problems to look into?  

thanks
eddie

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 16:46:48 -0500
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

smckinty@sunicnc.France.Sun.COM (Steve McKinty - SunConnect ICNC) writes:

>In article <CLsA8M.F8n@bluecross.on.ca>, swel@bluecross.on.ca (Steve Welsh) writes:
>> 
>> I can't imagine that there are too many people who would agree
>> that coax is a better alternative than 10bT. TP cable is cheaper,
>> easier to manage and more widely supported than coax. Network
 
>I think it depends a lot on the environment. TP is certainly cheaper
>to install in a building than co-ax, but in an engineering lab
>a coax ring lying under a suspended floor is just as cheap & easy,
>and much easier to expand.
 
>> growth should also be a consideration. Todays 10 node network
>> usually becomes a 100 node network very quickly. Using a hub,
>> is a very easy and effective way to manage and expand a network,

Another thing to consider is wire management, especially in an environment
like an office where you can't just sling wire on the floor (if you
do have wire on the floor coax is hardier).  With discrete offices 
it works out **MUCH** better if you make "home runs" to a single
point such as a computer room or wiring closet.  If you're going to
do this is makes vastly more sense to use TP than coax.  Problems
with coax in this case:
	*much* costlier ( times 2 if you're doing home runs )

	"pocket full of keys" problem similar to token ring, since a
	break in once office brings down the whole segment (you need
	a pocket full of keys to get into each office to check)

	harder to manage at the wire closet than TP - can't put it
	on a frame easily or use patch panels

	coax is ethernet, period.  with TP if you want you can run
	serial over it instead (it works great for us to switch a
	particular office between net and serial just move the
	patch cord in the wiring closet from hub to concentrator)

	the connector is much more fragile (and costly) than TP.
	there are three connectors (three ends on a tee) to pull
	apart.  the cable is heavier and has a 1" lever to yank
	on the card.

of course there are problems with TP too, such as hubs need power.
no power no net.  of course if your power goes out your nodes are
down anyway, but plugs get kicked out of sockets easily in crowded closets.
-- 
=========================================================================
Martin C. Walker                                         martinw@eapi.com
Project Lead                                         Voice (513) 629-2517
Eagle-Picher Industries Inc.                           Fax (513) 629-2449

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 08:38:54 GMT
From:      yang03@poly.edu (Mu-hsien Yang)
To:        comp.protocols.tcp-ip
Subject:   RFC ?

Hi, there,

Does anyone know where I can get RFC ?

Thanks in advance.

Robert

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 94 16:07:02 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a host arp for itself?

In article <1994Feb25.142636.27302@alias.com>, mark@alias.com (Mark Andrews) writes:
> We have a number of SGI boxes here and tcpdump shows that they arp for their
> own ethernet address. Why? Isn't is easier for the machine to lookup its
> own enet address?
> 
> The ifconfig output from one of the hosts is:
> 
> ec0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,FILTMULTI,MULTICAST>
> 	inet 192.XX.XX.XXX netmask 0xffffff00 broadcast 192.XX.XX.255
------------
	It ARPs for the hardware address of any machine using its own IP 
address. The reason is to verify that another station is not accidentally 
(or worse) using it. In a perfect world there would be no need (except for 
the bad guys who are ipso facto not in that world).
        Like to have a little "harmless" fun? Get two unused clients to use
the same IP address. Start a session far away with one, fire up a conversation
far away with the second. Notice that one loses, because the gateway's
ARP cache becomes modified. Be prepared to clear the other remote connection. 
Not recommended to try in a busy place or more than once.
        Joe D.

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 14:14:45 GMT
From:      swel@bluecross.on.ca (Steve Welsh)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?


I can't imagine that there are too many people who would agree
that coax is a better alternative than 10bT. TP cable is cheaper,
easier to manage and more widely supported than coax. Network
growth should also be a consideration. Todays 10 node network
usually becomes a 100 node network very quickly. Using a hub,
is a very easy and effective way to manage and expand a network,
especially now that there are so many cheap, stackable hubs on
the market. 
Being someone who has experienced both 10bT and coax, I would
never opt for coax, given a choice.

I hope this helps!


-- 
Steve Welsh                     \\\///
swel@bluecross.on.ca           / @  @ \   __   __              ___          __
Telecommunications Specialist  |   j  |  [_   /    |_| \    /   |    /\  / / _
Ontario Blue Cross             | (---)|  __]  \__  | |  \/\/   _|_  /  \/  \_|

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 14:26:36 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Why does a host arp for itself?

We have a number of SGI boxes here and tcpdump shows that they arp for their
own ethernet address. Why? Isn't is easier for the machine to lookup its
own enet address?

The ifconfig output from one of the hosts is:

ec0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,FILTMULTI,MULTICAST>
	inet 192.XX.XX.XXX netmask 0xffffff00 broadcast 192.XX.XX.255

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 15:01:15 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

The problem of "multi-homed hosts" has several different implications. The
first thing you have to remember is that while the applications deals with
names, IP deals with interfaces. At the application level, you see:


                           FDDI ring
             --------------------------------------
                   | Iaf                  | Iuf
                 Alpha                  Ultrix
                   | Iae                  | Iue
             -------------------------------------
                           ethernet

because you name the machines, say "alpha" and "ultrix". At the IP level, you
only see Ip addresses. Suppose that you are sending a packet from "alpha":
there is no difference for the IP code between the figure above and:


              FDDI ring
--------------------------------------
   | Iuf                      | Iaf 
 (foo)                      Alpha                  Ultrix
                              | Iae                  | Iue
                         -------------------------------------
                                      ethernet

When presented with the address "Iuf", the IP code of alpha will observe that
it is on the same "network" as "Iaf": the most significant bits of the
address, under the subnet mask, match. It will thus very naturally route it
through the FDDI ring. Similarly, a packet sent to "Iue" will naturally travel
through the Ethernet.

You can indeed change that by a routing instruction, telling the IP code to
route every packet bound to "Iue" through the interface "Iuf" (this is the
command suggested by R. Bradshaw). It has only one inconvenient: you loose the
inherent reliability of having two routes.

In fact, you should rather try to pick the correct address within the
application. One very simple way to solve this is to have an additional entry
in the DNS for "alpha-fddi" and "ultrix-fddi". This is the solution we are
actually using right now in my lab when we want to be absolutely sure of the
way the packets are routed, e.g. when doing comparisons of performances.

The real solution however is to change the "gethostbyname" code so that when it
returns multiple addresses it tries to sort them by "distance". This is very
hard to implement in the general case, for you don't have access to the
distance: your host is not a router. Listening to RIP packets is *not* a
recommanded practice - it will not be very useful if the network uses OSPF.
Besides, RIP distances are essentially hop-counts which will not be terribly
helpful in your case. Also, you should note that even the routers don't know
the "end to end" distance in the general case: real distances are not carried
by EGP or BGP. Thus the estimation of distance will largely be an heuristic,
based on:

 * the local knowledge: the local addresses and subnet masks are known,
   can be associated with a throughput indication. In any case, an address
   on a local subnet should be prefered to a remote address.

 * past statistics: the typical host only has a limited number of
   correspondants. It can keep statistics of the previous connections and
   use them to "rate" addresses.

 * probes: if you are going to send gigabytes, it may make sense to actually
   build the statistic before engaging in the real connection.

Note that there are several usages to this "address ratings": multi-homed hosts
is one, but another is picking one server out of several candidates. Like the
nearest mail gateway out of several MX records of equal precedence...

Last but not least: if you don't know how to chose, picking one at random is
usually better than always picking the same one!

Christian Huitema


-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 14:02:29 +0100
From:      hohmuth@irs.inf.tu-dresden.de (Michael Hohmuth)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

In article <2khb6f$9fl@breeze.dra.hmg.gb>,
Anthony Heading <heading@signal.dra.hmg.gb> wrote:
> This makes me suspect that multiple A records
> are used by trying each address in the gethostbyjingo() structure
> in turn, but there seems to be no way of making the DNS server
> impose order onto those addresses.

This is what I experienced, too, but you can try to override the DNS
based hosts database with entries in /etc/hosts on the two machines.
(Be sure to have the appropriate setting in /etc/svc.conf on both your
Ultrix and your OSF/1 machine, i.e. "hosts=local,bind".)

Michael
-- 
Internet: hohmuth@irs.inf.tu-dresden.de

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 16:20:51 GMT
From:      ahd@epsilon.com (Drew Derbyshire)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Drive help

In article <1994Feb24.150724.1@uoft02.utoledo.edu> mstahl@uoft02.utoledo.edu writes:
>Does anyone have (or know where to obtain) a packet drive for TCP/IP for
>an AE-2 ethernet board (By Artisoft)???

Not a packet driver, but it's useful to know that the they coughed up NDIS
drivers for the cards on CompuServe last April.  I use them with TCP/IP
for OS/2.

You realize, of course, that the cards can also run in NE2000
compatible mode?  You're more likely to find drivers for them.

-ahd-
-- 
Drew Derbyshire			Address:	50 Cambridge St
High Performance Computing			Burlington, MA 01803-4692
Epsilon Data Management		Telephone:	617-273-2630 x6938
						800-225-3333 x6938
Internet: ahd@epsilon.com	Fax:		617-272-1760

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 16:32:35 GMT
From:      ihsan@nmti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Load balancing on multiple paths

In article <762004267.27194@news.Colorado.EDU>, Sam Wilson <ercm20@festival.ed.ac.uk> writes:
> > > ...load sharing is possible with IGRP but not, I beleive with RIP...
> > 
> > You will get load sharing using RIP over equal cost paths. Of course, since
> > RIP uses hop count as a metric, you need to kee a careful eye on your network
> > topology so that you don't create paths of equal hop counts, but different
> > bandwidth (eg) between destinations.
> 
> We use IGRP in our backbone precisely because of this feature - using
> RIP we were getting packet-for-packet load sharing between one ethernet
> hop and one FDDI hop.  Not exactly optimal performance!
> 

Does OSPF support load balancing on multiple paths to remote systems ?
Will it load balance packets for the same TCP connection between two
hosts on LAN A and LAN B in the figure below ?  Would any other
standard/defacto standard routing protocol do it for TCP connections ?

   Net A (LAN)                                     Net B (LAN)
       |     ----------- Net I1(WAN) -----------       |
       +-----|Router A1|-------------|Router B1|-------+
       |     -----------             -----------       |
       |     ----------- Net I2(WAN) -----------       |
       +-----|Router A2|-------------|Router B2|-------+
       |     -----------             -----------       |

I am trying to find a set of HW configuration and protocols so that
no single point of failure between the LANs causes the TCP connection
to go down, not even momentarily and also take advantage of load
balancing on the multiple paths.  Can both these objectives be met ?
Can I meet the first objective without meeting the second objective ?

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 16:33:33 GMT
From:      ihsan@nmti.com (jaleel ihsan)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Is there an OSPF RFC ?

If yes, what is the number ?

Thanks in advance.

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 17:31:14 GMT
From:      jeff@unislc.slc.unisys.com (Jeff Hammett)
To:        comp.protocols.tcp-ip
Subject:   Need OSPF help

Are there any textbooks, articles or tutorials that may help in 
learning/understanding the OSPF protocol described in RFC1247.

I has RFC 1245 and 1246 and am aware of the workshop offered for
at Interop in May.

Thanks,
jeff

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 17:58:07 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: ? PC-based TCP/IP Decode Analyzer?

In article <CLn39s.81s@tandem.com>,
Dave Dilena <daved@carbon.forge.tandem.com> wrote:
>Anyone know of an Analyzer (S/W only) for the PC that does TCP/IP Decoding.  I'm
>looking for inexpensive or free analysis software.  I've tried ETHLOAD but it doesn't
>do decoding does it?  Anyone have experience with General Software's (Redmond, WA)
>Snooper?  It looks and feels right but the TCP/IP Decodes are incorrect in the versions
>that I have used.
>
>Thanks, Dave
>
>
>

We have a product called PacketView that goes for $299 (is that inexpensive
enough?) that should be able to do what you want.  The best way to know is
to try out our demo version of PacketView, available from our BBS at (603)
429-0032 or via anonymous FTP from mv.mv.com:pub/users/klos/pvdemo.zip.  It
supports TCP/UDP/IP, as well as SNMP, IPX/SPX/NCP, VINES, and some other not
so common protocols.  It has symbolic support for node addresses, IP addresses
and SNMP object IDs (and 24-bit vendor IDs too).  It can run on any ethernet,
token-ring or ARCNET adapter with a packet driver or ODI driver that supports
promiscuous mode (most ARCNET adapters can't do this, but most people don't
care about ARCNET).  Let me know if you have any other questions.

Sincerely,

Patrick Klos
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
============================================================================

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 18:08:14 GMT
From:      smckinty@sunicnc.France.Sun.COM (Steve McKinty - SunConnect ICNC)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In article <CLsA8M.F8n@bluecross.on.ca>, swel@bluecross.on.ca (Steve Welsh) writes:
> 
> I can't imagine that there are too many people who would agree
> that coax is a better alternative than 10bT. TP cable is cheaper,
> easier to manage and more widely supported than coax. Network

I think it depends a lot on the environment. TP is certainly cheaper
to install in a building than co-ax, but in an engineering lab
a coax ring lying under a suspended floor is just as cheap & easy,
and much easier to expand.

> growth should also be a consideration. Todays 10 node network
> usually becomes a 100 node network very quickly. Using a hub,
> is a very easy and effective way to manage and expand a network,

But hubs cost money. You can buy a lot of co-ax for the price of
even a cheap hub, and co-ax throughput is higher than some cheap hubs.

> especially now that there are so many cheap, stackable hubs on
> the market. 
> Being someone who has experienced both 10bT and coax, I would
> never opt for coax, given a choice.

For an office environment with PCs where the network grows predictably
and performance isn't an enrormous issue I would agree.

For an engineering lab, or an engineering department, I'll take
thinwire co-ax anytime.

Steve

-- 
Steve McKinty
Sun Microsystems ICNC
38240 Meylan, France
email: smckinty@france.sun.com

(Of course, a look on the back of any new SPARCstation will tell you that
 my employers don't share my opinion!)

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 21:20:42 GMT
From:      vanasse@mips1.info.uqam.ca (Vanasse*Martin)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP router over X.25 wanted

I am in a desparate need of assistance ... help !!

(This is a followup to a request for information I already posted on some  )
(groups, but we've somewhat expanded our search criteria, so here goes...  )

I'm searching for a TCP/IP router operating over X.25 to link two LANs. The
first one is made up of VME 68030 machines running the VxWorks 5.1 realtime OS,
and the second one is a LAN of UnixWare 486 PC's.

The problem is that there doesn't seem to be any X.25 package (using an
intelligent communication board) for the VME / VxWorks combination, and even
much less of a TCP/IP router to go over it. It's driving me mad.

We could always write such a package from scratch, but it's a little beyond
our corporate ability; furthermore, we simply don't have time for such an
undertaking.

So we're searching for a ->hardware<- TCP/IP - X.25 router, that would have
the following specs:
- Ethernet connection with the local LAN;
- Serial port to enable connection to a modem, linking the router to the local
  PDN node.

We could of course put together such a contraption by using a Unix PC with a
X.25 card and sotfware, plus a software TCP/IP router package; however, the
price would be a little steep. That's why we figure an embeded solution might
be less expensive.

The other solutions we've looked at are:
- Using a DOS PC with a PC/TCP package, an X.25 package and a TCP/IP router
  package (hmmmm... to many pieces, and it might be too expensive)

- Adding another VME processor card in the VME machines and running Unix on it,
  along with X.25 and TCP/IP routing packages (might also be quite $$$...)

- I've heard about a "dial up" version of X.25 called X.32, wich is used in
  France on their Transpac network. Is there any product (a hardware router
  would be great) supporting it here ? Remember, we need a TCP/IP router...

So far, we still think that a dedicated hardware X.25 - TCP/IP router would
best suit our needs. But we've been unable to find even a single one so far.

So if you know about a product that could help us, please e-mail or fax me
as soon as possible.

Thanks.

Note:
   The company I work for doesn't have a full Internet connection yet,
   (we can only telnet and ftp) so I'm using a borrowed account for News
   and e-mail access. But unfortunately, this account will expire on
   February 28th. If you can't answer before that, please fax or phone
   me your information. Sorry .... :-(

-------------------------------------------------------------------------------
 -========----   | Pierre Olivier               | Temporary e-mail address:
---========----  | Videoway Enterprises Ltd     | (until february 28, 1994)
----========---  | 2021, Union av.              |
-----========--  | 10th floor                   | vanasse@mips1.info.uqam.ca
------========-  | Montreal (Quebec)            |
-----========--  | H3A 2C1                      | Future e-mail address:
----========---  | Canada                       | (activation date unknown)
---========----  | Phone (514)285-5775 ext. 260 | pierreo@videoway.qc.ca
 -========----   | Fax   (514)285-5702          |
-------------------------------------------------------------------------------


-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 22:06:36 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

In article <2khb6f$9fl@breeze.dra.hmg.gb> heading@signal.dra.hmg.gb (Anthony Heading) writes:
>  I want the two routing machines to use the FDDI network to
>talk to each other, but they steadfastly refuse to use anything
>but the ethernet.

We solved this problem by putting static routes in /etc/gateways.  We're
using SunOS and NIS, so we have to assign distinct names to each interface
address; in the example below, host1 would have names hostN for its
ethernet interface and hostN-fddi for the FDDI interface.  /etc/gateways on
a FDDI machine looks like:

host host1 gateway host1-fddi metric 1
host host2 gateway host2-fddi metric 1

I think if we ran gated instead of routed we could configure the FDDI
machines to broadcast similar host-specific routes, so it wouldn't be
necessary to hard-code them into /etc/gateways.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 22:16:57 GMT
From:      stan.huyge@ClemsonSC.NCR.COM (Stan Huyge)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP specification

In article <arvesen.374.000F3513@tivoli.com> arvesen@tivoli.com (Ralph Arvesen) writes:
>From: arvesen@tivoli.com (Ralph Arvesen)
>Subject: SMTP specification
>Date: Tue, 22 Feb 1994 15:12:20
 
>Does anyone know where I can get the specification for SMTP? Thanks.
>... Ralph Arvesen
>... arvesen@tivoli.com

Sure.  This is available as rfc 821.  There are also lots of other rfc's that 
update it.

Stan

stan.huyge@clemsonsc.ncr.com

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 22:24:57 GMT
From:      lees@austin.ibm.com (Lee Slaughter)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP-Eudora/POP/SMTP

In article <pchanCLq0Mq.2xH@netcom.com> pchan@netcom.com (Pochun Chan) writes:

> .... dialogue explaining link to netcom deleted ....
 
>My questions:
>=============
>10. Is it possible at all to receive email addressed to my slip account? 
>    (i.e. "anything@pchan.slip.netcom.com")  Either receiving it from my 
>    shell account on netcom's UNIX machine or from my PC/SLIP connection 
>    will be fine.
>11. Where do I run the SMTP server as mentioned in #9?  On netcom's UNIX 
>    machine or on my PC.  Is PC Eudora a SMTP server program?  How can I 
>    run it as a SMTP server.  If it is not, can anyone recommend me one 
>    please.  BTW, is Eudora just an off-line mail reader?
>12. What is the Mail User Agent mentioned in #9?

I believe netcom is telling you that they aren't running a POP server.
Read RFC1460 to see what POP does. I believe netcom is telling you
you need a Mail Transfer Agent on your PC to pick up mail; something
like Unix's sendmail. I have no idea what, if any, such critters
exist for PC's running Windows.

This caught my attention because a customer has some FTP (tm) 
client POP software looking for port 109 on a RISC6000 (AIX)
and I can't see that we support it, so in my search I was just
reading RFC 1460 and that's about all I know.

Anybody know if Unix's generally run POP2 or POP3 servers?

lee slaughter
lees@austin.ibm.com

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 22:46:16 GMT
From:      ganzhorn@cisco.com (Charles Ganzhorn)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a host arp for itself?

In article <1994Feb25.142636.27302@alias.com>, mark@alias.com (Mark
Andrews) wrote:
> 
> We have a number of SGI boxes here and tcpdump shows that they arp for their
> own ethernet address. Why? Isn't is easier for the machine to lookup its
> own enet address?
> 
> The ifconfig output from one of the hosts is:
> 
> ec0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,FILTMULTI,MULTICAST>
> 	inet 192.XX.XX.XXX netmask 0xffffff00 broadcast 192.XX.XX.255

The usual reason for ARPing yourself is to ensure that no one else is using
your IP address.

Charles.

--
Charles Ganzhorn                        Email:  ganzhorn@cisco.com
cisco Systems                           Phone:  612-368-8922
Chaska, MN                              FAX:    612-368-9977

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 22:55:29 GMT
From:      ganzhorn@cisco.com (Charles Ganzhorn)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp problems under tcp/ip

In article <2klmsoINN6uc@faatcrl.faa.gov>, ebabin@faatcrl.faa.gov (Ed
Babin) wrote:
> 
> I'm running SCO ODT 3.0 and connected a PC as a terminal under TCP/IP.
> I can telnet into an account but when I try to transfer a file via
> ftp, it hangs after about 2000 bytes transfered.  What utilities do
> I have at my disposal to check this out or what may be some possible
> problems to look into?  
> 
> thanks
> eddie

If you have an analyzer, get it on the wire and watch the transfer.  You'll
see one or the other of the systems either stop talking or re-transmitting
because the other side sent something unexpected.  You'll probably end up
digging into the TCP header to figure this one out.

If you don't have the analyzer or if you want to do some preliminary work
before  breaking one out, you could try FTP connections from and to
different machines and see if you can narrow it down to one box or the
other misbehaving.

Charles.

--
Charles Ganzhorn                        Email:  ganzhorn@cisco.com
cisco Systems                           Phone:  612-368-8922
Chaska, MN                              FAX:    612-368-9977

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1994 23:04:29 GMT
From:      camou@csid.gmeds.com (Mario Camou)
To:        comp.protocols.tcp-ip, robert@Sharenet.Edu ()
Subject:   Re: 2 class c's can't talk?

In article <2kdjfk$m6a@kasey.umkc.edu> robert@Sharenet.Edu () writes:
>I have two machines  (a.b.c.250 & a.b.c.251)  From either I can see anywhere
>I can see either from  anywhere, however I can not see the other machine
>from the other (if that makes sense) neither ping, telnet, traceroute
>find each other.  Any ideas ?
>thank you very much,    -robert
> 
>   robert@pei.sharenet.edu

Do a 'netstat -r'. You should see an entry something like:

network                   *                         UN         0   6655 eth0

If you don't have it, add the following line to your /etc/rc.net
(that's in SLS, I think the later versions have an rc.net1 and
rc.net2, don't know in which one it goes):

route add -net network

For this to work, you need the following entry in your /etc/hosts file:

network  a.b.c.0

Hope this helps,
--
Mario Camou / EDS Mexico Client-Server Integration Team
MS-DOS is a bug. MS-Windows is a bug with a Graphical User Interface.
------------------------------------------------------------------------------
My opinions are only mine, mine, MINE!

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Feb 1994 23:08:52 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a host arp for itself?

In article <1994Feb25.142636.27302@alias.com> mark@alias.com (Mark Andrews) writes:
>We have a number of SGI boxes here and tcpdump shows that they arp for their
>own ethernet address. Why? Isn't is easier for the machine to lookup its
>own enet address?
> ...

Sending the ARP packet out cannot tell the machine its own address.  It
must already know its address in order to send the packet.  ARP is not
RARP.

BSD style network stacks do this, and I think it's recommended somewhere
in the HR-RFC's.  Such an announcement serves several purposes:

    - if some other box on the wire is using the same IP address, it
	will notice and log the problem (assuming common BSD style network
	code).  Some boxes will try to defend their use of the IP address
	by periodic ARP announcements of their own.  This is often enough
	to keep TCP links sufficiently alive so you can reach the
	appropriate common database machine and fix the error.

    - the box might have been rebooted with a different Ethernet MAC
	address, perhaps after board swap.  Without such an announcement,
	you would have to wait until other machines aged-out the old MAC
	address from their caches, which is literally forever in some
	systems.


Vernon Schryver    vjs@rhyolite.com

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1994 12:48:21 -0600
From:      hlg9696@tamsun.tamu.edu (Han Lin Goh)
To:        comp.protocols.tcp-ip
Subject:   Multicast IP

Looking for public domain or commercial DOS/Windows TCP/IP packages that
implement multicast IP. Various SUN platforms already have that support but
what about PCs?

Any related information is appreciated. Thank you.



-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 94 03:12:54 GMT
From:      wrmerkel@gibbs.news.oit.unc.edu (William Merkel)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for DOS/Windows Product Survey

Hey netters, I'm working on a project at UNC which mainly entails a
competitive analysis of DOS/Windows TCP/IP packages that are out there
today.  I'd like to get some of your opinions as to what you like and
dislike about products such as Chameleon, Super TCP, Connect II, etc.  Any
help will be greatly appreciated and will surely assist in my coming
graduation.  

Thanks!
Bill Merkel
merkel@uncmvs.oit.unc.edu
wrmerkel@gibbs.oit.unc.edu
or as above

*-<8^/)--

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Feb 1994 13:00:12 GMT
From:      anntoh@gallery.ncb.gov.sg (Ann Toh Hwee Choo)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Info


Just wondering if anyone can provide me with a good ftp source for info.
concerning TCP/IP stuffs. Can get here and there but all seem to be pretty
loose info.

Thanks in advance.


-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1994 14:20:43 GMT
From:      cplai@csie.nctu.edu.tw (unknown)
To:        comp.protocols.tcp-ip
Subject:   client-server integer problem ...

Hi,
   I have a client/server program based on TCP/IP, at server side(RISC machine),
I pass an integer to client(SCO unix), the strange thing is,
If I pass the int less than 256, client side get 0, if greater than 256, some
big number comes out.
For example, the server send 553, the client gets 687996928, 
and 553 = 00000229(in hex)
    687996928 = 29020000(in hex)

I know this has to do with byte order problem, but I don't know how to fix it.
Good sample codes(both on client and server) will be appreciated.
The situation will be client side is Intel-based unix,
and server side is either Intel-based unix or RISC machine.

Please E-mail me directly, thanks.

scott
.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1994 17:24:58 GMT
From:      whoswho@hobbes.mitre.org (Who's Who on the Internet)
To:        comp.protocols.tcp-ip,alt.cul.ture.usenet,alt.net.personalities,ne.nearnet.general,ny.nysernet,soc.net-people,alt.dcom.telecom
Subject:   Final CFN: Who's Who on the Internet

Final Call for Nominations:

                      Who's Who on the Internet


You have seen the reference books at your local library, listing luminaries
in a variety of industries, but none yet of the Net community.  This is not
intended to be a White Pages directory, but a reference source of the
people who have (and continue to) shape the Net.

The individuals to appear in this directory will be selected based on
nominations by the Net community.  Once selected, they will be directly
contacted for biographical information if they desire to be included.  

The final publication form has not yet been decided, but will most likely be
available for searching and/or browsing on the Net as well as in print form.

To nominate a Net personality, simply fill out the short form below and
e-mail it to whoswho@hobbes.mitre.org by 6 March 1994.  Feel free to
nominate anyone, no matter how small their claim to fame (i.e., first
person to access the Net from the Galapagos island, maintainer of a cool
list/archive, first administrator of a Net node in Antarctica, developer of
<favorite Net tool/protocol here>, etc.).  And yes, you may nominate yourself.

Questions about the project should be e-mailed to whoswho-q@hobbes.mitre.org.  
Please note that questions sent to the nomination address will NOT be answered.

Multiple nominations by one person is allowed, but each must be submitted
in a separate e-mail.

:-) :-) :-) :-) :-) :-)  Detach Here (-; (-: (-: (-: (-: (-:

Name:
E-mail:
Claim(s) to fame:


------------------------------------------------------------
    E-mail completed form to: whoswho@hobbes.mitre.org
============================================================

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Feb 1994 18:35:07 +0000
From:      andy@legion.demon.co.uk (Andy Leigh)
To:        comp.protocols.tcp-ip
Subject:   Hardware fault on Wellfleet BLN

Hi,

I've also posted this in comp.sys.wellfleet, but I thought I'd try here
as well. It seems our Wellfleet BLN has developed a fault, and it won't
boot up properly. I haven't seen the fault (I got rung at home) but I've
got Usenet access from home hence the post.

We have an hardware contract, but we don't seem to be able to raise
anyone, so if any one has a contact in the UK who might be able to look
at the problem over the weekend, we'd be grateful for any advice!

It seems the controller card (the one with the console port) is pulling
down the rest of the system. Without it, of course the box won't boot,
but with it the LED's seem dim.

Absolutely *any* advice would be very gratefully received!


Andy
====

|     For evil news rides post, while good news baits -- John Milton     |
 +------------------------------+-----------------------------------------+
| Andy Leigh, 34 Castle Drive, | andy@legion.demon.co.uk   } Personal    |
| Kemsing, Kent, England, UK.  | andyl@cix.compulink.co.uk } Personal    |
| TN15 6RW  [+44 0959 522508]  | al1071bh@bh.bbc.co.uk     } Work(RFC822)|
 +------------------------------+-----------------------------------------+
|       legion is not associated with any other demon dial-up site       |
|  Any opinions expressed herein are my own and not those of my employer |

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1994 20:28:34 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths

In article <id.4Q971.022@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
    Does OSPF support load balancing on multiple paths to remote systems ?
    Will it load balance packets for the same TCP connection between two
    hosts on LAN A and LAN B in the figure below ?  Would any other
    standard/defacto standard routing protocol do it for TCP connections ?
    
Yes, yes, and yes, IGRP, RIP, and ISIS _can_ all load balance in this
configuration.  Note that for some of them (OSPF included) it depends on
how you configure the protocol.  OSPF does equal cost load balancing, so
you would need to be careful about how you assigned costs to links.

    I am trying to find a set of HW configuration and protocols so that
    no single point of failure between the LANs causes the TCP connection
    to go down, not even momentarily and also take advantage of load
    balancing on the multiple paths.  Can both these objectives be met ?
    Can I meet the first objective without meeting the second objective ?

That depends what you mean by "go down".  If you mean that you will not
drop packets, no, there's no way to guarantee that.  All routing protocols
(so far ;-) have a significant convergence time.  So you would at least see
retransmissions.

If you're trying to avoid breaking the TCP connection, then any routing
protocol that converges within about 30s will work.  That leaves OSPF and
ISIS (and soon EIGRP).  You could also get IGRP to do this, using a "highly
non-standard configuration".

Load balancing can be done in any case and is orthogonal to the convergence
time.

Tony

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1994 20:29:40 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Is there an OSPF RFC ?

In article <id.5Q971.E72@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
    If yes, what is the number ?
    
RFC 1247




-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1994 08:33:26 -0500
From:      sunborn@news.delphi.com (SUNBORN@DELPHI.COM)
To:        comp.protocols.tcp-ip
Subject:   How does one apply for a tcp/ip address ?

If anyone could either email me or fax me at 203-549-5039 with information
as to how to apply for a tcp/ip address , it would be apprecaited.  

James McGovern
Command Systems



-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1994 02:28:17 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a host arp for itself?

In article <1994Feb25.142636.27302@alias.com> mark@alias.com (Mark Andrews) writes:

   We have a number of SGI boxes here and tcpdump shows that they arp for their
   own ethernet address. Why? Isn't is easier for the machine to lookup its
   own enet address?

Paranoia.  Good idea to make sure no one else is using your address,
otherwise massive confusion occurs.

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Feb 1994 03:09:02 GMT
From:      skolos@gemini.csil.sfu.ca (Chester)
To:        comp.protocols.tcp-ip
Subject:   SLIP with OS2?

HI

I am currently using winsock.dll with windows to connect to a unix host,
but I would like to run a native OS2 app to connect. Could someone point 
out a good program that I can use or some where to start looking?

THANKS

--CHESTER
aka CHET SKOLOS
    skolos@sfu.ca


-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Feb 94 14:16:00 PDT
From:      Joe Ford <fordjb@wln.com>
To:        comp.protocols.tcp-ip
Subject:   Re: HOW : dynamic IP addr assign on Dial-in SLIP


In article <CLKGL0.BED@wang.com>, <michelg@wang.com> writes:

> 
> On an AIX RS6K, we want to be able to talk to a number of PC systems running
> SLIP. All these systems will establish communications by DIAL-IN. Can I get 
 the AIX system to understand that various different IP addresses will be coming
> in on the same (serial) network interface. A solution where all the PC's are
> assigned the same IP address is no good ?
> 
> Thanks,
> 
> 
> ---
> Michel Godfroid              Wang belgium            michelg@wang.com
> 
Michel;

I dial into an RS6000, using both SLIP and PPP and get a dynamically-assigned 
IP address each time, but the address is handled by the terminal server which 
manages the modem pool. You might look into using a Zylogics terminal server 
for the port and IP address management.

Joe Ford 

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Feb 94 14:23:47 PDT
From:      Joe Ford <fordjb@wln.com>
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet - Where?


In article <2k98h9$b8v@nova.umd.edu>, <COATES@UMUC.UMD.EDU> writes:

> 
> Where can I ftp the NCSA Telnet server PD program.  Please e-mail direct,
> TIA.
> 
>  ----------------------------------------------------------------------- 
>  |                            Elliott Coates                           | 
>  |            coates@umuc.umd.edu        coates@umuc.bitnet	       |
>  |                            washingtoon, dc                          |
>  -----------------------------------------------------------------------
Elliott;

Try ftp to

ftp.ncsa.uiuc.edu

I'm not sure about directory info, but look around and you're likely to find 
what you're looking for. Another possibility is

ftp.cica.indiana.edu

Good luck

Joe Ford >fordjb@wln.com>


-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1994 12:54:12 GMT
From:      ucbked@athena (Earl H Kinmonth)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.windows.ms,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   selective appearance of network group under windows

I run WINQVT using Novell odi drivers under Windoze 3.1.  I offer a
bootup menu that allows Windoze with and without the network drivers in
order to maximize the memory that is available to DOS programmes spawned
from Windoze.  Because the network.grp containing WINQVT always appears,
there are users (myself included) who try to run WINQVT when the network
drivers have not been loaded.  This hangs the machine.

Is there an elegant (simple) way of causing the network.grp file to
appear only when the proper drivers have been loaded?

I could, of course, have two progman.ini files with and without the
network.grp and use a bat file to select the appropriate one.  That is
not what I would call an elegant approach....

Please e-mail a copy of any posting you make in response to this.
-- 
earl h. kinmonth, centre for japanese studies, university of sheffield,
sheffield, england s10 2tn  jp1ek@sunc.sheffield.ac.uk

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Feb 94 21:07:16 PST
From:      FelineGrace@cup.portal.com (Dana B Bourgeois)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/NFS and DNS

PC-NFS use DNS?  Maybe in the 6.0 release.  Right now it NIS.  What
I did on my server is put all the PC-NFS systems in the NIS table and
enable DNS.  The PCs are guarenteed to find their PCNFS server and will
use DNS for any other host lookup.  Works fine so far.

Dana Bourgeois

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 94 18:42:37
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: "What's the RFC number for XXXXX"

Note that anyplace that serves as an archive for the RFCS almost certainly
contains a file called "rfc-index.txt" in the same directory, which lists
the numbers, names, authors, and some other data about every RFC that has
ever been written, in reverse chronological order...

BillW


-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Feb 1994 18:27:25 GMT
From:      systex@hookup.net (Lawrence Levin)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocals.tcp-ip
Subject:   LAN Workplace for DOS & NFS Client for LAN Workplace for DOS

We are looking for a complete set of LAN (tcp/ip) software for our clients.  
Having worked extensively with all of the shareware/freeware/PD stuff around, 
I am more than pleased with it.  Unfortunately there doesn't appear to be a 
comparable NFS product available to fulfill a key need.  We tried the new AIR 
suite of LAN software.  Costs alot and doesn't even work.  I've been reading a 
lot of neg. info on alt.winsock re: Chameleon.  Sounds like another mess for 
lots of money.  Novell offers their LAN Workplace for DOS software which has 
everything.  They also know how to sell & support the market.  Any feedback 
from actual experience would be appreciated.
Our environments are typically a SCO server with both terminals & PC's. The PC 
users need _good_ terminal emulation software and also a simple NFS connection 
so that they can access DOS data/programs on the server.  Performance must be 
as good as Trumpet/WINSOCK, WS_FTP ... well you get the picture.  Any help 
would be appreciated.
TIA

Lawrence Levin

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 14:21:11 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 Address resolution for TCP/IP networks.

In article <2kt97r$sek@olivea.atc.olivetti.com> rajn@sassella.ico.olivetti.com (Rajendran) writes:
>
>We are currently trying to implement an address resolution package
>for TCP/IP over X.25 and to achieve this objective
>I have recently acquired a document about Address resolution
>over X.25 Networks (xarp) called "X.121 Address resolution for IP 
>Datagram Transmission ove X.25 Networks." by Carl-H.Rokitansky,
>Fern University of Hagen , dated July 1990.In the status of the 
>document it says "This draft will be submitted to the RFC editor 
>as a standards document." However,looking through the list of RFC's I am
>unable to find the corresponding standard.Therefore, I would 
>like to know 

   The only way you are going to be able to "arp" something like
   IP addresses to X.121 addresses is IF your users have total
   control over the addressing structure for BOTH their IP network,
   (meaning this is a private network) and their X.121 addresses.

   If you can't control BOTH your Internet and X.121 address, you need
   to do what the commercial packages do and create a mapping table
   which maps X.121 addresses to IP addreses.  

   It sure would be nice to be able to algorithm this, but I don't see
   it happening on any multi-national PSDN soon.  

   Barring that, you could have a central authority which contains all
   this mapping....but since users may change X.25 network providers
   in some countries, I can see an administrative nightmare in doing
   this, unless your tcp/ip--X.25 Network is big enough to make it
   worth putting all this info on a single machine rather than in
   tables on every machine.



>
>	4. What is  the position of this document vis-a-vis 
>	   RFC-1236 ( IP to X.121 Address Mapping for DDN ).
>
    Mapping in the DDN is easy, since they control both their
    IP and X.25 DTE addresses.  There is just a simple algorithm for
    converting between same.



-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 01:14:17 GMT
From:      wchen@netcom.com (Wen Chen)
To:        comp.protocols.tcp-ip
Subject:   Avoid/Recover from "Bus Error"

 
I am developing a client/server system that relies on socket communication on 
TCP/IP.  The processes run great, most of the time, except once a while they 
get themselves into a "Bus Error".  The client sides typically fail after they 
lose their connection.

My questions: is this problem preventable?  If not, how can the client 
process recover from the connection failure, instead of exiting the program?

thanx,

wayne

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 01:23:08 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

In article <2khb6f$9fl@breeze.dra.hmg.gb> heading@signal.dra.hmg.gb (Anthony Heading) writes:
>Hello.
>   I'm really puzzled by this. We have several hundred hosts on
>a class B ethernet, and a few on a class C FDDI net, the routing
>being done by one of two machines (an OSF/1 alpha and an Ultrix
>DECstation) which have interfaces on both networks. The nameserver
>has multiple A records for these machines - we hope to avoid 
>giving different hostnames to the different interfaces.
>  I want the two routing machines to use the FDDI network to
>talk to each other, but they steadfastly refuse to use anything
>but the ethernet. I've tried setting the interface metrics (which
>doesn't work) and reversing the boot time configuration order in
>the hope that this might reorder the routing table (without success
>- netstat -r lists the class B network first always).
>  Resorting to the obvious books, Comer vol.1 doesn't discuss
>DNS style multiple addresses at all, and the 4.3BSD book claims
>routing is a user-level process and the kernel doesn't try to
>do anything smart. This makes me suspect that multiple A records
>are used by trying each address in the gethostbyjingo() structure
>in turn, but there seems to be no way of making the DNS server
>impose order onto those addresses.
>
>Any clues, speculation or even hard answers appreciated...
>
>Thanks
>
>Anthony
>-- 
>
>------------------
>AJR Heading, DRA UK

BIND 4.9.2 includes code to sort answers to gethostbyname queries. This
is due for release RSN. In this case you would add the fddi network
before the enthernet network in resolv.conf of the two machines.

e.g. sortlist 130.155.160.0/255.255.240.0 130.155.0.

In this case subnet 160 is given preferance over the rest of 130.155 and
they are given preferance over the rest of the world. The sortlist
directive supports up to 10 {sub}networks.

Mark

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1994 08:15:06 +1030
From:      simon@wraith.internode.com.au (Simon Hackett)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over telnet link

ace@ics.forth.gr (Andreas C. Enotiadis) writes:

>The short answer is no. You cannot have a slip ling over anything but a serial 
>link.

The correct short answer is yes. I'm logged in typing this via a slip
link from a pc running FTP Software's PC/TCP, over a modem to 
an Annex terminal server, which is doing an rlogin to a sun that is
running slip-4.0 quite happily over the rlogin connection. 'been doing
it for years, literally. you Just have to try a few slip packages on the
sun till you find one that tolerates connection via pty's. ANd make
sure that the login connection is 8 bit clean. I use rlogin to get the
8 bit clean-ness out of it, you should be able to use telnet but 
you'd have to make sure it was a binary connection with the escape
character processing disabled.

Simon
-- 
      Simon Hackett,  Internode Systems Pty Ltd, Adelaide, Australia
      simon@internode.com.au   Ph +61 8 373 1020  Fax +61 8 373 4911

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 01:30:25 GMT
From:      ihsan@nmti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths

In article <2kobdi$d51@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
> 
> Load balancing can be done in any case and is orthogonal to the convergence
> time.
> 

That sounds good but what about the (IP?) rule that if there are two (or more?)
routers connecting two networks, then the second router must go in backup mode
until the primary (active) routers fails.

Also note that in my original posting I mentioned load balancing for the SAME
TCP connection.  So, using proxy ARP if the host on Net A establishes Router A1
as the ethernet recipient of the IP datagrams for the TCP connection to the
host on Net B, then how will Router A2 share the load of sending the IP
datagrams from Net A to Net B for THE TCP connection ?

   Net A (LAN)                                     Net B (LAN)
       |     ----------- Net I1(WAN) -----------       |
       +-----|Router A1|-------------|Router B1|-------+
       |     -----------             -----------       |
       |     ----------- Net I2(WAN) -----------       |
       +-----|Router A2|-------------|Router B2|-------+
       |     -----------             -----------       |

I very much appreciate your expert advice.

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 01:31:27 GMT
From:      welsbyp@qdpii.ind.dpi.qld.gov.au (Peter Welsby)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.windows.ms,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: selective appearance of network group under windows

In article <2kq55k$675@agate.berkeley.edu> ucbked@athena (Earl H Kinmonth) writes:
>From: ucbked@athena (Earl H Kinmonth)
>Subject: selective appearance of network group under windows
>Date: 27 Feb 1994 12:54:12 GMT
 
>I run WINQVT using Novell odi drivers under Windoze 3.1.  I offer a
>bootup menu that allows Windoze with and without the network drivers
 
>Is there an elegant (simple) way of causing the network.grp file to
>appear only when the proper drivers have been loaded?

Not to my knowledge.  You could, of course, write a program for us both...

The difficulty is that Windows records all info about defined (and always 
available) groups in PROGMAN.INI.  All listed groups will always appear.  The 
contents of each group is defined (and is always available) in group_name.GRP. 
 All included program items will always appear.

The answer is to run a batch file which tests for drive availability before 
the program item can run.  Windows, of course, offers absolutly NO BATCH 
language capability.  I looked at some of the available Windows batch language 
programs (e.g. CATCH), but with no joy.  They allow windows to be resized etc, 
but there is no way to perform basic DOS batch operations.

>I could, of course, have two progman.ini files with and ...
>That is not what I would call an elegant approach....

Sounds downright disasterous to me.  Make a change to one setup, and lose it 
for all others...

pete
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
Peter Welsby (Senior Lab Technician)    email: welsbyp@qdpii.ind.dpi.qld.gov.au
Computer Operations Support             voice: +61-7-877-9554
Ag.Chem, Dept.Primary.Ind, Meiers Rd,   fax  : +61-7-371-6436
INDOOROOPILLY, QLD, 4068, AUSTRALIA

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 94 08:45:16 MST
From:      u-mwong%peruvian.cs.utah.edu@cs.utah.edu (Michael Wong)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Looking for Sample FTP Client/Server Source Code


   Does anybody know of an FTP site where I can get sample source code for an 
FTP client and and FTP server?  I'd like to see how they work on a PC...but
sample code on any platform will do.  I'd appreciate any help...

-Mike
-- 
Michael Wong 
u-mwong@peruvian.cs.utah.edu
University of Utah

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 05:37:43 GMT
From:      kees@$LOGNAME@ee.ualberta.ca (Kees denHartigh)
To:        comp.protocols.tcp-ip
Subject:   cisco term server /slip&ppp options

We have a few cisco terminal servers here of which I know
very little and have no admin access to. They seem to
have ppp and slip options which when invoked request
host name. Once given one there is a passwd prompt.
Is this passwd from the host or from the terminal server?
also if I have slip or ppp admin capability on a net host
that  I can access from this terminal server is there a possibility
of running slip or ppp through the terminal server?
I have tried to an HP 735 machine using ppp but the ppl log
states that the dev cannot be accessed due to the fact that
I am actually coming in on a pty

--
Kees denHartigh                         kees@ee.ualberta.ca 
Unix System Admin.      Electrical Engineering Digital Labs     
University of Alberta 238 Civil Elect   Voice (403)492-5421
Edmonton, Alberta Canada                Fax   (403)492-1811

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 94 23:45:56 -1000
From:      sabax_s1@verifone.com (S Sabapathy, Bangalore Ph: +91-80-226-9920)
To:        comp.protocols.tcp-ip
Subject:   Help needed - Thruput handling in X.25

                        Thruput handling in X.25
                        ------------------------

How is the thruput class negotiation facility handled in X.25 packet
layer?

Since many SVC's share the same link layer, how does the DTE handle a
situation like SVC1 negotiating for a thruput of 9600bps and SVC2 for
a different thruput of 64000bps.

If it can be handled, at what point of time does the DTE switch the
speed. Whether it switches after receiving a call confirmation packet
or ....?

How does it affect an established PVC?

Any information in this regard, will be highly appreciated.

Please email to sabax_s1@blrv1.verifone.com.

Thanks in advance
Sabax


-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 17:08:38 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question

mrouted 3.1 (which is what the question refers to) requires coordination between
the user space daemon that now keeps info that must be tracked by the equivalent
 in the  kernel - this requires more deep mods that previously ...

it would be very nice if those keen and excellent folks like silicon grafix and 
"some microsystems" etc
that support multicast would move to this version/capability....lack of pruning
will cause the internet to melt badly...

iof course the integration of multicast routing into router vendor products
would help even more (by removing the requirement for tunnels) and doesn't
involve the same size installed base (or inertia!) and is on the way (proteon
have, cisco will, so anyone who doesnt, better have) -

the pruning (or problem caused by lack of it) is specific to
dvmrp, and is not a problem with (proteon's) mospf, or the proposed
Protocol Independent Multicast (PIM, cisco say they will have)...
though mospf may have other problems, and we have yet to see how
pim can work in a large internet...

-- 
jon crowcroft (hmmm...)

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 17:12:27 -0600
From:      us312545@mmm.com (Robert Brandt)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting a non-standard netmask

Chris Tanner (tannerc@cu18.crl.aecl.ca) wrote:
> Hi All
 
> We have a number of ethernet networks radiating out from a Wellfleet
> router. We have a Class B IP address block assigned to our organization,
> but generally configure our ethernet lines (and subnets) with a class C
> net mask. 
 
> We wish to set up a subnet that can have 500 hosts on it (instead of the
> regular 254 hosts using a class C netmask). From the reading that I have
> done, I assume that we set the netmask to 255.255.254.0, and assign 2
> adjacent subnets (in this case 116 & 117) to that subnet. 
 
> We were told that we cannot do this if subnet's 0 & 1 are in use
> elsewhere in the network. I find this hard to believe. Can anybody
> confirm this statement and/or explain it too me.
 
> Thanks very much.
 
> Chris
> -- 
> Chris Tanner                  Email: tannerc@CU18.CRL.AECL.CA
> AECL Research                 Phone: (613) 584-3311 X4053       
> Chalk River, Ont.             FAX:   (613) 584-1082
> Canada, K0J 1J0


Chris,

We looked at this very issue, i.e. different size subnets for different size
networks.  We also use Wellfleet routers.  One thing you should know is that if
you are using RIP as your routing protocol then you MUST use the same subnet
mask for the whole Class B network, i.e. all your subnets need to be of size
512, 256, 128, 1024, or 4, etc.  Based on the RIP RFC, you cannot have half of
your networks of size 256, some of size 4, etc.

Subnets 0 and 1 have nothing to do with it.
It is true, however, that subnet 0 and subnet 255 (in a subnetted Class B using
256 node subnets) should not be used for networks, just as the first and last
node on the subnet are not used for explicit addressing, i.e. node 0 and 255.

We migrated to OSPF to allow for different size subnets in a Class B.

Regards,

Bob Brandt
3M Company
bbbrandt@mmm.com

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 08:18:24 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths

In article <id.I7C71.9GK@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:

    > Load balancing can be done in any case and is orthogonal to the
      convergence time.
    
    That sounds good but what about the (IP?) rule that if there are two
    (or more?)  routers connecting two networks, then the second router
    must go in backup mode until the primary (active) routers fails.
    
? There's no such rule.  Perhaps you're thinking of a bridge?

    Also note that in my original posting I mentioned load balancing for
    the SAME TCP connection.  So, using proxy ARP if the host on Net A
    establishes Router A1 as the ethernet recipient of the IP datagrams for
    the TCP connection to the host on Net B, then how will Router A2 share
    the load of sending the IP datagrams from Net A to Net B for THE TCP
    connection ?
    
Don't use proxy arp.  Point all hosts at router A1.  Configure the cost of
I2 such that I1 = I2 + A.  Thus, A1 sees two equal cost paths and can load
balance over both paths.

       Net A (LAN)                                     Net B (LAN)
           |     ----------- Net I1(WAN) -----------       |
           +-----|Router A1|-------------|Router B1|-------+
           |     -----------             -----------       |
           |     ----------- Net I2(WAN) -----------       |
           +-----|Router A2|-------------|Router B2|-------+
           |     -----------             -----------       |

Tony

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1994 11:39:55 +1300
From:      craigw@iconz.co.nz (Craig Whitmore)
To:        comp.protocols.tcp-ip
Subject:   Routing between domains

Can someone help me please
I have a slip setup for a machine that is in another domain
marvin.creative.co.nz (202.36.129.195)
and he connect via slip to this machine 
iconz.co.nz (202.14.100.1)
Normally when someone else slips in (says *.iconz.co.nz (202.14.100.*)
he can ping/connect outside us (via 202.14.100.254) and connect to the
rest of the internet, but marvin.creative.co.nz cannot (it gets to 
202.14.100.254 (our PC router) and the traceroute/ping etc stops
(our router is connected via slip liek to someone else

a bit liek this

University--ROUTER--sliplink--pcrouter--iconz.co.nz-rest of our network
                                            |
                                        sliplink
                                            |
                                     marvin.creative.co.nz
                               (and the rest of *.creative.co.nz)

can someone tell me what routing/arp etc commands I have to do to allow
*.creative.co.nz (202.36.129.*) or even marvin.creative.co.nz 
(202.36.129.195) to get out of domain on both sides please
(iconz.co.nz runs SunOs, marvin runs AIX)

      ______
      \/oo\/
.---oOO-\/-OOo------------------------------------------------------------.
|Craig Whitmore - craigw@status.gen.nz      - Status BBS                  |
|               - craigw@midland.co.nz      - Midland Internet Services   |
|               - craigw@mserve.kiwi.gen.nz - Advanced Systems            |
|               - craigw@iconz.co.nz        - Internet Company of NZ      |
`-------------------------------------------------------------------------'


-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 10:35:50 GMT
From:      gdmr@dcs.ed.ac.uk (George Ross)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: 10BaseT connected directly?

In article <2kleqe$20r@uk-usenet.uk.sun.com>, smckinty@sunicnc.France.Sun.COM (Steve McKinty - SunConnect ICNC) writes:
> ... co-ax throughput is higher than some cheap hubs.

That is only true if "cheap" = "broken".  Any properly-working 10baseT hub
should repeat at full medium-speed.

Our experience of both 10base2 and 10baseT is that the cost of the hubs is
more than made up for by not having to waste time trying to fix unreliable
networks.
-- 
George D M Ross, Department of Computer Science, University of Edinburgh
     Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Mail: gdmr@dcs.ed.ac.uk      Voice: 031-650 5147      Fax: 031-667 7209

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 13:42:55 GMT
From:      jeg@gronja.kymmene.fi
To:        comp.unix.aix,comp.unix.admin,comp.security.unix,comp.protocols.tcpip
Subject:   Once more: How do I log outgoing TCP/IP-connections ?

I posted this question almost week ago, but there were very few responses and 
those suggestions weren't suitable for me (I hope I don't need ident server).
I received message that there are others who want to know solution of this 
problem. So I'll try again and this time I'll post this message to couple more 
news groups. If this can't be done, that infomation is also usefull.

> We have access to the Internet through one RS/6000 (AIX 3.2.4). I would 
> like to keep log when and where users have connections out of our network. 
> My goal is that if I get call: "Somebody is hacking us from your network" 
> I could trace who he is. I'd like have tools log which indicates that user 
> kilroy started telnet (or ftp) session to host any.host.in.net at 23.2.1994 
> 23:01:11 and ended session at 23.2.1994 23:43:17.
> 
> I could log use of telnet and ftp command (with parameters), but that wouldn't 
> be very reliable way to do logging (you can choose host with open-command).
 
> Can I do logging with normal AIX-commands, can I get something with FTP or 
> should I buy something ? I'll be thankfull of any advices.

Jan-Erik Gron           E-mail: kymmene.kh.gronja@elvi.vtkk.fi
Kymmene Corporation     Fax:    +358-51-402 2241
Finland                 Phone:  +358-51-402 2314

-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 14:05:52 GMT
From:      tkuhn@cip.informatik.uni-wuerzburg.de (Thomas-Albrecht Kuhn)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP - Programming Interface

hi,

do anybody know a programming-interface in C, C++ or Pascal, so that you can
access the Internet-application within you on programms?

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 14:07:43 GMT
From:      ling@dutepp9.et.tudelft.nl (Ling Thio)
To:        comp.protocols.tcp-ip
Subject:   Re: ? PC-based TCP/IP Decode Analyzer?

daved@carbon.forge.tandem.com (Dave Dilena) writes:

>Anyone know of an Analyzer (S/W only) for the PC that does TCP/IP Decoding.  I'm
>looking for inexpensive or free analysis software.

Inexpensive: Novell's LANalyzer might be what you're looking for.

Free: try the FTP site dnpap.et.tudelft.nl,  /pub/Fergie
The Delft University has a RMON SNMP agent called BTNG (Beholder, The Next
Generation).  Its predecessor is still available (although unsupported).
for MS-DOS (BTNG runs on OS/2, SUN/OS and recently Solaris).
The MS-DOS version is called FERGIE, and has a simple TCP/IP decoder
in the Capture utility.

Ling Thio
H.L.Thio@et.tudelft.nl




-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 15:43:41 GMT
From:      dangst@csn.org (Dan Angst)
To:        comp.protocols.tcp-ip
Subject:   Re: How does one apply for a tcp/ip address ?

SUNBORN@DELPHI.COM (sunborn@news.delphi.com) wrote:
: If anyone could either email me or fax me at 203-549-5039 with information
: as to how to apply for a tcp/ip address , it would be apprecaited.  
 
: James McGovern
: Command Systems

Administered by the Network Informatin Center (NIC) phone 800.365.3642 or
703.802.4535...e-mail nic@nic.ddn.mil.


-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 16:27:40 GMT
From:      anderson@dseg.ti.com (John H. Anderson)
To:        comp.protocols.tcp-ip
Subject:   SLIP/PPP FAQ location?

Could someone point me to where a FAQ or similar document is
for SLIP and/or PPP.

Thanks

*************************************
* John H. Anderson		    *
* Internet:   anderson@dseg.ti.com  *
* CompuServe: 71174,2625	    *
*************************************

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 16:48:16 GMT
From:      robert@olsen.ch (Robert Ward)
To:        comp.protocols.tcp-ip
Subject:   A couple of detailed TCP/IP questions


I'm developing a session-layer protocol running on top of TCP/IP and I
have a couple of detailed questions concerning TCP/IP.

1.  This session-layer sends alternating frame-header and user-data
blocks.  The frame-header contains the number of bytes in the following
user-data block.  I've found that if I use two write() calls to send
the frame-header and the user-data, it is very much slower than if I
copy all the data into a separately allocated storage area and do a
single write() on that.  I wrote a simple test "perpertual echo" client
and server.  Using separate write()s, this takes 30 minutes to echo
10000 messages.  Using a single write(), this takes 1 minutes for 10000
messages.

I presume TCP/IP is somehow trying to "optimise" this.  I'm worried
that I may later run into such "optimisations" even if I copy all data
into a single buffer.  Can someone please explain what is happening
here ?  How can I force the system to transmit data without waiting ?
(I tried setting the TCP_NODELAY socket option and it made no
difference).

2.  I've noticed that host/port associations seem to stay around even
after both sides of a TCP/IP connection have terminated.  (This also
happens if the SOL_REUSEADDR socket option is set).  A subsequent
bind() may well fail with "Address already in use".  Why is this ?  Can
I force the host/port association to be freed up ?

Btw, this is all on SunOS 4.1.1.

Thanks for any light you can shed on these matters.

	- Rob Ward.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    J. Robert Ward,
    Olsen & Associates AG, Seefeldstrasse 233, CH-8008 Zuerich, Switzerland

Tel.:   +41 1 3864847/8        Fax: +41 1 4222282
Email:  robert@olsen.ch        Uucp:  uunet!olsen!robert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 17:01:13 GMT
From:      Doug.Bradley@launchpad.unc.edu (Doug Bradley)
To:        comp.protocols.tcp-ip
Subject:   RARP: help requested

Would appreciate any pointers to RARP examples/implementations.
(Have read rfc903 but it's pretty general; didn't see anything 
on ftp.uu.net either)

If you email I will summarise for the net.

many tia,
Doug Bradley
bradley@wg.com

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 17:22:03 GMT
From:      rajn@sassella.ico.olivetti.com (Rajendran)
To:        comp.protocols.tcp-ip
Subject:   X.25 Address resolution for TCP/IP networks.

We are currently trying to implement an address resolution package
for TCP/IP over X.25 and to achieve this objective
I have recently acquired a document about Address resolution
over X.25 Networks (xarp) called "X.121 Address resolution for IP 
Datagram Transmission ove X.25 Networks." by Carl-H.Rokitansky,
Fern University of Hagen , dated July 1990.In the status of the 
document it says "This draft will be submitted to the RFC editor 
as a standards document." However,looking through the list of RFC's I am
unable to find the corresponding standard.Therefore, I would 
like to know 

	1. Is this document an RFC ? If yes , what is the 
	   reference number?

	2. If No is there an alternative relevant document
	   which should be consulted ?

	3. Does anyone know if there any implementation 
	   ( public domain or comercial ) which uses this standard ?

	4. What is  the position of this document vis-a-vis 
	   RFC-1236 ( IP to X.121 Address Mapping for DDN ).

I also have some other doubts which I hope sonmeone can clarify.

	1.All the  procedures seem to demand an apriori knowledge
	  of some 'xarp server' as call requests are made to this 
	  server.Is there one in the internet which performs this 
	  role ?

	2. Is aging foreseen in the protocol ?
	
	3. Would it be difficult to consider a referral mechanism 
	   wherein an xarp server returns the address of another
	   xarp server which the sending node may or may not choose
	   to contact ?

	4.How are the different channels (PVC and SVC) handled ?
	  For example if hosts A and B can communicate using
	  both SVC and PVC other than using different subnets 
	  how does a TCP application specify the type of channel
	  to use ?
	

I would be obliged if I get my answers by e-mail eventhough
I shall look through the newgroup for some time.

Thank you in advance ,

V.Rajendran (rajn@sassella.ico.olivetti.com)
Please note that I use a different e-mail address and a 'reply to author'
may not work.



-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 17:47:23 GMT
From:      magnet@nRCHs022.NoSubdomain.NoDomain (Brad Glidewell)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths


|> Don't use proxy arp.  Point all hosts at router A1.  Configure the cost of
|> I2 such that I1 = I2 + A.  Thus, A1 sees two equal cost paths and can load
|> balance over both paths.
|> 
|>        Net A (LAN)                                     Net B (LAN)
|>            |     ----------- Net I1(WAN) -----------       |
|>            +-----|Router A1|-------------|Router B1|-------+
|>            |     -----------             -----------       |
|>            |     ----------- Net I2(WAN) -----------       |
|>            +-----|Router A2|-------------|Router B2|-------+
|>            |     -----------             -----------       |
|> 
|> Tony

Tony,

What happens when "A1" loses the route or (horrors) goes down?

-- 
brad.glidewell@nt.com

"I am the most humble person in all the world!"

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 18:27:31 GMT
From:      avg@sprintlink.net (Vadim Antonov)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths

In <2ktanb$va@corpgate.rich.nt.com>, Brad Glidewell (magnet@nRCHs022.NoSubdomain.NoDomain) wrote:

: |> Don't use proxy arp.  Point all hosts at router A1.  Configure the cost of
: |> I2 such that I1 = I2 + A.  Thus, A1 sees two equal cost paths and can load
: |> balance over both paths.
: |> 
: |>        Net A (LAN)                                     Net B (LAN)
: |>            |     ----------- Net I1(WAN) -----------       |
: |>            +-----|Router A1|-------------|Router B1|-------+
: |>            |     -----------             -----------       |
: |>            |     ----------- Net I2(WAN) -----------       |
: |>            +-----|Router A2|-------------|Router B2|-------+
: |>            |     -----------             -----------       |
: |> 
: |> Tony
 
: Tony,
 
: What happens when "A1" loses the route or (horrors) goes down?

You may have A1 and A2 to advertise default (or real routes) with, say, RIP
and have A2 to generate longer distances.

--vadim

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 21:03:13 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Tcpdump for AIX?

Anyone managed to port tcpdump to AIX?

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 21:04:08 GMT
From:      peery@straight.isc.tamu.edu (Alan Peery)
To:        comp.unix.aix,comp.unix.admin,comp.security.unix,comp.protocols.tcpip
Subject:   Re: Once more: How do I log outgoing TCP/IP-connections ?

In article <2ksscv$120k@fikyrsk2.kymmene.fi> jeg@gronja.kymmene.fi writes:

>>   I posted this question almost week ago, but there were very few
>>   responses and those suggestions weren't suitable for me (I hope I
>>   don't need ident server).  I received message that there are
>>   others who want to know solution of this problem. So I'll try
>>   again and this time I'll post this message to couple more news
>>   groups. If this can't be done, that infomation is also usefull.

It is possible to do what you want if all you want to track is the
average user--you find the source code for telnet and ftp, add logging
functions, and install the new executables.  This solves the problem
you stated(assuming that a sophisticated cracker doesn't bring along
his own telnet), but this is only a small part of the problem.

Many of the tools that the cracking community uses are not based
on telnet and ftp--they use the network services at a lower level.
To trace the use of socket-based networking programs, you will have
to instrument the tcp/udp (networking) sections of the AIX kernel, 
which is impossible without source code.  

SUMMARY:

    It is not the entire answer, but you might catch a few of 
    the less dangerous fish this way.


>>   > We have access to the Internet through one RS/6000 (AIX
>>   > 3.2.4). I would like to keep log when and where users have
>>   > connections out of our network.  My goal is that if I get call:
>>   > "Somebody is hacking us from your network" I could trace who he
>>   > is. I'd like have tools log which indicates that user kilroy
>>   > started telnet (or ftp) session to host any.host.in.net at
>>   > 23.2.1994 23:01:11 and ended session at 23.2.1994 23:43:17.
>>   > 
 
>>   > I could log use of telnet and ftp command (with parameters),
>>   > but that wouldn't be very reliable way to do logging (you can
>>   > choose host with open-command).
>> 
 
>>   > Can I do logging with normal AIX-commands, can I get something
>>   > with FTP or should I buy something ? I'll be thankfull of any
>>   > advices.


>>
>>   Jan-Erik Gron           E-mail: kymmene.kh.gronja@elvi.vtkk.fi
>>   Kymmene Corporation     Fax:    +358-51-402 2241
>>   Finland                 Phone:  +358-51-402 2314

Alan

--

Alan Peery
Institute for Scientific Computation
Texas A&M University
peery@isc.tamu.edu

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 22:32:21 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths

In article <2ktanb$va@corpgate.rich.nt.com> brad.glidewell@nt.com writes:
    
    |> Don't use proxy arp.  Point all hosts at router A1.  Configure the
 cost of 
    |> I2 such that I1 = I2 + A.  Thus, A1 sees two equal cost paths and
 can load 
    |> balance over both paths.
    |> 
    |>        Net A (LAN)                                     Net B (LAN)
    |>            |     ----------- Net I1(WAN) -----------       |
    |>            +-----|Router A1|-------------|Router B1|-------+
    |>            |     -----------             -----------       |
    |>            |     ----------- Net I2(WAN) -----------       |
    |>            +-----|Router A2|-------------|Router B2|-------+
    |>            |     -----------             -----------       |
    
    What happens when "A1" loses the route or (horrors) goes down?
    
You use router discovery to find A2.

Tony

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Tue, 01 Mar 1994 08:38:44 -0600
From:      Carl.Hoang@f31.n282.z1.tdkt.mn.org (Carl Hoang)
To:        comp.protocols.tcp-ip
Subject:   HL7 Interface

I would like to get contact with people who's doing Health Level 7 interface
between platforms and application systems.  Please send me an Email message if
you are.  Thanks.
   Carl Hoang   carl.hoang@tdkt.mn.org

 * Origin: Dark Knight's Table (1:282/31)

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Feb 1994 23:07:03 GMT
From:      peter@austin.ibm.com (Peter Jeffe 512.838.4019)
To:        comp.protocols.tcp-ip
Subject:   SYN-RECEIVED-->CLOSE-WAIT

In rfc793, it says that a connection in the SYN-RECEIVED state
should go to the CLOSE-WAIT state when it receives a FIN.  This
is causing problems, since in the BSD implementation (and others
I'm sure) the connection isn't presented to the user (via the
accept() call) until it reaches the ESTABLISHED state.  This
means that there is no way that the user process can close the
connection once it goes into the CLOSE-WAIT state in this
manner, since it doesn't have a file descriptor to it, and it
doesn't know that it exists.

The result is that you get CLOSE-WAIT connections hanging around
forever on the LISTEN socket, taking up valuable queue space.
It seems to me that this must be a known problem, or perhaps I'm
not looking at it right.  In either case, can anyone tell me if
there's a way out of this sad state of affairs?

-- 
peter jeffe  peter@tkg.com

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 23:36:44 GMT
From:      mbeebe@repo.rose.hp.com (Mike Beebe)
To:        comp.protocols.tcp-ip
Subject:   FAQ Requested

   If there is an FAQ for this group, I'd like to be e-mailed a copy.

--
"The difference between humans and animals is that you can pet 98% of
 an animal and still pull a G rating."

					-- Overheard on FurryMUCK


END OF DOCUMENT