The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 1993 00:57:19 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip
Subject:   HELP! tcpdump is not giving me data...

Let's suppose that I have tcpdump running in promiscuous mode and
giving unfiltered output. No filter restriction is specified.
In that case when I do something like ftp I should get some tcpdump
output pertaining to the ftp, right? I don't get a flicker. So can
someone tell me what tcpdump needs to get started? I'm not sure
what the defaults are. The man page is really sketchy.

When I quit tcpdump it says something like 350 packets (maybe with
some discards). I don't see the headers of all 350 packets though.
The number of discards doesn't account for what I don't see. How
does tcpdump decide what to output? and what not to output?

Another question is if I want tcpdump to get the ftp packets, what
parameters do I set? The man page says something about "port ftp".
I don't know what that means. What does "port" have to do with
"ftp"?

--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 01:12:22 GMT
From:      rudoff@mdd.comm.mot.com (Doug Rudoff)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc,alt.sys.sun
Subject:   How do I send a raw IP packet on a Sun (socket? /dev/nit?)


I want to do something very simple: send a raw IP packet out on the
Internet. I have a Sparcstation10 running SunOS 4.1.3. I'm not having
much luck.

I have an IP packet received via radio from a mobile computer. I have
a host that acts as a gateway to the Internet and passes the IP packet
to our Internet provider.

The IP packet is correct when received. The problem is that our host
substitutes its IP address for the mobile IP address (as viewed while
running etherfind). However, the packet type (ICMP, telnet, etc.)
remains as it shoud be. It's as if our host looks at the IP packet and
says, "hold it, the destination address says it's not from me. But I'm
sending it, so I'll change it to my address." This means that no
response from the Internet can be forwarded to the mobile.

I open the socket with socket(AF_INET, SOCK_RAW, IPPROTO_RAW) and use
a sendto() to forward the packet.

Since I'm having problems I'm looking into using NIT. I have source
for receiving on nit, but not for sending. The manual pages leave much
to be desired.

So, any advice and/or source code samples out there that would help me
out?

Thanks.
-- 
//////////////////////////////////////////////////////////////////////////
Doug Rudoff              Motorola, Seattle         rudoff@mdd.comm.mot.com
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 93 12:58:09 NZDT
From:      fowler@southpower.co.nz
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,comp.os.vms
Subject:   Anybody use PC Route???

Hello,


We currently run Multinet TCP/IP and have a connection to the Internet VIA
PC Route.  PC Route is a package that will run on a PC and do TCP/IP
Routing across different interfaces including ethernet cards and the serial
port for slip.  Our slip connection currently runs at 9k6 and I am looking
to upgrade it to perhaps 48k.

My Question.  Does anybody out there use PC Route??  Has anyone tried to
use it at speeds higher than 9k6??  Please email any responses as due to
the speed of our link news is about three days behind at the moment.  I
will post a summary.



Thanks,
Ken.
--
Southpower,             Phone:     (64)(03) 363-9527
Private Bag,            Fax:       (64)(03) 363-9816
Christchurch,           Internet:  fowler@southpower.co.nz
New Zealand.            PSI:       0530130010083::galaxy::fowler

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 1993 03:02:31 GMT
From:      Gunnar Helliesen <gunnar_h@bg1.brg.mbs.no>
To:        comp.protocols.tcp-ip
Subject:   Can I do this with a class C network?

Hi,

I'm sorry if this is a trivial question to you net-gurus, but here goes:

I'd like to set up a SLIP connection between the office and home over a
leased line. We don't have all that many addresses, so I'll have to use
them sparingly.

On the ethernet at work we use one C nett: x.y.105.0 (no subnetting). On
this network we have a default gateway/router that connects us to the
rest of the world. This gateway has no spare ports, so I'll have to use a
VAX(!) on the ethernet as my gateway home.

Can I split up a second class C network (using netmask 255.255.255.240)
and use the first subnet for the line home:

x.y.106.17 (SLIP at work) <--> x.y.106.18 (SLIP at home)
*and* use the second subnet (x.y.106.33 - x.y.106.46) for the machines on
my ethernet at home?

Will the routing software (BTW, which should I use? Static or gated?) see
this as two networks (x.y.106.16 and x.y.106.32) and figure out the
routing between the nets? I *have* tried to set this up, but couldn't get
it to work.

The gateways at both ends are VAXen running VMS and TCP/IP, with one
ethernet interface and one SLIP interface each. I tried to use gated for
routing with simple "rip yes ;" statements in gated.conf (in addition I
had to use an "interface le0 passive ;" statement at home in order to
keep gated from declaring the ethernet interface down).

If this is supposed to work, what happens when someone else wants a line
home? Can she or he use the next two subnets in the same fashion as long
as they are connected to a second SLIP interface on the same gateway at
work? E.g. networks x.y.106.48 (office <--> home) and x.y.106.64 (at
home).

Or do we really need to use four whole class C networks to get us both up
and running?

Again, I'm sorry if this is a FAQ or in an RFC somewhere. If so, please
point me in the right direction...

-- Gunnar

--------------------------------------------------------------------------
   >         |     /   ___  /   ____/  Gunnar Helliesen
  > >        | /  /   /    /   /       Support/Tech. Manager
 O >    /  _/  /   ___ /   ___  /    MBS Fjerndata AS, Bergen, Norway
  > >    /      /   /    /       /     Voice: +4755343800 FAX: +4755345690
   >   _/     _/  ______/  _____/      email: gunnar_h@bg1.brg.mbs.no
--------------------------------------------------------------------------
 "The reason the universe is so hard to comprehend is that there is
  nothing to compare it with"  -- Douglas Adams
--------------------------------------------------------------------------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 03:55:47 GMT
From:      csc3bem@cabell.vcu.edu (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over VSAT


Has anyone out there successfully (or unsuccessfully) attempted
running IP-based applications over VSAT technology?  If so,
could you briefly describe your setup and application.

Thanks,

Bryan

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 1993 04:32:15 GMT
From:      Jerry@PeachNet.EDU (Jerry W. Segers)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <DRW.93Sep29200319@zermelo.mit.edu>
drw@zermelo.mit.edu (Dale R. Worley) writes:

> It seems that there are several sorts of data streams like real-time
> video and audio that have the properties:
>         - tight timing requirements
>         - resistance to loss of individual packets
... other stuff deleted

I have worked in data communication for a long time, but I am a
relatively new to the field of video compression so perhaps the
following question is somewhat naive.  If so please be kind with your
replies and I will quietly go away.   

Are these two <requirements> for <real time> video as real as Dale and
many in the telephony industry seem to believe?

My understanding is that any real time video over a network will be
compressed in some way, at least to the extent needed to remove the
redundant information (e.g. MPEG).  I also understand that current
compressors are required by current telephony standards to emit
constant output streams.  Thus each compressor will use a relatively
large frame buffer that is filled from the output of the compression
process then emptied into the communication path at a constant rate.  

Is it not reasonable to change the approach when using a transport
method like IP that has a variable transmission rate?  For example has
there been any work done along the lines of moving the buffer to the
other end of the path.  That is, send the variable output from the
compressor directly to the network and collect it in a buffer at the
receiving end.  If the data arrives too late or is lost, the buffer
will empty but the display software can repeat the last frame thus
causing the display to stutter then jump but the picture quality will
not degrade.  The same argument would seem to apply to audio as well.
Instead of duplicating the output on buffer empty just output silence.

The amount of jumpiness or silence could be controlled by the user at
the expense of the output frame rate or by adding bandwidth thus
increasing circuit reliability.

It seems to me that we have been using this plan for text transmission
with great success.  If the characters from a Telnet session arrive too
slow or sporadically for the receiver, the options are put up with the
problem or secure a faster connection.

Have I missed something or are the folks like Dale right for requiring
a reliable data path? 

**************************************
Jerry W. Segers
Director
Regents Telecommunications and Networking
P.O. Box 444
Marietta, GA   30061
Phone: 404-423-6860
Fax: 404-423-6868
Internet:Jerry@PeachNet.EDU
**************************************

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 05:37:06 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Host routes on Cisco?

Do Ciscos support host-routes at all?  I've been doing some experiments
trying to short-cut paths for multihomed hosts, and it appears that Ciscos
ignore the host part of any route, whether it's received via RIP or given
as a static route.

Has anyone managed to get this working?  Or, is this a to-be-supported
feature?  Thanks for any info.

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

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 09:35:12 +0000
From:      paulr@pcproj.datastream.co.uk (Paul Rossington)
To:        comp.protocols.tcp-ip
Subject:   None (mail relay)

Hi,

can someone point me to some example code for using non-blocking sockets?

Thanks in advance.

Paul

--
=============================================================================
                                 |
Paul Rossington,                 | "Sometimes I think the surest sign that
Datastream International, London | intelligent life exists elsewhere in the
paulr@pcproj.datastream.co.uk    | Universe is the fact that none of it has
paulr@dspcproj.demon.co.uk       | tried to contact us" - Calvin to Hobbes
                                 |
=============================================================================

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 93 15:51:18 CDT
From:      mcginnis@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need help choosing E-net card and software

I have a student that needs to write a program to send/receive
data over the Internet.  His PC is going to be hooked to ethernet.
His program will have the data.  He needs to write software to
encapsulate the data into IP packets and transmit them to a remote
site.  He'll then, of course, need to be able to receive data from
the remote site in a like manner.

I need a recommendation for an ethernet card and card contol software.
He'd like to write C routines to control the ethernet card driver...
maybe even just issue calls to a card driver that will handle all
the TCP/IP overhead.

Please email replies since I don't read these groups regularly.

Thanks.

Michael McGinnis                Internet: mcginnis@kuhub.cc.ukans.edu
Computer Center                   Bitnet: mcginnis@ukanvax
University of Kansas               Voice: (913)864-0413
Lawrence, KS  66045                  FAX: (913)864-0485

Rust never sleeps.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 16:23:56
From:      kck@pacnw.intel.com (Kevin Kahn)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <1993Sep30.150011.85836@ucl.ac.uk> ccaajac@ucl.ac.uk (Jon Crowcroft) writes:
>a lot of work on next generation IP includes concepts of link sharing (a form 
 of>VPN)
>as well as supporting traffic which must needs be treated differently, in the
>context
>of starting with bursty (traffic that needs big buffers in switches) and adding
>less bursty (CBR video, or voice) (not to get into a debate about whether VBR
>video is bursty...)
 
>this is in contrast to the bulk of published work on aTM which starts with
>supporting policed (leaky bucket sources) and has only recently added some
>work on adding really bursty sources...

The Traffic Management WG at  ATM Forum seems to have finally come to grips 
with officially discussing this issue.  Although there seems to be a strong 
contingent of Telco types that still focus their attention on rate controlled 
VCs, there is now an official work item to address a service (coined Available 
Bit Rate following Constant and Variable Bit Rate) that would have low cell 
loss probability but potentially long delays.  The notion is to define a 
service and mechanisms to allow the network to tell the application on a 
continuing basis what bandwidth is "available".  This is intentionally worded 
a bit strangely to avoid a priori prejudicing the mechanisms to accomplish the 
goal.  There are flow control advocates, BECN types, FECN types, and folks who 
think hybrid solutions will be needed.  At least the topic is now on the table 
and hopefully the merging of the various camps that Jon hopes for can happen.
Kevin Kahn
Intel Architecture Labs

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 12:52:20 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   where is "Where are You" ?


   I have a network consisting of Suns running 4.1.2 and 4.1.3. If I wish 
rlogin from a .3 sun to a .2 sun or vice verso everything works fine ->
my rhost file(s) are fine. However if I try to rcp where the .3 sun is a 
server ie the rcp is issued on the .2 machine) I get a "where are you" and the command exits. It works fine in the other direction. If I do a rsh from a .2 machine to a .3 machine I still get the "where are you" but the command will
execute. It works fine in the other direction. I have RTFM'ed but maybe in the 
wromg place. This is obviously some sort of configuration problem. What is
happening.

                                        Jerry Freedman,Jr

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 93 13:53:28 GMT
From:      mikeh@hdssun1hds.com (Mike Hartman)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ ?

>Sorry to post this here. Just want to make all clear for the new ones.
>
>In article <CE49vJ.E66@fiu.edu>, Jim Schenk <jims@fiu.edu> wrote:
>>Is there a FAQ for this list?
>>
>
>Yes, of course, almost every important group has a FAQ.
>It is posted here (at regular intervals).
>Subscribe to news.answers and you'll get all the FAQ you've (n)ever
>wanted to know about.

Well, I've never seen an FAQ posted on comp.protocols.tcp-ip, and I don't
consider myself a ``new one'' (I've been reading this group the last 3 years).

Where is the FAQ ??

-- 
Michael Hartman			  | e-mail: mikeh@hds.com
Software Engineer		  | phone:  (215) 277-8300
Human Designed Systems, Inc.	  | FAX:    (215) 275-5739
421 Feheley Drive		  |
King of Prussia, PA 19406  (USA)  |
----------------------------------------------------------------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Oct 93 17:25:51 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Text Descriptions with FTP's "ls" command

In article <CE6AAH.2BA@news.iastate.edu> john@iastate.edu writes:

   PS, I really love how programs like NcFTP send junk like:

       NLST -FC file

   assuming that all (unix) LIST/NLSTs are ls-based...   (*sigh*)

That's why the FTP protocol needs a new XLST command, which is
guaranteed to return information in a parsable format.  The obvious
choice is the output of "/bin/ls -lg".  That makes implementing XLST
just a matter of making an alias for NLST.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 1993 18:23:04 GMT
From:      ajohnson@unix.sri.com
To:        comp.protocols.tcp-ip
Subject:   Enabling TCP to output state/debug info

 Hello,

I am currently trying to teach myself how TCP works.  I noticed there
exists a
tcp_debug module that allows for some TCP state information to be output.
How do I get TCP to output the debug infomation?  I am assuming someone
out 
there has done it because the tcp_debug function exists! ;^}
I am running a SUN3 w/SunOS 4.1.1. I also have the TCP source.

Thanks in advance!

Alan W. Johnson
SRI International 

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 19:27:43 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Design of parallel TCP. Is it possible ?

> I'm wondering if TCP protocol can be parallelized to make the
> processing of the protocol more effective.

Leaving aside the notion of what `effective' is, the answer is yes, TCP
can be parallelized, and in ways that make at least some good use of the
multiple processors.
 
Note that there are several ways to do this, most of which don't work well.
Many folks try to do different functions (e.g., checksum, sequence number,
etc) in different processors.  That's typically a losing approach, because
the cost of coordinating among the processors far exceeds the number of 
instructions required to do the TCP processing.
 
A more winning approach appears to be to have several processors each capable
of doing all the TCP processing for a segment, and assigning incoming
segments round-robin among the processors.  (See, for example, Bjorkman
and Gunningberg's paper in Proceedings of ACM SIGCOMM '93).

Craig

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 20:54:41 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Text Descriptions with FTP's "ls" command

nelson@crynwr.com (Russell Nelson) writes:
}In article <CE6AAH.2BA@news.iastate.edu> john@iastate.edu writes:
}
}   PS, I really love how programs like NcFTP send junk like:
}
}       NLST -FC file
}
}   assuming that all (unix) LIST/NLSTs are ls-based...   (*sigh*)
}
}That's why the FTP protocol needs a new XLST command, which is
}guaranteed to return information in a parsable format.  The obvious
}choice is the output of "/bin/ls -lg".  That makes implementing XLST
}just a matter of making an alias for NLST.

   ... all the world's Unix disease again ...

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

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 93 21:24:38 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: Design of parallel TCP. Is it possible ?

craig@sics.se (Craig Partridge) writes:

>> I'm wondering if TCP protocol can be parallelized to make the
>> processing of the protocol more effective.
 
>Leaving aside the notion of what `effective' is, the answer is yes, TCP
>can be parallelized, and in ways that make at least some good use of the
>multiple processors.
> 
>Note that there are several ways to do this, most of which don't work well.
>Many folks try to do different functions (e.g., checksum, sequence number,
>etc) in different processors.  That's typically a losing approach, because
>the cost of coordinating among the processors far exceeds the number of 
>instructions required to do the TCP processing.
> 
>A more winning approach appears to be to have several processors each capable
>of doing all the TCP processing for a segment, and assigning incoming
>segments round-robin among the processors.  (See, for example, Bjorkman
>and Gunningberg's paper in Proceedings of ACM SIGCOMM '93).
 
>Craig

	I would think the TCP checksum would probably be the only
	good candidate for parallelizing (?) I'm assuming that multi-
	threaded STREAMS implementations would not be considered in this
	case since I think the person asking the question meant 
	parallelizing single connection processing through TCP....

	Randy



-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 93 21:36:50 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   audio conferencing software - mbone


	I am looking for the software that allows internet-wide
	audio conferencing between <n> numbered audio-capable 
	workstations...Recently I heard that it was on one of
	the machines in the lbl.gov domain but I forgot which one.

	Also, I believe I will also need the SunOS 4.1 kernel
	patches to support IP Multicast.  Does anyone know where
	these patches are and possibly provide some quick procedure
	for building the kernel with these new changes ?

	Thanks!
		Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 21:53:53 GMT
From:      na@netrix.com (Najam Ahmad)
To:        comp.protocols.tcp-ip
Subject:   Looking for IP conformance tests

Hi,

I am looking for scripts/applications for IP conformance/performance testing 
of a router. I need something that can run under DOS, UNIX, or Domain OS. 
Could anyone who has any information about such applications mail me the 
information.

Thanx in advance!

Best Regards,
Najam

------------------------------------------------------------------------------
   Najam Ahmad                     		Email: na@netrix.com
   Netrix Corporation				Phone: (703) 793-1001
   13595 Dulles Technology Drive			Fax:   (703) 713-3805
   Herndon, VA 22071
------------------------------------------------------------------------------






























-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 1993 23:29:02 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip
Subject:   REQUEST: tcpdump raw packet output format

There's a -w option for tcpdump to write the raw packets to a file.
Does anyone know the format of this write?

I look at the resulting file and it's binary! I can't read it.

For instance when I use tcpdump -r on the binary, tcpdump gives the
time stamp and all sorts of information. Well, how the heck does
tcpdump figure out this from the file???????????

I can't see the time stamp (example time stamp 17:17:41.634657) in the
file. However, if I use od -a on the file every once in a while
there's about 5 or 6 bytes of coherent information nested in
all kinds of crap.

--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 1993 23:47:33 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip
Subject:   HELP! Where do ftp transfers go?

I'm trying to use tcpdump to read the network traffic due to ftp
activity. When the ftp starts, tcpdump spits out some info, but
tcpdump stops after that even though I'm transferring millions of
bytes. Does this mean the information in the file cannot be seen
with tcpdump?

Let's say that tcpdump picks up headers only. Does this mean the
file transfer occurs with only a constant number of initiating
conversation packets and a terminating packet? This is inconceivable
when I'm dealing with a 1 Meg file (maybe).

Another explanation which may be true is many packets are used
to transfer my file, but these files are not ftp packets. In that
case, I don't know what an ftp packet is and I'd appreciate someone
telling me all the types of packets ftp uses during a transfer!!!



--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Oct 1993 23:59:49 GMT
From:      Openview_forum@dmewrk1.orl.mmc.com
To:        comp.protocols.tcp-ip
Subject:   OpenView Product Requirements


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

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

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


Dear Users/Developers:

Tell the OpenView Forum what Issues need to be addressed by specific 
vendor(s) and topic for the upcoming User/Developer conference scheduled in
Oct/Nov in Dallas.

We want to tell HP & HP OpenView Premier partners the types of requirements,
comments/suggestion, Hot Issues, etc that will need to be addressed by the 
speakers at the conference. (We want the correct people present at the 
conference to answer the MAIL!!!)

We want to make sure that speakers come prepared to address issues most 
important to YOU!! With that in mind, would you please:

    List any issues that you would most like to see addressed at the 
    conference, including issues related to one or more of the following:

            - OpenView strategy
            - Product-specific features/functions and evolution
            - Platform technologies
            - Others, such as standards bodies involvement,
              partnerships, whatever... 


We need your suggestions for enhancements to the HP OpenView Microsoft 
Windows and Unix product line as well as the premier partners product
line. Send the Forum as many Email requirements/suggestions/issues you
want TODAY!!!!.

Remember the Key for this First year's OpenView Forum is INTEGRATION of
Vendor Solutions to the OpenView Framework!!!

At the Forum we will also collect requirements so they can also be
categorize, and VOTE on these on the seconds day of the conference. 
Please don't want until the day of the conference to submit your input!!

YOU NEED TO GET THE INFORMATION TO THE OPENVIEW FORUM VIA EMAIL ASAP!!!

Please help us in getting the requirements documented and so we can have 
this information available On-Line for review at the OpenView Forum conference.

Below is a sample form, which you can use to docuement your input to the Forum!


VENDOR:________________________________ Issue:__________________________
                                        (Evolution, Features, Integration,
                                        Design, Cost, etc) 

PRODUCT:_______________________________ Rating:_________________________ 
                                        (HOT, WARM, Cann't Live without,
                                         etc)

Description:____________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________


Suggested Enhancement:__________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

Return your replies to:

OPENVIEW_FORUM@DMEWRK1.ORL.MMC.COM

Thanks Frank Belland
VP Technical Operations 

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 93 11:50:07 NZDT
From:      fowler@southpower.co.nz
To:        comp.protocols.tcp-ip
Subject:   Question on SLIP

Hello,


I have a simple question about the SLIP protocol.  I want to know if it can
be used across a Synch pair of modems as well as Async.  Sorry if this is a
stupid question.  Otherwise can anyone point me towards an RFC for slip.

Please email any responses as due to the speed of our link news is about
three days behind at the moment.



Thanks,
Ken.
--
Southpower,             Phone:     (64)(03) 363-9527
Private Bag,            Fax:       (64)(03) 363-9816
Christchurch,           Internet:  fowler@southpower.co.nz
New Zealand.            PSI:       0530130010083::galaxy::fowler

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 1993 01:23:41 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Specifying IP

crohrer@advtech.uswest.com ( Chris Rohrer) writes:

> Never having tried to hook up two IP devices or (even worse) networks
> together I need to know just how you go about specifying everything you
> have to do to have a set of rules for a well-behaved network.
> Can I just say "Oh,
> we'll just put in an Ethernet and use the TCP/IP protocol suite over it" and
> use all the "default" settings out of the box, as it were?

Yes, absolutely.  You sound doubtful, but almost all the decisions you
could make in a configuration like this have been taken out of your hands
and put in the software, which figures out what to do based on person-
millenia of painfully gained experience.

While there are some things you can adjust (you can lower MTU, though you
can almost never raise it, etc), you should do this only after you get an
intimate knowledge of how the net works in its normal, out-of-box setup.
This is something you can only learn with experience, and the default
nearly always works fine.

> MTU size
> Version number
> Use of other header fields
> Use of optional fields
> Use of address resolution mechanism(s)

All these are defaulted to the right values by software (MTU depends on the
hardware, Version=4, address resolution=ARP) or vary by application
(optional header fields in ping -R or traceroute).  They're not meant to be
messed with at install time.

> Like if I were to write an "interface specification" to my IP network, what
> items would I absolutely have to specify (ignoring for the moment the
> actual applications and their requirements...)?

I'd recommend you put these items in your "interface specification":

- Always use an officially assigned network number from the NIC; never,
   never make up a network number even for "temporary" use.

- If you're installing SMTP, the same applies to the domain name.

- If you have more than a dozen or so systems, use DNS or NIS.  If you
   have systems that are maintained by more than one organization (or by
   two or more individuals who are not co-workers), use DNS.

- If you use NFS or SMTP, also use a time-synchronization protocol like ntp
   (recommended) or timed (not recommended, but sometimes necessary) or
   both.  Even if you don't use NFS or SMTP, this is worth considering.

- If you have an external network link, or even a single dialin line, or
   systems in publicly accessible areas, set things up to be secure and
   never forget about security.

These might not be what you were asking for, and some people in your
position won't like to think about these things (because they involve extra
work and aren't as satisfying as a pronouncement of "Thou shalt use an
initial TTL of 255"), but they really are the things that will burn you if
you don't do them right from the beginning.

Good luck.

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

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 93 03:38:20 GMT
From:      stuartf@sequent.com (Stuart Friedberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Design of parallel TCP. Is it possible ?

In article <1993Oct1.192743.14972@sics.se> craig@sics.se (Craig Partridge) writes:
>A more winning approach appears to be to have several processors each capable
>of doing all the TCP processing for a segment, and assigning incoming
>segments round-robin among the processors.  (See, for example, Bjorkman
>and Gunningberg's paper in Proceedings of ACM SIGCOMM '93).

If the vendor-specificity will be excused, Sequent's PTX operating
system features fully symmetric multiprocessing, and our TCP and
other comms products are all STREAMS based.  As a result, you can
get real concurrency at various levels in the protocol stack via
STREAMS service procedures (doesn't happen that often), as well as
getting per-segment multiprocessing for free via interrupt handling
symmetrically shared among the processors (happens all the time).

With some recent changes that will ship in our next release (perhaps
the current release as well, not sure), we *efficiently* support
over 2000 active TCP connections on our commercial systems (some
customers have these modifications already).  Mind you, that's 2000
connections in an environment where move-to-first optimizations of
BSD-style pcb lookups do *not* buy you very much.  There have been
papers on this issue ...

Stu Friedberg (stuartf@sequent.com)

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 1993 04:16:39 GMT
From:      dhara_s@nun.cs.odu.edu (Sudheer Dharanikota)
To:        comp.protocols.tcp-ip
Subject:   Sharing ACE..

Hai,

        I am trying to access the ARP cache entry (ace) from
IP. Can someone who is familiar with the source code of IP 
and ARP help me where to look for and how to access this 
information. I am working on solaris 2.1 OS.

Thank you,

sudheer.


-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 1993 07:50:03 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking answers to Net Problem

In article <1993Sep27.122710.3737@inland.com> postma@inland.com writes:
>
>We have a 10base5 Ethernet network with a majority of Vitalink bridges with a
>handfull of DEC bridges.  We have a DEC VAXStation 3100 Ultrix workstation

[some stuff deleted]

>The original gateway bridge had an IP address of 156.144.60.2.  I assigned the 
>"new" gateway bridge an address of 156.144.60.40.  Then I changed the Ultrix
>Wanmanager software to use 156.144.60.40 as the address of its gateway bridge.
>The system never came up.  I used an HP Lan analyser and saw no traffic between
>the Vitalink Gateway bridge (156.144.60.40) and the Ultrix station.  I then
>tried to ping the new bridge.  It failed the ping, than I ARP'd it and that was
>successfull.  The old bridge could be ARP'd and Ping'd.  After alot of time
>with Tech support, I finally decided to try a new IP address for the new
>bridge.  I assigned the bridge the address of 156.144.60.100, then modified the
>WanManager software to look for that address.  At this point the system came on
>line and has been working fine since.
>
>Now what I don't understand is what really was wrong?  I spent a lot of time on
>this and did not come away learning anything.  The only other thing is that
>156.144.60.40 used to be assigned to a cisco router we were testing, but the
>router is gone and has been for at least a week.  Any answers ......

This is a bit of a long shot because I don't fully understand your
configuration, but it may help.

The fact that you mention gateways (ie. the Vitalinks) and that you give 
them IP addresses (which bridges don't need, except for management) makes
me think that what you have got on the Vitalinks is *router* functionality 
or maybe a router you haven't mentioned?

If this is the case, you have actually got more than one subnet.

However, your IP address is class B  (first octet between 128 and 191)
and your subnet number for ALL of the devices is 156.144  (implying that
they think, if default Class B subnet masking is used, they are all on 
the same subnet).  

What subnet masks have you set on all your devices?
If its 255.255.0.0  (by default for a Class B) then this could be the 
problem.

If your subnet mask (for some or all devices) is 255.255.255.192 then 
this *could* explain it, because "100" in the last octet would be
interpreted as on a different subnet from "40" and "2" and probably
unreachable?

Finally, if the subnet mask settings are different between some of 
the devices this could also explain the problem, and cause others :-)


Hope this helps


-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 93 08:09:31 GMT
From:      phone@cairo.anu.edu.au (matthew green)
To:        comp.protocols.tcp-ip
Subject:   Re: Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)

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

>                           Oh, you also need superuser privilege to
>create a raw socket.

of course, if you are running ESIX, this is false.  (unless its been
``fixed'' in a new version)

mrg..

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 1993 11:38:57 GMT
From:      andym@sthwark.demon.co.uk (Andy McClements)
To:        comp.protocols.tcp-ip
Subject:   Opinions wanted on network harware

I'm currently evaluating various vendors routers, hubs, management software
etc. which I'll be using to set up a modest multi-protocol internetwork
between four of our sites. There'll initially be between 15-25 active users
per site, using PC's and Macs, and the traffic between sites will be mainly
e-mail and database transactions.

The infrastucture will be based on 2Mbit/s fibre links, shared with the
voice system by NewBridge multiplexers. The data bandwith between sites
will initially be 512kbit/s, (expandable to 1024kbit/s if we opt for
compression on the voice channels) and will be presented on X.21
connectors.

It seems like there aren't many vendors which do a complete range as
mentioned above. The only one I've found so far is HP, who can provide
everthing I need to build the internet, from the central router down to
individual transceivers. It would certainly make my life a lot easier if I
had a single point of contact for support, maintenance etc. and I would
think going for a single vendor should minimise interoperability problems.

Does anyone have experience of HP hardware, or have any recommendations ?


-- 
--------------------------------------------------------------------------
Andy McClements           e-mail:     andym@sthwark.demon.co.uk
Computer Manager          applelink:  southwark.uk             
Southwark College         voice:      071-815-1522
Drummond Road             fax:        071-815-1525
London
SE16 4EE
--------------------------------------------------------------------------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 1993 12:54:13 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! Where do ftp transfers go?

Henry_Choy@engr.usask.ca (Henry Choy) writes:
}I'm trying to use tcpdump to read the network traffic due to ftp
}activity. When the ftp starts, tcpdump spits out some info, but
}tcpdump stops after that even though I'm transferring millions of
}bytes. Does this mean the information in the file cannot be seen
}with tcpdump?

    FTP uses a control connection and a data connection.
    It would seem you are watching only the control connection.
    See RFC959 (available at your better ftp sites) for details.

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

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 1993 14:19:27 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specifying IP

In article <CE8x7I.K75@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>...
>-                  ...    also use a time-synchronization protocol like ntp
>   (recommended) or timed (not recommended, but sometimes necessary) or
>   both.  Even if you don't use NFS or SMTP, this is worth considering.


I know of a major UNIX vendor that ships `timed` turned on, so that there
are 10's of 1000's of workstations out there happily using timed, with
their clocks synchronized to about 10 ms.  Almost all timed problems result
from customer improvements to the out-of-the-box configuration or when
two different groups of people on the same wire cannot agree on the time.
Notice that unnecessary knob TCP/IP twisting is what Mr. Fitzgerald warned
against in the rest of his article.  A large fraction of all computer
problems are "operator assisted."

The timed protocol, "TSP", is not what it should have been, and the 4.3BSD
implementations was not an admirable piece of code, but in my biased
opinion, the 4.4BSD version is sufficiently stable.  Timed has one great
advantage over NTP, at least as NTP is currently used.  Timed can be
shipped to work out-of-the-box, so that the customer need not look for a
time server and otherwise fiddle with configuration files.  Even when you
do use NTP (or other protocols) to get the time from a better source, it
is best to use NTP on only a few trusted time lords, and let them
distribute time via timed-TSP to the local rabble.  Maybe NTP
implementations will eventually be improved to do that also.


Vernon Schryver    vjs@rhyolite.com

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 93 19:12:14 GMT
From:      orel@oeaix.oea.ihep.su (Oleg Orel)
To:        comp.protocols.tcp-ip
Subject:   Re: libftp libraries on a sun4

Doug Burke (dburke@icarus.lis.pitt.edu) wrote:

: Hi.  I am trying to get the "libftp" ftp libraries up and running on our
: Sun4/360 machine running SunOS 4.1.3 but keep getting core dumps when
: trying to run the sample application.  It seems to be core dumping when
: trying to use the hostname passed to the FtpConnect function.  The
: "libftp" software was posted to this newsgroup sometime last July.
 
: Has anyone had success with these libraries on their Sun machines?  I am
: using GCC 2.4.5.  Thanks in advance for any information.  Email responses
: and I'll post if there's interest.
 
: Thanks and cheers,

Are you try mailing about this problem to author (me).

Your version of libftp don't correct transfer peremeters. Try retrive new
version of library from lpuds.oea.ihep.su:/libs and relink it.

Peoples!!! If who have ideas about expandet this library , please write 
mails about it to me... Thanks.

Oleg Orel





-- 
---------------------------------------------------------------------------
| Oleg Orel, Russia, Protvino       |   orel@lpuds.oea.ihep.su            |
| Institute of High Energy Physics  |   Home Phone: 49106                 |
---------------------------------------------------------------------------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Oct 1993 23:36:40 GMT
From:      andr@elvis.sovam.com (Andrei Arkhipov)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C subnetting

In article JHM@pippen.ub.com, Alain Struyf <astruyf@UB.com> writes:
>In article <znr749222444k@nlbbs.com> David Pratt, dpratt@nlbbs.com writes:
>> We have a new class C Internet number at our school... How do I go about
>> subnetting this and why would I want to...
>
>RFC1219 (On the assignement of subnetnumbers) could be a good start for
>you. However, on the why you would want to subnet a class C...
>
>Alain.


Why not? I have a Class C network with subnet mask 255.255.255.224 and have no
problems. In the config original author described it's possible to use netmask
255.255.255.192, I think. 

Andrei.



-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 93 03:57:49 GMT
From:      perl@dwrsun4.UUCP (Robert Perlberg)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Changing IP addresses (SUMMARY)

Thanks to the responses I received from the net I solved the problem.

I brought the system down, changed the /etc/hosts file, deleted the
directory containing the NIS maps, and rebuilt the maps with ypinit.  I
also deleted the files from /var/yp/binding.  I don't know whether I
needed to do both or which of the two would have been enough, but I
didn't have the luxury of enough downtime for experimentation.

My theory is that doing the NIS make in single-user mode didn't
properly update the maps.  I tried doing the NIS make in multi-user
mode but that caused the system to hang since it could not access its
own NIS.

I've never completely understood NIS.  It seems so simple, or at least
it should be, and yet any time I try to do anything with it I wind up
having to rebuild from scratch.  I haven't worked with NIS+ (I haven't
upgraded to Solaris 2.x yet) so I don't know if it is better in this
respect.

Robert Perlberg
Dean Witter Reynolds Inc., New York
dwrsun4!perl@murphy.com -or- philabs!dwrsun4!perl

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 1993 04:47:17 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! Where do ftp transfers go?

John Hascall (john@iastate.edu) wrote:
: Henry_Choy@engr.usask.ca (Henry Choy) writes:
: }I'm trying to use tcpdump to read the network traffic due to ftp
: }activity. When the ftp starts, tcpdump spits out some info, but
: }tcpdump stops after that even though I'm transferring millions of
: }bytes. Does this mean the information in the file cannot be seen
: }with tcpdump?
 
:     FTP uses a control connection and a data connection.
:     It would seem you are watching only the control connection.
:     See RFC959 (available at your better ftp sites) for details.

Thanks to all who made suggestions!

I backed off on the filter to see all tcp packets as opposed to
ftp port tcp packets. I saw more of my transfer. I'm
checking to see if I can now see all my transferred data.

--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sun, 03 Oct 93 19:53:59 -0600
From:      "BSW Gateway" <p00122@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Short Course on SNMPv2

| The following message was forwarded from Northeastern University
| because of USENET trouble there. Please send all private replies to
| "gisele@neu.edu (Gisele Crepeau)", not to this gateway system.

From: gisele@neu.edu (Gisele Crepeau)
Organization: Northeastern University
Subject: Short Course on SNMPv2
Newsgroups: comp.protocols.tcp-ip

October 18-19. SNMPv2: The New Wave in Network Management. William
Stallings conducts an intensive short course on SNMPv2, including protocol
functions, security features, and coexistence/transition. Cape Cod, MA.
Contact:

Northeastern University, Center for Continuing Education State-of-the-Art
Program, 370 Common street, Dedham, MA 02026. Tel: 617-320-8000 ext. 8052
or 800-367-5376 (outside MA).



-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Oct 1993 12:42:05 GMT
From:      tstiller@sarnoff.com (Tom Stiller)
To:        comp.protocols.tcp-ip
Subject:   Re: audio conferencing software - mbone

In article <rturner.749511410@imagen>, rturner@imagen.com (Randy Turner)
wrote:

> 
> 	I am looking for the software that allows internet-wide
> 	audio conferencing between <n> numbered audio-capable 
> 	workstations...Recently I heard that it was on one of
> 	the machines in the lbl.gov domain but I forgot which one.
> 
> 	Also, I believe I will also need the SunOS 4.1 kernel
> 	patches to support IP Multicast.  Does anyone know where
> 	these patches are and possibly provide some quick procedure
> 	for building the kernel with these new changes ?
> 
> 	Thanks!
> 		Randy
> 

Please add my name to the list.
Tom Stiller
-- 
Everyone's entitled to my opinion

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Oct 1993 14:55:01 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time

In article <CE9x4G.2u9@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:

% Even when you do use NTP (or other protocols) to get the time from a
% better source, it is best to use NTP on only a few trusted time lords,
% and let them distribute time via timed-TSP to the local rabble.  Maybe
% NTP implementations will eventually be improved to do that also.

I disagree.  Timed isn't all that helpful really.  

The best thing to do is to simply run NTP on all of one's machines.
For that matter, if you care about time, you should be running NTP
with the DES or MD5 authentication enabled.

Ran
atkinson@itd.nrl.navy.mil


-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Oct 1993 19:31:44 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Opinions wanted on network harware

In article <andym-021093123901@sthwark.demon.co.uk> andym@sthwark.demon.co.uk writes:

>I'm currently evaluating various vendors routers, hubs, management software
>etc. which I'll be using to set up a modest multi-protocol internetwork
>between four of our sites. 
 
>It seems like there aren't many vendors which do a complete range as
>mentioned above. The only one I've found so far is HP, who can provide
>everthing I need to build the internet, from the central router down to
>individual transceivers. It would certainly make my life a lot easier if I
>had a single point of contact for support, maintenance etc. and I would
>think going for a single vendor should minimise interoperability problems.
>
>Does anyone have experience of HP hardware, or have any recommendations ?
 
>Andy McClements           e-mail:     andym@sthwark.demon.co.uk

Andy,

This kind of strategic planning is what I do all the time.

Regarding HP, I respect them a great deal (and used to work for them in
the UK) however, I would not advise a one-stop-shopping approach to
all your networking needs.  (I wouldn't describe HP as a network
design, integration and support company).

There are few companies which manufacture and integrate systems and
networks satisfactorily.  However, the benefits of one-stop-shopping 
are more than outweighed by your being able to select best of breed 
from each main technology.  I would advise you split your plannig and 
procurement into:

	Cabling (UTP, fibre)  -  specialists cabling installers

	Repeaters and 10baseT components  -  speciality LAN companies
	or hub dealers.  (You may want to select the type first, eg.
	Cabletron, HP Ethertwist, UB, 3Com (British design, ex-BICC
	ISOLAN) DEChub 90, Synoptics etc.  then shop around for the 
	best deal).

	Bridges & routers next  -  look to the market leaders (3Com,
	Wellfleet, Cisco etc. )	unless you are very familiar with
	installing and configuring routers.

	Network management systems  -  as you are unlikely to buy one 
	which supports ALL possible MIB extensions, I would advise that 
	you choose your NMS to manage the hubs as a priority.  You can	
	always manage other devices (if their MIB isn't supported)
	by a telnet session.

There are some good "network integration" companies around, such as 
ACT CableStream, Computer International and Spider Networks (also BT
and Hg will bid for big networks) but these companies charge for 
network design, project management, training courses etc. and I guess
you are keen on spending the minimum on these things and  doing
your own (especially the design!!)

Hope this helps (and apologies to any vendors who I've omitted)


-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 1993 09:36:52 -0700
From:      schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: Design of parallel TCP. Is it possible ?

++ >> I'm wondering if TCP protocol can be parallelized to make the
++ >> processing of the protocol more effective.

You might want to check out some of the following articles, which are
listed in no particular order.  The first three discuss parallelizing
TCP in particular, the next seven discuss parallelizing other
protocols (such as TP4, XTP, IP etc.), and the remaining two discuss
communication framework issues for multi-processor platforms.

My apologies if I've omitted anything or anyone by accident.	

	Doug

----------------------------------------
@inproceedings{Zitterbart:92d,
	AUTHOR ="O.G. Koufopavlou and A. N. Tantawy and Martina Zitterbart",
	TITLE = "{Analysis of TCP/IP for High Performance Parallel Implementations}",
	BOOKTITLE="17th Conference on Local Computer Networks", 
	ADDRESS="Minneapolis, Minnesota",
	MONTH =sep,
	YEAR=1992,
}

@inproceedings{Schwartz:93b,
	AUTHOR = "M. H. Nguyen and Mischa Schwartz",
	TITLE = "{Reducing the Complexities of TCP for a High-Speed
	Networking Environment}",
	BOOKTITLE = infocom,
	ORGANIZATION="IEEE",
	ADDRESS="San Francisco, California",
	YEAR = 1993
}

@inproceedings{Bjorkman:93,
	AUTHOR = "{Mats Bjorkman and Per Gunningberg}",
	TITLE = "{Locking Strageties in Multiprocessor Implementations
	of Protocols}",
	BOOKTITLE=sigcomm,
	ORGANIZATION="ACM",
	ADDRESS="San Francisco, California",
	YEAR=1993
}
----------------------------------------
@inproceedings{Ito:92,
	AUTHOR="M. Goldberg and Gerald Neufeld and Mabo Ito",
	TITLE="{A Parallel Approach to OSI Connection-Oriented Protocols}",
	BOOKTITLE="Proceedings of the $3^{rd}$ IFIP Workshop on 
	Protocols for High-Speed Networks",
	ADDRESS="Stockholm, Sweden",
	YEAR=1992,
	MONTH=may,
}

@article{Ito:93,
	AUTHOR="Mabo Ito and Len Takeuchi and Gerald Neufeld",
	TITLE="{A Multiprocessing Approach for Meeting the Processing
	Requirements for OSI}",
	JOURNAL=ieeejsac,
	MONTH=feb,
	YEAR=1993,
	PAGES="220--227",
}

@inproceedings{Schwartz:93a,
	AUTHOR = "Thomas La Porta and Mischa Schwartz",
	TITLE = "{Performance Analysis of MSP: a Feature-Rich
	High-Speed Transport Protocol}",
	BOOKTITLE = infocom,
	ORGANIZATION="IEEE",
	ADDRESS="San Francisco, California",
	YEAR = 1993
}

@inproceedings{Zitterbart:92c,
	AUTHOR ="A. N. Tantawy and Martina Zitterbart",
	TITLE = "{Multiprocessing in High Performance IP Routers}",
	BOOKTITLE="3rd International IFIP WG 6.1/6.4 Workshop on
	Protocols for High-Speed Networks", 
	ORGANIZATION="IFIP",
	ADDRESS="Stockholm",
	MONTH =may,
	YEAR=1992,
	ABSTRACT = ""
}

@inproceedings{Zitterbart:93b,
	AUTHOR ="Torsten Braun and Martina Zitterbart",
	TITLE = "{Parallel Transport System Design}",
	BOOKTITLE="{Proceedings of the 4$^{th}$ IFIP Conference on High
	Performance Networking}", 
	ORGANIZATION="IFIP",
	ADDRESS="Belgium",
	YEAR=1993,
	ABSTRACT = ""
}

@inproceedings{Schwartz:90,
	AUTHOR="Jiraj Jain and Mischa Schwartz and Theodore Bashkow",
	TITLE="{Transport Protocol Processing at GBPS Rates}",
	BOOKTITLE=sigcomm,
	ORGANIZATION="ACM",
	ADDRESS="Philadelphia, PA",
	YEAR=1990,
	MONTH=sep,
	PAGES="188--199",
}

@article{Haas:91,
	AUTHOR = "Zygmunt Haas",
	TITLE = "{A Protocol Structure for High-Speed Communication
	Over Broadband ISDN}",
	JOURNAL = "IEEE Network Magazine",
	YEAR = 1991,
	MONTH = {January},
	PAGES = "64--70",
}

@article{Woodside:89,
	AUTHOR = "C. Murray Woodside and J. Ramiro Montealegre",
	TITLE = "{The Effect of Buffering Strategies on Protocol
	Execution Performance}", 
	JOURNAL = "IEEE Transactions on Communications",
	YEAR = 1989,
}
----------------------------------------
@inproceedings{Presotto:93,
	AUTHOR="David Presotto",
	TITLE="{Multiprocessor Streams for Plan 9}",
	BOOKTITLE="Winter USENIX Conference",
	ADDRESS="San Diego, CA",
	ORGANIZATION="USENIX",
	MONTH=jan,
	YEAR=1993
}

@inproceedings{Sequent:90,
	AUTHOR="Arun Garg",
	TITLE="{Parallel STREAMS: a Multi-Process Implementation}",
	BOOKTITLE="Winter USENIX Conference",
	ADDRESS="Washington, D.C.",
	MONTH=jan,
	YEAR=1990
}
-- 
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 01:03:26 GMT
From:      pace@mailer.cc.fsu.edu (Don Pace)
To:        comp.protocols.tcp-ip
Subject:   NAT IP Routers


I am looking in to setting up a inexpensive network.  I have been
told that the NAT IB/290 remote IP router is a good
choice for wht I am doing, but have not had any experience
with them.  If you have had any experiences good or bad with them,
could you please drop me a note so I know what I am getting into.

Thanks
Don Pace


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 1993 03:17:53 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip
Subject:   HELP! What protocol do I have?

I have TCP packets transmitted over an ethernet wire.
What protocols are these packets nested in? Is it 802.3?
Is there another level of nesting?

--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Mon, 04 Oct 93 10:04:04 -0400
From:      "Jeff Milloy" <p00633@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Vendor MAC Addresses

ISC has developed an Ethernet Bridge w/ISDN, Frame Relay, and Sync 
access and needs to acquire a block of Vendor MAC Addresses.  Can 
someone please tell me who controls the assignment/purchase of Vendor 
MAC Addresses these days?

Thanks in advance,

/Jeff


-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 03:59:46 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: Design of parallel TCP. Is it possible ?

In article <1993Oct1.192743.14972@sics.se> craig@sics.se (Craig Partridge) writes:
>> I'm wondering if TCP protocol can be parallelized to make the
>> processing of the protocol more effective.
>
>Leaving aside the notion of what `effective' is, the answer is yes, TCP
>can be parallelized, and in ways that make at least some good use of the
>multiple processors.

Craig mentioned some work. You may also want to check out John
Zweig's work at UIUC on parallel IP suites. 




-- 
David Boyes      | This signature modified to be inoffensive to any race,
dboyes@rice.edu  | color, creed, sexual orientation, or programming limitation.
My opinion is my | Sober pursuit of truth and to all high ideals consecrated?
own.             | Look, it says so right on the box, next to the Vitamin A.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 04:00:13 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time

In article <CEBtFq.Cn@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>In article <CE9x4G.2u9@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>
>% Even when you do use NTP (or other protocols) to get the time from a
>% better source, it is best to use NTP on only a few trusted time lords,
>% and let them distribute time via timed-TSP to the local rabble.  Maybe
>% NTP implementations will eventually be improved to do that also.
>
>I disagree.  Timed isn't all that helpful really.  
>
>The best thing to do is to simply run NTP on all of one's machines.
>For that matter, if you care about time, you should be running NTP
>with the DES or MD5 authentication enabled.


If you care about time, then I agree that you should be using the current
version of NTP with authentication enabled and "peering" with a low
stratum server.

However, in what way is timed not "all that helpful really"?  The vast
majority of people who use computers, not to mention the population at
large, does not really care, and thinks that a minute or two is "close
enough for goverment work."  They clearly find discussions of computers
that all stay within milliseconds of one atomic clock in a basement
somewhere bizarre and/or boring.

The vast majority of computer users and operators are like the perverbial
VCR owners with the blinking "12:00".  Almost all customers do not even
set the local timezone.  They do not know or care or understand about the
implications of network time for things like `make` and NFS.  A scheme
that automagically causes all computers within broadcast range to the same
second, even if it is hours (wrong timezone) plus minutes wrong (based on
their setting of Mickey to what the airline attendant said on their last
flight) is great.

(If time is a hobby, and keep you keep your wristclock within a second or
two of WWV, have you ever wondered if the airlines really know how often
and how early or late they are?  The people who annouce the local time in
the airplanes certainly don't know what time it is.)


Vernon Schryver    vjs@rhyolite.com

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 93 09:41:56
From:      amoss@serenade.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

   (Vernon Schryver) writes:

   % Even when you do use NTP (or other protocols) to get the time from a
   % better source, it is best to use NTP on only a few trusted time lords,
   % and let them distribute time via timed-TSP to the local rabble.  Maybe
   % NTP implementations will eventually be improved to do that also.

   I disagree.  Timed isn't all that helpful really.

I didn't see the original question but if you are reffering to the precision
timed/timeslave can produce then I must say that I found SGI's bundled
timeslave very accurate in following time from a server.

   The best thing to do is to simply run NTP on all of one's machines.
   For that matter, if you care about time, you should be running NTP
   with the DES or MD5 authentication enabled.

Does anyone have experience in running xntp3 in a "broadcast-client" mode?
It doesn't work for me.

   Ran
   atkinson@itd.nrl.navy.mil

--Amos
--
--Amos Shapira (Jumper Extraordinaire) | "If it was good enough for Jesus
C.S. System Group, Hebrew University,  |  then it is good enough for our kids"
Jerusalem 91904, ISRAEL                |      -- A U.S. Senator
amoss@cs.huji.ac.il                    |         about the English language

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 93 15:43:08 -0600
From:      cichanowski@vax2.winona.msus.edu
To:        comp.protocols.tcp-ip
Subject:   "super" netting class c

If I have 32 consecutive class C  addresses that line up on the appropriate bits, can
I avoid the need to route between them if I use the following subnet mask?
255.255.224.0

I have tried this with NCSA telnet and it assumes that the 32 class Cs are on the same
net. (It does an arp for the other class C address, not the gateway.)   I assume that most IP implementations apply masks without considering what
address classes are being used.  Does anyone know of hidden problems this might
create or implementations of IP that consider address class before subnet masking?


-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 09:10:10 GMT
From:      kc2x@andrew.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Windows-based NNTP newsreader

In article <749639482.AA02735@compsol.fidonet.org> ben@compsol.fidonet.org (ben elliston) writes:
>I'm looking for a Windows-based NNTP newsreader - can someone please point me in the direction of one? (Preferrably shareware/freeware).
>
>Thanks.
>
>Cheers, Ben
>
> * Origin: % EchoSprint: bringing HS/Link to your FrontDoor! % (3:620/262)

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 09:37:40 GMT
From:      samson@china5 (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   Buffer checking of Socket steam

Dear all tcp-members,
	Sorry to ask a probably very simple question. When I start a socket
connection, how to check if the remote side send any data. So that I can
avoid the reading to a socket handle will be suspended until the remode side
send something. To check that socket handle as a file handle is useless.
Is there any method to perfome such a funtion.
	I will be very appreciate if someone can tell me some clues about
it. 
	Thank you for reading this boring message.

 *Samson Chen (³¯ ²Ð «T)         
 *samson@chpi.edu.tw              
 *department of Computer Science  
 *Chung-Hua Polytechnic Institute, Hsin-Chu, Taiwan           

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Sun, 03 Oct 1993 18:16:00 +1000
From:      ben@compsol.fidonet.org (ben elliston)
To:        comp.protocols.tcp-ip
Subject:   Windows-based NNTP newsreader

I'm looking for a Windows-based NNTP newsreader - can someone please point me in the direction of one? (Preferrably shareware/freeware).

Thanks.

Cheers, Ben

 * Origin: % EchoSprint: bringing HS/Link to your FrontDoor! % (3:620/262)

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 11:27:17 GMT
From:      feigin@iis.ee.ethz.ch (Adam W. Feigin)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time

amoss@serenade.cs.huji.ac.il (Amos Shapira) writes:


>Does anyone have experience in running xntp3 in a "broadcast-client" mode?
>It doesn't work for me.

We've been running it here on a few machines to test it out before
using it more extensively. What version of xntp3 are you using ? I
hadn't tried it until the relatively recent versions.

							/AWF
------------------------------------------------------------------------------
Internet: awf@iis.ee.ethz.ch				 Adam W. Feigin
UUCP:{backbones}!iis!feigin			     Network Systems Manager
Mail: Integrated Systems Laboratory	      Institute for Integrated Systems
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41 1 632 50 53					FAX: +41 1 252 09 94
      
"I'd like to donate my body to science after I die, but I'm afraid its
taken far too much of it already"

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 15:34:31 GMT
From:      vatsan@maxwell.ccs.att.com (Vatsan Srivathsan)
To:        comp.protocols.ibm-main,comp.protocols.tcp-ip
Subject:   tn3270-ISPF Problem


 Hello,

       I am trying to use tn3270 from a SUN Sparc server 630 to logon to an IBM mainframe running MVS. I am having a problem bringing up ISPF. It gives me the following error "ISPP330 BDISPMAX EXCEEDED  -/-100 DISPLAYS EXCEEDED IN BATCH MODE ON PANEL ISR@PRIM".
       I am not sure if tn3270 is able to make a successful 3270 connection. I am able to logon and work on native TSO mode. Did anybody try this before and succeed???. Any help would be appreciated.
       Please email to my id   vatsan@maxwell.ccs.att.com.

Thanks


-- 
Raj Srivathsan				
AT&T Consumer Information Management
vatsan@maxwell.ccs.att.com
rsrivathsan@attmail.com

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 15:48:56 GMT
From:      constant@harker.com (Constance Harker, 408-295-6239)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.nfs
Subject:   Seminars in Boston, TCP/IP and NFS, Building and Managing TCP/IP WANs


Harker Systems is proud to announce two seminars on TCP/IP Networking in
Boston, MA:

	_TCP/IP,  NFS and NIS_	  October 25-27, 1993		

	and

	_Building and Managing TCP/IP Wide Area Networks_  October 28-29, 1993


These classes are designed for the MIS professional or UNIX System
administrator who wishes to install, configure, and debug UNIX Ethernet
TCP/IP networks.  Configuring and maintaining the Network File System
(NFS) and the Network Information Service (NIS) is explained. These classes
provide a thorough grounding in the concepts behind installing and managing
a TCP/IP network, as well as giving practical suggestions and covering the
pitfalls of managing TCP/IP networks.

Each course covers a different area of UNIX TCP/IP networking:

_TCP/IP, NFS and NIS_ is a solid introduction to TCP/IP networking and using
NFS and NIS on a UNIX network

_Managing and Building a TCP/IP Wide Area Network_ covers the advanced
topics of building and managing a UNIX TCP/IP network

Course Fees:
	_TCP/IP,  NFS and NIS_					$1,050
	_Building and Managing TCP/IP Wide Area Networks_	$700

Fees include the seminar, seminar notes, lunch, and refreshments.

For more information call (408) 295-6239 or send email to info@harker.com
 
_TCP/IP, NFS and NIS_

_TCP/IP, NFS and NIS_ covers the IP protocol, the TCP and UDP
protocols, IP routing protocols, Berkeley sockets, connecting a UNIX
workstation to the network, and the common user network applications,
Telnet. FTP, rlogin, rsh, and rcp.  The Network File System (NFS) and
Network Information Service (NIS) portion of the class covers the Sun
Network File System including setting up and managing NFS and NIS, the
automounter, NFS debugging, and an overview of NIS+.

After this three day seminar you will:

*Understand the IP protocols and IP routing
*Be able to configure network interfaces, routers, and network daemons 
*Debug TCP/IP problems using the OSI 7 layer model
*Be familiar with the standard Berkeley user networking commands
*Use the standard Berkeley TCP/IP networking commands
*Set up and manage NFS and NIS
*Understand how UNIX system administration is changed with NFS and NIS
*Set up and use the automounter
*Debug NFS and NIS problems
*Tune NFS performance
*Understand NIS+ and the migration issues involved

Day one:	The TCP/IP protocol stack
	OSI 7 layer model as it relates to the TCP/IP protocol suite
	The IP network layer protocols
	TCP/IP packet types
	The TCP and UDP transport protocols
	The Berkeley socket interface
	The Internet routing protocols,
		RIP (routed)
		Overview of advanced exterior routing protocols

Day two:
	Common user programs that use the TCP/IP network
		Telnet, FTP, tftp, rlogin, rsh, and rcp
	Files that control network access and security
	An introduction to NFS
	Remote Procedure Call (RPC)
	eXternal Data Representation (XDR)
	Setting up NIS servers
	Using the NIS databases on client machines

Day three:
	The operational flow of mounting and using an NFS file system
	Installing and using the automounter
	Creating and using custom NIS maps
	Debugging NFS and NIS problems
	Overview of installing and maintaining NIS+


Prerequisites: Attendees should have a working knowledge of UNIX commands and
a basic understanding of UNIX system administration

For more information call (408) 295-6239 or send email to info@harker.com
 
_Managing and Building a TCP/IP Wide Area Network_

_Managing and Building a TCP/IP Wide Area Network_ covers the issues
and responsibilities of building and managing a UNIX TCP/IP network.
This course was designed for the MIS professional or UNIX system
administrator who want to understand the technologies used in building
a Wide Area Network (WAN) using TCP/IP routers, dial-up phone lines,
and leased lines.  The course covers:

The Simple Network Management Protocol (SNMP) and the domain naming
	system (named) as tools to aid in management.
Connecting groups of Local Area Networks (LAN) into campus Metropolitan
	Area Networks (MAN) or global Wide Area Networks (WAN).
Technologies for building a Wide Area Network (WAN) using TCP/IP
	routers, dial-up phone lines, and leased lines.
Building a back-bone corporate Metropolitan Area Network (MAN) by
	connecting Ethernet LANs using a fiber optic FDDI backbone.

After this two-day seminar you will:

*Understand the mechanics of managing a TCP/IP network, and what 
	tools and procedures are recommended
*Create consensus in the user community between users and network managers
*Be able to configure, use and maintain the domain naming system (named)
*Be familiar with the Simple Network Management protocol (SMNP), SNMP Network
	Management Stations and SNMP Agents.
*Understand how to combine the different LAN, MAN, and WANs in to
	robust internet network
*Configure the LANs and backbone of a campus location into a self contained MAN
*Use the MANs as building blocks to create the corporate WAN
*Use the IP routing protocols to create universal connectivity while
	maintaining control over what connectivty is allowed 
*Connect a corporate WAN to the world wide Internet
*Be able to protect network security by building a firewall router
*Understand the issues of reliability, performance, and network security

Day one:
	The domain naming system (named)
	Network management tasks
	Organizing your user community
	Simple Network Management Protocol (SNMP)
	Monitoring the network

Day two:
	Understanding TCP/IP routers
	TCP/IP routing protocols used with WANs
		Exterior Gateway Protocol (EGP)
		Boarder Gateway Protocol (BGP)
		Open Shortest Path First (OPSF)
	Leased line circuits types and services
		Digital fractional T1, T1, and T3
		An introduction to advanced telecom standards
			ISDN, Frame Relay, SMDS, ATM
	Building a campus network using FDDI
	Building a WAN using leased lines
	Building a WAN using dial-up phone lined lines and
		Point to Point Protocol (PPP)
	Connecting to the Internet
	Building a firewall router
	WAN network security
	Working with your long distance service provider

Prerequisites: _TCP/IP,  NFS and NIS_ course or equivalent experience.
Attendees should have a working knowledge of UNIX system administration
and setting up TCP/IP networks.

For more information call (408) 295-6239 or send email to info@harker.com


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 1993 18:37:21 GMT
From:      clark@berg.irpa.vt.edu (Clark Gaylord)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp script

Damoder Donur (donur@pilot.njin.net) wrote:
: i would like to know is there any ftp script that I can put into
: cron file to get the file from the pc which is connected to network.

The only way I have been able to do this is by having ftp read from
stdin.  Try:
--- begin junk ---
anonymous blah@phoo
cd /pub/mystuff
get thisstupidfile.txt
quit
---  end  junk ---
$ ftp < junk

Clark

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Mon, 04 Oct 93 19:07:10 +010
From:      bg@tnis.frmug.fr.net (Bernard.Guillaumot)
To:        comp.protocols.tcp-ip
Subject:   TN5250


Hi,

Can someone please advise me on the TCP/IP products (free or commercials)
with support of TN5250 (Telnet 5250) and/or TN3270 (Telnet 3270), for :

1)      PCs - DOS with/without Windows ?

2)      Unix platforms (Risc, Cisc) ?

3)      others systems like VMS ?


Mabe you can help me by the addresses (postal, fax, email, ..) of
providers/vendors of these products and any details regarding them.
Any help you can give will be gratefully appreciated.

Best regards.

Bernard.


--
bg@tnis.frmug.fr.net (Bernard.Guillaumot)
T.nis - Telecoms dedicated private server : (33)-{1}46-085-205 - GMT+0100

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 93 20:39:49 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Writing a new TCP/IP based on raw sockets on Sun4 (OS

In article <phone.749549371@cairo> phone@cairo.anu.edu.au writes:

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

   >                           Oh, you also need superuser privilege to
   >create a raw socket.

   of course, if you are running ESIX, this is false.  (unless its been
   ``fixed'' in a new version)

Could be.  ESIX is under new management, and they take bug reports
very seriously.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      04 Oct 1993 22:05:46 GMT
From:      dtm@Ebay.Sun.COM (Duane T. Mun)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp script

"Damoder" == Damoder Donur <donur@pilot.njin.net> writes:

Damoder> i would like to know is there any ftp script that I can put
Damoder> into cron file to get the file from the pc which is connected
Damoder> to network.

Try this...

-------------------------------------
ftp -n << EOFTP
	open <machine name>
	user <login name> <password>
	<commands>
	...
	quit
EOFTP
-------------------------------------

-- dtm

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 05:00:49 -0400
From:      erik@rat.SE (Erik Heimdahl)
To:        comp.protocols.tcp-ip
Subject:   Sockets and bind...


I have just started testing to write some small testprograms for  
communication between Unix-mashines. 

I have the book "Internetworking with TCP/IP vol 1" by  
Douglas.E.Comer and on page 360 is an example program that i wanted  
to test.
When started, an errorcode from bind is returned.

	bind: Can't assign requested address.

The errno variable is 49

Why isn't the test-program executed properly ??

My hardware is a NeXT Station Color.
I'm member of the group "operator"

Whats wrong ???


	/erik

PS.

	_PLEASE_ anwser by mail (erik@rat.se), since I don't recieve  
this newsgroup.

DS.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Oct 1993 23:18:53 GMT
From:      samy@fraser.sfu.ca (Sam Yee)
To:        comp.protocols.tcp-ip
Subject:   telnet and term emulation recognition

When I telnet from one machine to another, how does the destination
machine know what terminal emulation I am using?  Off course, this
doesn't always happen, so I want to know how to make it always
happen.

thanks,
-sam
P.S. Please reply by e-mail as I don't read this newsgroup often.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Mon, 04 Oct 1993 08:29:03 +1000
From:      ben@compsol.fidonet.org (ben elliston)
To:        comp.protocols.tcp-ip
Subject:   Windows-based NNTP newsreader

 > I'm looking for a Windows-based NNTP newsreader - can
 > someone please point me in the direction of one?
 > (Preferrably shareware/freeware).

I found one!  Trumpet for Windows is available on ftp.utas.edu.au for anyone who was also interested in such a beast.

Cheers, Ben

 * Origin: % EchoSprint: bringing HS/Link to your FrontDoor! % (3:620/262)

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      05 Oct 1993 02:20:28 GMT
From:      pst@cisco.com (Paul Traina)
To:        comp.protocols.tcp-ip, cichanowski@vax2.winona.msus.edu
Subject:   Re: "super" netting class c

In article <1993Oct4.154309.5795@msus1.msus.edu> cichanowski@vax2.winona.msus.edu writes:

   Path: cronkite.cisco.com!decwrl!spool.mu.edu!umn.edu!msus1.msus.edu!msus1.msus.edu!news
   Newsgroups: comp.protocols.tcp-ip
   From: cichanowski@vax2.winona.msus.edu
   Date: 04 Oct 1993 13:43:08 PST
   Reply-To: cichanowski@vax2.winona.msus.edu
   Organization: Winona State University - minnesota
   Nntp-Posting-Host: 134.29.91.32
   X-Newsreader: IBM NewsReader/2 v1.00Lines: 9
   Lines: 9

   If I have 32 consecutive class C  addresses that line up on the appropriate bits, can
   I avoid the need to route between them if I use the following subnet mask?
   255.255.224.0

   I have tried this with NCSA telnet and it assumes that the 32 class Cs are on the same
   net. (It does an arp for the other class C address, not the gateway.)   I assume that most IP implementations apply masks without considering what
   address classes are being used.  Does anyone know of hidden problems this might
   create or implementations of IP that consider address class before subnet masking?

It sounds to me as if you're trying to BRIDGE together thirty-two
class C networks, since you want to be able to ARP to a different
network number but still expect to get there (unless you are holding
the world together by proxy-arp).

That's not really what we intended when CIDR was being written,  and
you may have some "backwards compatibility" problems with routers that
aren't aware of supernets (and routing protocols that don't cary
netmask information).

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 03:01:33 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Specifying IP

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

> I know of a major UNIX vendor that ships `timed` turned on, so that there
> are 10's of 1000's of workstations out there happily using timed, with
> their clocks synchronized to about 10 ms.

I think I know which one you mean.... but didn't this vendor also make some
changes to timed, to avoid chasing after bad clocks, jumping the time
unnecessarily, etc?  These are constant problems with the usual timed - I
guess we should distinguish between the timed protocol (which is fine for
non-obsessive applications) and timed implementations, which tend to have
some really pathological behavior.  Maybe this was fixed in BSD 4.4, but
nearly all vendor code is BSD 4.3-derived, at best, and porting socket-
intensive code to some real-world systems is a real pain.

> Timed has one great
> advantage over NTP, at least as NTP is currently used.  Timed can be
> shipped to work out-of-the-box, so that the customer need not look for a
> time server and otherwise fiddle with configuration files.
> Even when you
> do use NTP (or other protocols) to get the time from a better source, it
> is best to use NTP on only a few trusted time lords, and let them
> distribute time via timed-TSP to the local rabble.  Maybe NTP
> implementations will eventually be improved to do that also.

NTP can do this.  The easiest way to set up ntp is to fully configure the
timelords, as you say, then set up everyone else with only a single config
file line: "broadcastclient yes".

Even with timed, you have to set -M on at least one of the systems....

With NTP broadcastclients everywhere, the only disadvantage of NTP is
increased real memory usage.  (And I do have timed running here on systems
that are extremely tight on RAM.)  The advantages are greater accuracy,
resistance to bad clocks, better trace information in case of problems, and
smoother slewing of the clocks.

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

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 93 12:09:09 CDT
From:      bilbrey@cray.com (Timothy Bilbrey)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same ti


Where can I obtain ipxtcp.com

 I presently am running ipx and ip Ie: ncsa telnet on my Novell Workstations
my  netware boot file looks like this
         cd\net
	  ipx
	  netx
	  w8003pkdr (SMC Elite16 packetdriver)

Would ipxtcp work better. Where can iget this generic packetdriver

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 93 09:28:34 GMT
From:      mvwyk@rkw-risc.cs.up.ac.za (Domini)
To:        comp.protocols.tcp-ip
Subject:   OSPF SLIP/PPP ...


Does anyone out there have, or know of a place where I can find FAQs for 
OSPF or SLIP/PPP ?  I am confused as to what these actually are, and what the
issues are surrounding them.

Any info can also be mailed to : mvwyk@rkw-risc.cs.up.ac.za
thnx.

Marius van Wyk.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 08:45:00 +0100
From:      jpmens@ingres.com (Jan-Piet Mens)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PC-NFS 5.0 over packet driver ?

I would like to run PC-NFS 5.0 over a packet driver. I believe I 
need a new \NFS\PCNFS.SYS for this. Can someone enlighten me ?
Where can I get the PCNFS.SYS file for packet driver (archie doesn't
say much... :-)

Regards,
	Jan-Piet
-- 
Jan-Piet Mens                                               jpmens@ingres.com
ASK Ingres GmbH, Frankfurt, Germany                          +49 69 66413-285

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 11:42:48 GMT
From:      5652garsidej@vms.csd.mu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp script

In article <DTM.93Oct4150546@booyaa.Ebay.Sun.COM>, dtm@Ebay.Sun.COM (Duane T. Mun) writes:
>"Damoder" == Damoder Donur <donur@pilot.njin.net> writes:
>
>Damoder> i would like to know is there any ftp script that I can put
>Damoder> into cron file to get the file from the pc which is connected
>Damoder> to network.
>
>Try this...
>
>-------------------------------------
>ftp -n << EOFTP
>	open <machine name>
>	user <login name> <password>
>	<commands>
>	...
>	quit
>EOFTP
>-------------------------------------
>
>-- dtm
If you want to eliminate the "open" and "user" lines put the following
entry into $HOME/.netrc:

machine <MACHINE YOU WANT TO CONNECT TO> login <LOGINNAME> password <PASSWORD>

If my machine is prosserv, this is my script:

ftp prosserv << EOF
   <commands>
   ...
   quit
EOF

Hope this helps,
jg
   

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 12:26:59 GMT
From:      davies@stavanger.sgp.slb.com (Gareth W Davies - Systems Engineer Stavanger)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! What protocol do I have?

TCP is an IP based protocol.

so TCP goes in IP goes in Ethernet packet.

Helps?
GWD


-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 13:22:46 GMT
From:      WJOSEPH@ob.missouri.edu
To:        comp.protocols.tcp-ip
Subject:   good book for tcp/ip

Can someone direct me to a good book for tcp/ip??  The book should also 
include program to explain the implementation.  If you have the book, would 
you please also tell me the publisher so that I can order it from the 
bookstore.  Thanks!!!

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 13:45:55 GMT
From:      hunenr@cis.corp.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Buffer checking of Socket steam

In article <1993Oct4.093740.653@debbie.cc.nctu.edu.tw> samson@china5 (Samson Chen) writes:
>	Sorry to ask a probably very simple question. When I start a socket
>connection, how to check if the remote side send any data. So that I can
>avoid the reading to a socket handle will be suspended until the remode side
>send something. To check that socket handle as a file handle is useless.
>Is there any method to perfome such a funtion.
>	I will be very appreciate if someone can tell me some clues about
>it. 

There are basically 2 ways of doing this:

1. If you have multiple sockets and just need to wait for data on any of
   these, read & process it and then go to sleep again, you can use
   select().

2. If you have other useful things to do and want to process incoming data
   on a socket in an asynchronous fashion, you can setup a signal handler
   for SIGIO. The socket must be configured to generate the SIGIO signal
   using fcntl() calls.

These methods are described in the SunOS Network Programming Guide. I assume
identical or similar mechanism exist on other systems.

Regards,
-Roger

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 14:32:24 GMT
From:      hickey@ctron.com (Gerard Hickey)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Is RMON a standard yet?

Can anyone out there tell me if RMON has become a standard yet? If 
it is not a full standard, what are the groups that have been stand-
arized? 

Thanks..

					Gerard.
-------------------------------------------------------------------
Gerard Hickey				hickey@ctron.com
Cabletron Systems, Inc.			+1 603 337 1577
	My employer probably thinks that I don't
	have any ideas of my own!!
-- 
					Gerard.
-------------------------------------------------------------------
Gerard Hickey				hickey@ctron.com
Cabletron Systems, Inc.			+1 603 337 1577

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 14:32:26 GMT
From:      svanarts@lmsc.lockheed.com (Scott VanArtsdalen)
To:        comp.protocols.tcp-ip
Subject:   Re: Opinions wanted on network harware

andym@sthwark.demon.co.uk (Andy McClements) writes:

( Text Deleted )


>It seems like there aren't many vendors which do a complete range as
>mentioned above. The only one I've found so far is HP, who can provide
>everthing I need to build the internet, from the central router down to
>individual transceivers. It would certainly make my life a lot easier if I
>had a single point of contact for support, maintenance etc. and I would
>think going for a single vendor should minimise interoperability problems.
 
>Does anyone have experience of HP hardware, or have any recommendations ?


>Andy McClements           e-mail:     andym@sthwark.demon.co.uk

Heh, heh, heh.  Be afraid...be very afraid.  Try reading comp.sys.hp 
sometime for a complete description of "HP Support."  Their customer reps 
screw orders up all the time, the maintenace contracts are consistantly 
incorrect, and most of their support people haven't been able to help us.  

Now, not all HP customers have had as bad a time as we but many have.  Their 
hardware seems to be top notch but their support has a ways to go to catch 
up.

If you are going to incorporate HP products into your net then comprising 
your net totally of HP products would be a good (albeit expensive) way to 
go.  If you mix vendor products in your net you're likely to get some finger-
pointing from HP when something goes wrong.

Good luck at any rate...
--------------------------------------------------------------------------    
    \    /\                                           Aeronca 7AC Champ
     \  /__\                                          =(*)= N3115E =(*)=
Scott \/an  \rtsdalen                                "The Boonie Bouncer"
--------------------------------------------------------------------------
        Opinions expressed here do not necessarily reflect those of
           Lockheed Missiles & Space Co., Inc. or its management.   =*
--------------------------------------------------------------------------

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 15:00:16 GMT
From:      ameen@hpcc01.corp.hp.com (Kavetta Ameen)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! What protocol do I have?

I've used those cards with novell before and I'am 99% sure the 3c501 driver
is the one you want. The switchs on the card should not be changed except
as a last resort. The only switch I ever changed was the interupt number
from 3 to 5.
**********************************************************************

From: Bob Bellavance bobb@hppcih58.svale.hp.com

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

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 15:41:52 GMT
From:      leighd@syma.sussex.ac.uk (Leigh Dodd)
To:        comp.protocols.tcp-ip
Subject:   PC-NFS 5.0 on a IBM XT *#%$&^^&

Hi All
        I'm just put PC-NFS V5.0 on a IBM XT and run into a few problems so I
hope someone can help ?.

        Problem 1.

                I want to use PCNFSLPD to make the XT into a print server, when
I run "pcnfslpd -P LPT1: xtp -d" I get the following error :-

        "NFSP004 Enviroment variable NFSDRIVE is unusable"

NFSDRIVE IS SET in the autoexec "SET NFSDRIVE=C"


        Problem 2.

                If I use nfsconf and set up a connection to a remote printer, I
only get the option of LPT2 or LPT3. What happened to LPT1 ?. NOTE. This is with
pcnfslpd NOT running.

Any help please

Leigh

--
*******************************************************************************
* Leigh Dodd (Sun System Administrator)  |      Three Steps to Heaven         *
* University of Sussex                   | 1). C.B.T. ----- Passed            *
* Brighton, England.                     | 2). Part 2 ----- Passed            * 
* INTERNET: leighd@eaps.susx.ac.uk       | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 16:00:21 GMT
From:      WJOSEPH@ob.missouri.edu
To:        comp.protocols.tcp-ip
Subject:   good book for tcp/ip  II

If you read my previous mail and would like to e-mail to me, the e-mail 
address of the previous post is not quite correct.  My E-mail address is
Joseph@ob.missouri.edu   Thanks!!

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 17:04:19 GMT
From:      braun@novell.com (Karl Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C subnetting

In article <CEAMx5.DG0@elvis.sovam.com> andr@elvis.sovam.com writes:
>>
>>RFC1219 (On the assignement of subnetnumbers) could be a good start for
>>you. However, on the why you would want to subnet a class C...
>>
>>Alain.
>
>
>Why not?

He probably wanted to know why you would want to go through the
trouble and expense of routing when you only have (at max) 254 nodes
on the network.

Of course, the answer could be any of:

1)	Security between nodes.

2)	Reliability of segments ("dirty" test network vs. production
	and development network).

3)	Needs for testing across routers.

etc.

kral   408/647-6112                                              
Network Scapegoat in Training                                      NOVELL/DSG
That's the whole problem with science.  You've got a bunch of empiricists 
trying to describe things of unimaginable wonder." - Calvin

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 17:27:29 GMT
From:      mlucas@world.std.com (matthew lucas)
To:        comp.protocols.tcp-ip
Subject:   Source Routing


I want to able to source route across the Internet, but I can't find
the right option to use with setsockopt. Does anybody know how to do
this? Thanks for any references or suggestions.

Matt.


-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 17:51:58 GMT
From:      dcc@scitor.com (Dennis Coyle)
To:        comp.protocols.tcp-ip
Subject:   Subnet Addressing Summary

Orginal Question:
-----------------

I looked at D. Comer's book and RFC950, but I am still not sure if you can
have a subnet address of all zeros. Given the following IP address and Subnet 
mask:
	Class B Address: 149.64.0.0
	Subnet Mask: FF.FF.F8.00 (i.e. 255.255.248.0)

I am reserving 5 bits for subnet addressing and 10 bits for hostids. In most of
the examples, it is stated that the first available subnet would have an
IP address of 149.64.8.X.  My question is what happens if you have an
IP address of say 149.64.1.1 ? Is it mapped into subnet 0 hostid 257?
(i.e., see example below)

  255.255.248.0 => FF.FF.F8.00 (Subnet mask)
  149.64.1.1 =>    95.40.01.01 (IP address)
                   95.40.00.00 => 149.64.0.0 & hostid of 257 ??

My confusion stems from the fact that some of the examples state that a 
5-bit subnet address field will yield 32 physical subnets, but RFC940 states
that "...subnets of all zeros and all ones in the subnet field should not be
assigned to actual (physical) subnets". I understand why you wouldn't
what all 1's, but I do not understand the all 0's.

P.S. Excuse my ignorance, but this is all new stuff for me. Also, I'm not
a regular reader of the group so I would appreciate direct mail. Howerver,
I wll post a summary of the answers.

Thanks in advance

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

Summary of Responses:
--------------------


...All zeroes in a field means "this network|subnet|host", just as all ones
means "all networks|subnets|hosts."  It is never sent, but could be used
in configuration for example.  Since it isn't sent, the code can be hacked
to allow it to be used as an address or subnet number and some stacks do
this.  RFC 1122, says the same thing RFC 942 does.  I wouldn't use it myself
since in a large network you are guaranteed to run into a stack sooner or
later that doesn't support it...



...From what I've been told and seen (on our bridges) 0.0.0.0 is an old unix 
broadcast which still exists for upwardly compatability.  And I think that
the others i.e 139.78.255.255 and 139.78.0.0 are also limited broadcasts and
mean the same thing.

...The all 1's is broadcast, and the all zero's combination usualy means: "This 
net" or in your case "this subnet". This can be used by a sending host if for 
some reason, he doesn't know in what subnet he himself is located.....




..I agree that very often the situation with "all zero's, host zero's or subnet 
zero's" is very unclear, especialy since a lot of people "misuse" the "whatever 
zero's" combination as an alternative to broadcasting.

As a general guideline, it is good practise to avoid a subnet "all zero" as 
well as a subnet "all one" in order to avoid problems....



....If you reference RFC 950, it states the following (referencing RFC 943):

	... When such usage is called for, the address zero
	is to be interpreted as meaning "this", as in "this
	network".... the address 0.0.0.37 could be interpreted
	as meaning host 37 on "this" network.

It also has other examples.

RFC 1009 states: "No subnet should be assigned the value zero or -1 (all
one bits).

In practice, I don't think I've seen anyone using zeros to indicate
this address (bootp or RARP, maybe?), but everyone adheres to this
convention and avoids assigning the all zeros subnet.....


RFC References: RFC1219, RFC1009, RFC950, RFC1122, RFC942

Thanks to all that applied, I hope this helps out some other newbe :) !

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 18:00:36 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP! What protocol do I have?

Henry Choy (Henry_Choy@engr.usask.ca) wrote:
: I have TCP packets transmitted over an ethernet wire.
: What protocols are these packets nested in? Is it 802.3?
: Is there another level of nesting?

I've had a number of very helpful responses! TANX!

--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 18:16:25 GMT
From:      wynn@cms-stl.com (Tim Wynn)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Is NIC running out of unique IP addresses?

	This may be a foolish question, but I'm too much of a novice 
about TCP/IP to know.

	I work for a small software company that is a reseller of
UNIX systems, which also sells medical treatment software.  When we
ship systems out into the field, we will supply them with a unique
domain name and range of IP addresses that we (supposedly) will get
from NIC.  We have not done this yet, but it is a requirement for
when our software ships.

	One of my co-workers is in a UNIX course on TCP/IP right 
now, and he tells me that his instructor said that NIC is running 
out of unique IP addresses.  Because of this, he says, NIC is 
calling people to ask for any unused addresses they might have 
requested in the past.  Furthermore he said, it's next to impossible 
to get contiguous blocks of addresses anymore, and getting any 
addresses takes 6 weeks or more.

	Is there any truth to any of this?  It sounds absurd to me,
but I don't know enough to confirm or refute it.  It would seem that
this situation would be so serious that I would have heard about it
by now.   Does anybody know the truth?  I'm having this co-worker
place a call to NIC to find out.

Thanks for any light some knowledgeable person might shed on this.

Tim Wynn (wynn@cms-stl.com)
=======================================================================
"The difference between writing fiction and non-fiction is that
 fiction has to make sense."
				- Tom Clancy
=======================================================================
    _/_/_/_/    _/      _/   _/_/_/_/   COMPUTERIZED MEDICAL SYSTEMS, INC.
   _/          _/_/  _/_/   _/         56 Worthington Dr. 
  _/          _/   _/ _/   _/_/_/_/   Maryland Heights, MO USA 63043
 _/          _/      _/         _/   tel: 314 434 4394
_/_/_/_/    _/      _/   _/_/_/_/   fax: 314 434 3936

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 1993 15:13:54 +0200
From:      ralfi@support.pem-stuttgart.de (Ralf U. Holighaus)
To:        comp.protocols.tcp-ip
Subject:   Re: TN5250

bg@tnis.frmug.fr.net (Bernard.Guillaumot) writes:

We have implemented a commercial tn3270 application called IP/3270
supporting 3278 and 3279 terminals with several submodels, colors
and extended highlighting. It runs well on SCO UNIX and SCO XENIX,
ports to other platforms will follow on demand.

>Can someone please advise me on the TCP/IP products (free or commercials)
>with support of TN5250 (Telnet 5250) and/or TN3270 (Telnet 3270), for :
 
>1)      PCs - DOS with/without Windows ?

planned.

>2)      Unix platforms (Risc, Cisc) ?

SCO UNIX, SCO XENIX, SCO Open Desktop (in work as GUI version)

>3)      others systems like VMS ?

nope.

Regards
Ralf.
-- 
Ralf Holighaus             | XLINK-POP Stuttgart            | Voice:
PEM GmbH                   | Mail * News * ftp * Internet   | +49.711/713045
Vaihinger Str. 49          | 2 Modems V32bis/V42bis         | Fax:
D-70567 Stuttgart, Germany | ISDN-Zugang (netISDN/netGW)    | +49.711/713047

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 19:19:05 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specifying IP

It could be argued that all of this belongs in some other newsgroup.

In article <CEELqM.KME@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>
>> I know of a major UNIX vendor that ships `timed` turned on, so that there
>> are 10's of 1000's of workstations out there happily using timed, with
>> their clocks synchronized to about 10 ms.
>
>I think I know which one you mean.... but didn't this vendor also make some
>changes to timed, to avoid chasing after bad clocks, jumping the time
>unnecessarily, etc?  These are constant problems with the usual timed - I
>guess we should distinguish between the timed protocol (which is fine for
>non-obsessive applications) and timed implementations, which tend to have
>some really pathological behavior.  Maybe this was fixed in BSD 4.4, but
>nearly all vendor code is BSD 4.3-derived, at best, and porting socket-
>intensive code to some real-world systems is a real pain.

Yes, I made many changes to the 4.3BSD timed code over the years,
and sent the results to be included in 4.4BSD.  Since then I've
found and fixed a few more minor problems, although considering
the history of the code, I could have introduced those bugs.

SVR4.1 and later STREAMS have much better socket emulation libraries.
I can't think off hand of anything in any of the timed code that
seems likely to be problematic even for older STREAMS, with the
possible exception of sending and receiving ICMP timestamps.

The 4.4BSD timed works fine on BSD386 and 386BSD 0.1.

 ...  [about working out-of-the-box]
>Even with timed, you have to set -M on at least one of the systems....

NO!  NO!  NO!  EACH AND EVERY TIMED SHOULD BE RUNNING WITH -M EVERYWHERE!

Sorry, but I've heard and fought that nonsense so many times that
it is very painful.

Absolutely no changes need or generally should be made to systems from
that vendor to have them properly synchronized "out of the box" by timed.
They are shipped with timed running -M (and with "timetrim" turned on).

"-M" does not make a timed daemon a master in a sense that any reasonable
person would understand "master."  Instead, they should have used the word
"moderator."  -M only lets a daemon volunteer (get "elected") to collect
and average participating machines' times and redistribute the result.
Any machine that is stable and secure enough to have its time averaged is
good enough to act as moderator.  About only the reason to turn off -M is 
to mess up time in a network, although the perpetrators usually do not
realize or acknowledge as much.

>With NTP broadcastclients everywhere, the only disadvantage of NTP is
>increased real memory usage.  (And I do have timed running here on systems
>that are extremely tight on RAM.)  The advantages are greater accuracy,
>resistance to bad clocks, better trace information in case of problems, and
>smoother slewing of the clocks.

You didn't mention that modern versions of NTP can include authentication,
or that NTP time has always carried an indication of the accuracy of
the source.

I have no doubt that NTP is far more accurate than timed.

The 4.4BSD timed can slew the clocks as smoothly as possible.  If you turn
on (and port to your system) the ifdef'ed out code, timed does better than
NTP, since it uses the kernel "timetrim" stuff to adjust the raw clock
frequency (unless you also use "timetrim" with NTP, or the NTP new system
call ideas that I understand to have similar aims).  Even without
"timetrim", 4.4BSD timed has some hacks to slew the clock more smoothly
as time get closer.

NTP does have better resistance to intermittently bad clocks, although
4.4BSD timed can be told to ignore lists of bad clocks.

I have heard claims that NTP uses far more CPU cycles than a point-to-point
hack named "timeslave", which uses ICMP timestamps, the UDP time port,
and lots of naive filtering to ride even intermittently asymmetrically
loaded low speed links.


Vernon Schryver    vjs@rhyolite.com

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 20:40:33 GMT
From:      dash@skyy.NoSubdomain.NoDomain (O.P.P)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp script

In article <Sep.30.15.27.34.1993.21933@pilot.njin.net>, donur@pilot.njin.net (Damoder Donur) writes:
|> Hello tcp-ip experts:
|> 
|> i would like to know is there any ftp script that I can put into 
|> cron file to get the file from the pc which is connected to network.
|> 
|> I am administering Rs/6000 servers running AIX(3.2) and also running tcp-ip
|> using ethernet interface.
|> 
|> Everyday I am manually ftping to pc getting some files. So instead of 
|> doing manually is there any script which will automaticall connect to that pc
|> and get the file from pc to rs/6000.
|> 
|> Thanks 
|> 
|> Damoder Donur
|> System Administrator
|> 
|> 
|> email Address:
|> 
|> donur@rs32h.atlantic.edu
|> -------------------------------------------------------------
One way would be to add the following to a script

------------------start here-----------------
(
   echo user username passwd
   echo cd d:\data
   echo get data.dat /usr/tmp/pc/data
   echo quit
)  ftp -n ibmpc > /dev/null
-----------------end------------------------

                o.p.p

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Oct 1993 21:57:43 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Source Routing

> I want to able to source route across the Internet, but I can't find
> the right option to use with setsockopt. Does anybody know how to do
> this? Thanks for any references or suggestions.

Fetch the file networking/ip/trace/traceroute_pkg.tar.Z from ftp.uu.net
and look at the file LSRR.patches.  It contains actual code that shows
how to set the souce rout option.  You want the IP_OPTIONS socket option,
but need to be careful getting all the fields correct.

	Rich Stevens  (rstevens@noao.edu)

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Oct 93 08:13:22 -0400
From:      "Kenneth Chin" <p00872@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   ARP entry timeouts

I'm just curious about what the standard ARP cache entry timeout
may be for routers when they're performing proxy-arp'ing?  In
most cases, I believe that this is configurable, but what do people
usually set it at?

Thanks,
Ken Chin
Pariclete Systems, Inc.
(212)249-0931
p00872@psilink.com


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 02:36:24 GMT
From:      secssxn@mx.secs.csun.edu (Scott Neugroschl)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wollongong and SCO ODT 2.0

Hi.  I'm running SCO ODT 2.0 as an LPD server.  On another 486 PC,
I'm running Wollongong Pathway Access and Pathway Client NFS.  The Network
Driver for Windows installed.  We have an HP LJ4 hooked up to the ODT system.

When we print from Windows to the LJ4 over the net, we get garbage on the
printout.  I believe it is because there is no way to pass the -oraw option
to the SCO spooler.

I would like to know if anyone else is using this sort of configuration,
and if so, if they have gotten this to work.

Thanks

-- 
Scott "The Pseudo-Hacker" Neugroschl
-- Beat me, Whip me, make me code in Ada

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1993 14:13:20 -0500
From:      cassasd@servo.ac.com (Devin Cassas)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   IP over VSAT network


I have RS/6000s communicating over a Hughes VSAT network.  The RS/6000s are
running TCP/IP and the application is having problems with timeouts.  Packets
are always delivered reliably, but I'm not sure about the round trip time.
PING gives me consistantly round trip times in the 3-7 second (yes thats
SECONDS) range.

My question is: does anybody have any experience or knowledge of tuning the
TCP/IP protocol stack to make it work better over satellite network?

If it helps, the IP is encapsulated in SNA at the earth station before it is
beamed into space.

Thank you for your help.

Devin Cassas
devin.cassas@ac.com

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1993 07:20:14 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Host routes on Cisco?

In article <CE7E9v.Ho8-resend@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
    Do Ciscos support host-routes at all?  I've been doing some experiments
    trying to short-cut paths for multihomed hosts, and it appears that Ciscos
    ignore the host part of any route, whether it's received via RIP or given
    as a static route.
    
    Has anyone managed to get this working?  Or, is this a to-be-supported
    feature?  Thanks for any info.

Yes, but you need version 9.1.

Tony



-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 08:03:50 GMT
From:      nh@lem.ee.ethz.ch (Norbert G. Hanke)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PC-NFS 5.0 over packet driver ?

In article <28r8ls$8vm@trsun1.ingres.com> jpmens@ingres.com (Jan-Piet Mens) writes:
>I would like to run PC-NFS 5.0 over a packet driver. I believe I 
>need a new \NFS\PCNFS.SYS for this. Can someone enlighten me ?
>Where can I get the PCNFS.SYS file for packet driver (archie doesn't
>say much... :-)
You just need PKTD40A.SYS as a driver shim to interface to the packet driver.
It is available from bcm.tmc.edu.

Norbert Hanke
Power Electronics Lab, ETH Zurich, Switzerland

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 93 16:06:47
From:      rens@stimpys.imsi.com (Rens Troost)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time

In article <AMOSS.93Oct4094156@serenade.cs.huji.ac.il> amoss@serenade.cs.huji.ac.il (Amos Shapira) writes:

   Does anyone have experience in running xntp3 in a "broadcast-client" mode?
   It doesn't work for me.

What breaks? We're running it in that mode here, and it works fine. I
must ssay it makes life a whole lot easier in a dynamic environment.

-Rens
--
  o===============================================================o
  | J. Laurens Troost - UNIX Systems  | At Work: rens@imsi.com    |
  | Investment Management Svcs, Inc.  | At Play: rens@century.com |
  | 12 East 49th Street,  35th floor  |   Phone: (212) 339-2823   |
  | New York, New York         10017  |     Fax: (212) 339-2854   |
  o===============================================================o
     -- IMS is unlikely to share any of the above opinions --

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 13:15:50 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip
Subject:   Re: Design of parallel TCP. Is it possible ?

Some more references on this subject, slanted towards multiprocessor
STREAMS based TCP/IP.  The work on the X kernel by Larry Peterson et al.
is also crucial (the X kernel architecture seemed to get it right where
Parallel Streams got it wrong).


High Speed Protocol Implementations Based On A Multiprocessor Architecture
Martina Zitterbat, University of Karlsruhe
Proceedings of the IFIP WG 6.1/WG 6.4 International Workshop on Protocols for High Speed Networks
Zurich, Switzerland
May 1989

Multi-Processor Based High-Speed Communication Systems
M. N. Jensen, M. Skov
Technical University of Denmark, Lyngby
6th European Fibre Optic Communications and Local Area Networks Exposition
Amsterdam, Netherlands
June-July 1988

TCP/IP Networking using Transputers 
Roger Peel
Department of Electronic and Electrical Engineering, University of Surrey, Guildford, U.K.
Transputer Research and Applications 3
Amsterdam
1990


A Performance Analysis of Network I/O in Shared Memory Multiprocessors
C. Thekkath, D. Eager E. Lazowska H. Levy
Dept. of Computer Science and Engineering FR-35
University of Washington, Seattle, WA
July 1992

Multithreading your STREAMS Device Driver in SunOS 5.0
Neal Nuckolls
Internet Engineering, Sun Microsystems
December 1991

A High Capacity TCP/IP in Parallel Streams
Ken Dove
Sequent Computer Systems
UKUUG
Summer 1990

Symmetric Multiprocessing in Solaris 2.0
S. Kleiman
COMPCON
San Francisco, California
Spring 1992

Beyond Multiprocessing: Multithreading the SunOS Kernel
USENIX Summer 1992
June 1992
J. R. Eykholt, S. R. Kleiman S. Barton, R. Faulkner, D. Stein,
M. Smith, A. Shivalingiah, J. Voll, M. Weeks, D. Williams
SunSoft, Inc.
San Antonio, Texas

The Parallelization of Mach/4.3BSD: Design Philosophy and Performance Analysis
Joseph Boykin, Alan Langerman
Encore Computer Corporation
Symposium on Experiences with Distributed and Multiprocessor Systems (SEDMS I)
October 1989

Experiences In Parallelisation of Streams-based Communications Drivers
Ian Heavens
Spider Software 
OpenForum Conference on Distributed Systems
November 1992 


ian

---
	 Ian Heavens			ian@spider.co.uk                 
 	 Spider Software
 	 Spider Park, Stanwell Street		
	 Edinburgh, EH6 5NG, Scotland	+44 31 555 5166 (Ext 4735)
--

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1993 14:24:33 GMT
From:      larsen@OES.ORST.EDU (Scott Larsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Is NIC running out of unique IP addresses?

In article <WYNN.93Oct5111625@haduk.cms-stl.com>,
Tim Wynn <wynn@cms-stl.com> wrote:

>	One of my co-workers is in a UNIX course on TCP/IP right 
>now, and he tells me that his instructor said that NIC is running 
>out of unique IP addresses.  Because of this, he says, NIC is 
>calling people to ask for any unused addresses they might have 
>requested in the past.  Furthermore he said, it's next to impossible 
>to get contiguous blocks of addresses anymore, and getting any 
>addresses takes 6 weeks or more.

Not true.  3 weeks ago I requested 6 type "C" addresses and they are 
contiguous.  They arrived in about 3 days.

By the way, addresses are no longer given out by the DDN/NIC.  Here's the
header to the reply from my latest address request:

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

	Please be advised that the DDN NIC (HOSTMASTER@NIC.DDN.MIL) no longer 
	provides NIC services to the INTERNET.  Registration services for the 
	INTERNET have been directed to the INTERNIC as of April 2, 1993.

        E-Mail regarding INTERNET transactions must be directed to 
	HOSTMASTER@INTERNIC.NET Phone questions can be directed to 
	1-800-444-4345 or if outside the continental U.S.A. then call 
	(619) 455-4600.

	Please direct your attached request to HOSTMASTER@INTERNIC.NET and/or 
	call the numbers listed above.

	THE DDN/NIC STAFF

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


>	Is there any truth to any of this?  It sounds absurd to me,
>but I don't know enough to confirm or refute it.  It would seem that
>this situation would be so serious that I would have heard about it
>by now.   Does anybody know the truth?  I'm having this co-worker
>place a call to NIC to find out.

Grinding some numbers from my /etc/networks file (93/08/01) I see:

Network type	Range		# of type	# in use	% Capacity
---------------	---------------	---------------	---------------	----------
A		1-126		126		51		40.5%
B		128-191		16,384		7509		45.8%
C		191-223		2,162,688	40,706		01.9%

(These numbers are already out of date, as numbers have been given out
 since Aug. 1'st, and I'm sure that I introduced some 1-off errors in the
 calculations, due to missing some restricted addresses and such.)

So you can see that there are _PLENTY_ of class "C" addresses available.

In addition, the current class "B" listings stopped at 167.167.0.0, and the
class "C" listings stopped at 202.20.79.0, so you can still get contiguous
blocks of addresses.

However, address depletion is a serious issue.  According to "Supernetting:
an Address Assignment and Aggregation Strategy", by V. Fuller, T. Li, J. Yu,
and K. Varadham, all class "B" addresses could be exhausted within the next
15 months, if the present rate of growth is maintained.  In exchange, large
quantities of class "C" addresses are being given out to avoid this.  This,
though, puts a larger load on routers, as they have larger tables to maintain.

Current research is being done by the ROAD (Routing and Addressing) group of
the IETF (Internet Engineering Task Force).


I highly recommend the book "TCP/IP Network Administration", by Craig Hunt,
published by O'Reilly & Associates ($29.95).  Most of the information here is
contained in this wonderful tome.


Scott Larsen
larsen@oes.orst.edu                      UUCP: hplabs!hp-pcd!orstcs!larsen
--------------------------------------------------------------------------
"Grasshopper, look beyond the game, as you look beneath the surface of the
 pool to see its depths."
		- Master Po

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 14:55:01 GMT
From:      dash@skyy.NoSubdomain.NoDomain (O.P.P)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp script

In article <1993Oct5.204033.14385@b30news.b30.ingr.com>, dash@skyy.NoSubdomain.NoDomain (O.P.P) writes:
|> In article <Sep.30.15.27.34.1993.21933@pilot.njin.net>, donur@pilot.njin.net (Damoder Donur) writes:
|> |> Hello tcp-ip experts:
|> |> 
|> |> i would like to know is there any ftp script that I can put into 
|> |> cron file to get the file from the pc which is connected to network.
|> |> 
|> |> I am administering Rs/6000 servers running AIX(3.2) and also running tcp-ip
|> |> using ethernet interface.
|> |> 
|> |> Everyday I am manually ftping to pc getting some files. So instead of 
|> |> doing manually is there any script which will automaticall connect to that pc
|> |> and get the file from pc to rs/6000.
|> |> 
|> |> Thanks 
|> |> 
|> |> Damoder Donur
|> |> System Administrator
|> |> 
|> |> 
|> |> email Address:
|> |> 
|> |> donur@rs32h.atlantic.edu
|> |> -------------------------------------------------------------
|> One way would be to add the following to a script
|> 
|> ------------------start here-----------------
|> (
|>    echo user username passwd
|>    echo cd d:\data
|>    echo get data.dat /usr/tmp/pc/data
|>    echo quit
|> )  ftp -n ibmpc > /dev/null
     ^
     add the pipe symbol | (curse vi it ate it....)
        so.......

   ) | ftp -n ibmpc > /dev/null

                  o.p.p.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 16:37:56 GMT
From:      ebrill@usr.com (Ed Brill)
To:        comp.protocols.tcp-ip
Subject:   U.S. Robotics announces the addition of SNMP management to Total Control internetworking products


The following is a new product announcement from U.S. Robotics.  The consenus 
of the net was that product announcements of this form were acceptable and 
desirable postings, so here goes.

Inquiries should be directed to 1-800-DIAL-USR or +1-708-982-5001.  The 
USR Systems Products Sales group does not presently maintain an e-mail
address, though I would be happy to forward electronic inquiries to them.

--Ed

-------------------------------------------------------------------------------
     SKOKIE, Ill., -- October 6, 1993 -- U.S. Robotics, Inc., today 
     announced the addition of Simple Network Management Protocol (SNMP) to 
     its line of Total Control internetworking products. With U.S. 
     Robotics' Total Control Manager, network administrators can easily 
     access and manage their network from a single console. Total Control 
     Manager will ship in October.
     
     Total Control Manager can be added to both the Enterprise Network Hub 
     and the Transaction Processing Hub. These complete, one-vendor 
     solutions solve the problem of network integration by combining X.25 
     PADs, modems, terminal servers, CSU/DSUs, and network interfaces into 
     one centrally managed chassis. 
     
     The Enterprise Network Hub enables organizations with remote locations 
     to aggregate their dial traffic onto T1 lines and route it through a 
     packet-switched network to their host computer at a central site.
     
     The Transaction Processing Hub reduces verification times for credit 
     card, point-of-sale, and inquiry/response transaction processing 
     applications by interfacing with the local exchange carriers' 
     services, including Feature Group B, D and 800 lines and routing 
     traffic via T1 trunks to LAN interfaces.
     
     "SNMP has really become the de facto management standard in the 
     industry," said Jonathan Zakin, U.S. Robotics executive vice president 
     of sales and marketing. "By incorporating it into the Total Control 
     products, we no longer add to the number of management consoles on the 
     network.  With SNMP, we become part of the solution of the future."
     
     For Baxter Healthcare Corp., a Total Control customer since 1991, SNMP 
     is a feature it is eager to have. "We have a goal at Baxter to 
     completely automate the entire network's recovery and operation," said 
     Steve Tindall, project leader of Baxter's telecommunications group. 
     "This is a long way off, but industry standards incorporated in 
     a single network platform are one way this goal will be accomplished. 
     With SNMP we can watch most of the network, and since Total Control 
     will now have SNMP, we're one step closer to our goal."
     
     Customers can purchase U.S. Robotics' Total Control Manager with 
     Novell's Netware Management Platform for $3999. For those networks 
     already using the Novell Netware Management Platform, the cost is 
     $2059.  
     
     U.S. Robotics will also provide MIB extensions for customers using 
     packages like HP Openview, SunNet Manager, and Netview 6000 so Total 
     Control can be easily added to these management programs. These MIB 
     extensions will also be available via Internet.
     
     The Enterprise Network Hub and Transaction Processing Hub are a 
     logical extension of the company's Total Control product line. U.S. 
     Robotics' Total Control line of intelligent management systems, 
     introduced in 1990, was the company's first entry into this market. 
     
     Both products use a common architecture, which consists of a 1 Gbps 
     backplane, andcircuit and packet-switched buses to minimize processing 
     time. Through downloadable software-defined technology, U.S. Robotics 
     can easily modify and enhance its products to take advantage of new 
     and emerging technologies. 
     
     U.S. Robotics, Inc., (NASDAQ:USRX), is a leading designer,manufacturer 
     and marketer of data communications systems and products.  Both 
     corporate headquarters and manufacturing operations are based in 
     Skokie, Illinois.  U.S. Robotics owns and operates U.S. Robotics Ltd. 
     in Slough, England, U.S. Robotics, s.a. in Lille, France and P.N.B., 
     s.a. based in Suresnes, France.  The company markets its products to 
     business, industry, government agencies and original equipment 
     manufacturers.
     
     # # # # #
     
     /98
     
     All products mentioned are trademarks or registered trademarks of 
     their respective manufacturers.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 16:50:46 GMT
From:      dpi@world.std.com (Mike Bloom)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip over token ring

I'd appreciate any feedback on porting a tcp/ip stack which runs over ethernet
to also run over token ring.  We have a standalone print server box that
supports several streams-based protocol stacks over ethernet via DLPI.  We're
interested in porting tcp/ip (minimally) to be able to run over token ring.
We already have a token ring driver and associated hardware for our platform,
so all we're really interested in learning here is what "gotchas" we can
expect when tcp and udp are running over token ring instead of ethernet.
For example, are there any new routing issues which need to address, will
arp and rarp still work, how does a diskless workstation learn about its
IP address when running over token ring, ......

Thanks in advance for any help!


Mike Bloom,
Digital Products, Inc.









-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 93 17:26:05 GMT
From:      turletti@jerry.inria.fr (Thierry Turletti)
To:        comp.protocols.tcp-ip
Subject:   Re: audio conferencing software - mbone

In article <rturner.749511410@imagen>, rturner@imagen.com (Randy Turner) writes:
|> 
|> 	I am looking for the software that allows internet-wide
|> 	audio conferencing between <n> numbered audio-capable 
|> 	workstations...Recently I heard that it was on one of
|> 	the machines in the lbl.gov domain but I forgot which one.
|> 
|> 	Also, I believe I will also need the SunOS 4.1 kernel
|> 	patches to support IP Multicast.  Does anyone know where
|> 	these patches are and possibly provide some quick procedure
|> 	for building the kernel with these new changes ?
|> 
|> 	Thanks!
|> 		Randy

Here is the list of the audio/videoconferencing tools available in the 
public domain. Multicast IP extensions are freely available by anonymous 
ftp from gregorio.stanford.edu in the "vmtp-ip" directory.

Regards,

Thierry


*********************************
AUDIO AND VIDEOCONFERENCING TOOLS
*********************************


* CU-SeeMe (0.40v)
------------------
	- From: Cornell University

	- Platform: Apple Macintosh

	- Description: Videoconferencing software for Apple MAC
           over IP. Requires SuperMac VideoSpigot board, Quicktime and
           SpigotVDIG extensions added to the system for video transmission.

	- Ftp-site: gated.cornell.edu:/pub/video

	- Further information: Dick Cogger (R.Cogger@cornell.edu)

	- Sources: not available.


* IVS (3.2v)
------------
	- From: INRIA Sophia Antipolis - RODEO Project.

	- Platforms: Sun Sparc station + VideoPix or Parallax framegrabber.
		     HP station + Raster Rops framegrabber.
		     Silicon Graphics station + Indigo framegrabber.
		     DEC station + VIDEOTX framegrabber
	
	- Description: Audio/video-conferencing tool which supports both
          point-to-point and broadcasting of audio/video using multicast IP.
	  
	- Audio encoding:
		+ PCM 64kb/s 8-bits u-law encoded 8KHz PCM (G.711)
		+ DVI ADPCM 32 kb/s
		+ Variable ADPCM (ADPCM + Huffman encoding) (10-30kb/s)

	- Video encoding: (H.261) variable rate. Three formats available:
		+ SCIF (704x576 pixels)
		+ CIF  (352x288  pixels)
		+ QCIF (176x144 pixels)
		
	
	- Ftp-site: zenon.inria.fr:rodeo/ivs

	- Further information: Thierry Turletti (turletti@sophia.inria.fr)

	- Standards: IP Multicast, G.711, H.261.

	- Sources: available.


* NEVOT (1.4v)
--------------
	- From: AT&T BL

	- Platforms: Sun Sparc Station (SunOS 4.1.x)
                     Silicon Graphics
	
	- Description: Audio-conferencing tool which supports both
          point-to-point and broadcasting of audio using multicast IP.
	  
	- Audio encoding:
		+ PCM 64kb/s 8-bits u-law encoded 8KHz PCM (G.711)
		+ ADPCM 32 kb/s [Sun only] (G.721) 
		+ DVI ADPCM 32 kb/s
		+ ADPCM 24 kb/s [Sun only] (G.723)
		+ CELP 4.8 kb/s
		+ LPC 2.4 kb/s

	- Ftp-site: gaia.cs.umass.edu:pub/nevot

	- Further information: Henning Schulzrinne (hgs@researc.att.com)

	- Standards: IP Multicast, G.711, G.721, G.723, GSM.

	- Sources: available.


* NV (3.2v)
-----------
	- From: XEROX/PARC

	- Platforms: Sun Sparc station + VideoPix framegrabber.
                     SGI Indigo station + Indigo video framegrabber.
                     DEC station + DEC PIP and DEC JVideo framegrabbers.
                     Sony NEWS video capture support.
	
	- Description: Video-conferencing tool which supports both
          point-to-point and broadcasting of video using multicast IP.

	- Video encoding: Variable rate. Video format is
	  320x240 pixels for NTSC sources and 384x288 pixels for PAL sources.
	
	- Ftp-site: parcftp.xerox.com:/pub/net-research

	- Further information: Ron Frederick (frederick@parc.xerox.com)

	- Standards: IP Multicast

	- Sources: available. 


* VAT (2.14v)
-------------
	- From: Lawrence Berkeley Laboratory

	- Platforms: SUN SPARC station
                     SGI station
                     DEC station
	
	- Description: Audio-conferencing tool which supports both
          point-to-point and broadcasting of audio using multicast IP.
	  
	- Audio encoding:
		+ PCM 64kb/s 8-bits u-law encoded 8KHz PCM
		+ IDVI 32 Kb/s Intel DVI ADPCM
		+ GSM 16 Kb/s
		+ LPC1 18kb/s Linear Predictive Coder
		+ LPC2 8Kb/s Linear Predictive Coder

	- Ftp-site: ftp.ee.lbl.gov

	- Further information: Van Jacobson (van@ee.lbl.gov) 

	- Standards: IP Multicast

	- Sources: not available.


**********************
SESSION DIRECTORY TOOL
**********************

* SD (1.14v)
------------
	- From: Lawrence Berkeley Laboratory

	- Platforms: SUN SPARC station
                     SGI station
                     DEC station
	
	- Description: Session director. SD lists all the
	  audio/video conferences available on the Internet. 
	  Information about each conference is presented to the user.

	- Ftp-site: ftp.ee.lbl.gov

	- Standards: IP Multicast

	- Further information: Van Jacobson (van@ee.lbl.gov)

	- Standards: IP Multicast

	- Sources: not available.


-- 
Thierry Turletti  - Project RODEO - INRIA sophia-Antipolis -FRANCE

	e-mail: turletti@sophia.inria.fr
 ivs-talk-site: jerry.inria.fr

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 18:32:43 GMT
From:      dpm@wixer.bga.com (David Maynard)
To:        comp.protocols.tcp-ip
Subject:   Re: Is NIC running out of unique IP addresses?

In article <WYNN.93Oct5111625@haduk.cms-stl.com> wynn@cms-stl.com (Tim Wynn) writes:
>	One of my co-workers is in a UNIX course on TCP/IP right 
>now, and he tells me that his instructor said that NIC is running 
>out of unique IP addresses.  Because of this, he says, NIC is 
>calling people to ask for any unused addresses they might have 
>requested in the past.  Furthermore he said, it's next to impossible 
>to get contiguous blocks of addresses anymore, and getting any 
>addresses takes 6 weeks or more.

The only potential shortage is "Class B" addresses for sites that want
a single network with more that ~254 hosts.  If someone thinks they
need a B network, they might have to spend awhile convincing INTERNIC
that they really need it (as opposed to multiple Class C nets).  As
mentioned in another response, people are working on long-term
solutions.

It sounds like the vast majority of your customers will just need
Class C networks.  There shouldn't be any problem or any delay in
obtaining them.

I got a new C network number a few weeks ago.  I emailed the
request one evening and had a network number before noon the next day.
I was impressed!

-David

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

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 19:30:19 GMT
From:      Boris Yanovsky <boris@netmanage.com>
To:        comp.sys.apollo,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: HELP: RJ45 to BNC conversion, how do I do it?


In article <284tnh$dk0@quad.wfunet.wfu.edu>, <ahn@wfu.edu> writes:

> What we have is an RJ45 cable that runs between the two machines, but 
 there
> is no way to connect the RJ45 cable to the Apollo w/ the BNC connector.
Even if you get the converter just runing an RJ45 cable between 2 machines 
will not work.  You need a 10Base-T concentrator. 

*****************************************************
Boris Yanovsky                    Phone: (408) 973-7171
NetManage Inc.                    Fax:   (408) 257-6405
20823 Stevens Creek Blvd.         Internet: boris@netmanage.com
Cupertino, California, U.S.A.
*****************************************************


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1993 19:46:08 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP entry timeouts

In article <2958995396.4.p00872@psilink.com> "Kenneth Chin"
<p00872@psilink.com> writes: 
    I'm just curious about what the standard ARP cache entry timeout
    may be for routers when they're performing proxy-arp'ing?  In
    most cases, I believe that this is configurable, but what do people
    usually set it at?
    
For a cisco router, the timeout is 4 hrs.  The vast majority of people
(>>99%) don't configure the timeout any lower.

Tony

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 19:50:55 GMT
From:      jybarnes@cs.umr.edu (Jym Barnes)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc
Subject:   Configuration for SLIP on terminal server

Hi,

Does anyone have the port configuration for a DECServer 300 offering a SLIP
service.  Are you using any flow control?  If you could send me the
sho port output you would make my day.  If you could also send the 
modems setup.  I will probably being using this port in DYNAMIC mode.
This way I could utilize present outgoing modems.  Does anyone know if
the DECServer 300 supports compressed headers?  Please reply to
jybarnes@cs.umr.edu.

Thanks,

-Jym-

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Oct 1993 23:08:36 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time

In article <AMOSS.93Oct4094156@serenade.cs.huji.ac.il> amoss@serenade.cs.huji.ac.il (Amos Shapira) writes:
% Does anyone have experience in running xntp3 in a "broadcast-client" mode?
% It doesn't work for me.

In article <RENS.93Oct6160647@stimpys.imsi.com> rens@imsi.com (Rens Troost) writes:
>What breaks? We're running it in that mode here, and it works fine. I
>must ssay it makes life a whole lot easier in a dynamic environment.

Older versions of the xntp3 software didn't work quite right in broadcast
mode on some systems.  Newer versions of the xntp3 work fine.  Perhaps
Amos Shapira doesn't have the latest and greatest version of xntp3 ?

Followups are directed to comp.protocols.time.ntp since this is really
an NTP discussion.



-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Oct 1993 13:02:20 -0800
From:      bcoughlin@pbs.org (Brian Coughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over VSAT

In article <1993Oct1.035547.9723@cabell.vcu.edu>, csc3bem@cabell.vcu.edu
(Bryan E. Miller) wrote:

> 
> Has anyone out there successfully (or unsuccessfully) attempted
> running IP-based applications over VSAT technology?  If so,
> could you briefly describe your setup and application.
> 
> Thanks,
> 
> Bryan

We've done it here at PBS.  We've used/tested 2 VSAT vendors'
products, AT&T Tridom and Hughes.  

The are 2 main issues with VSAT and TCP/IP:

1) propagation delay and it's effect on performance

2) IP traffic gatewaying/filtering, to minimize extraneous IP traffic
over the VSAT spacelink

For #2, AT&T built an IP router into their VSAT equipment, whereas
Hughes uses packet-type and MAC address filtering.

For #1, you have to make sure that TCP window size is set large enough
to reduce idle time of a sender waiting for an ACK to get back
from the receiver before they can resume transmitting packets.  This
is due to the large propogation delay of the connection having to
"hop" 23000 miles up and back to bounce off of the satellite.  Furthermore,
all point-to-point traffic must go through what's called the VSAT hub
site.  So, if neither of the hosts talking to each other are on the hub, 
the delay doubles becuase the connection requires 4 "hops" instead
of 2.

As for running real applications, avoid ones like telnet in which
each character may need to be echoed back from host to remote.

PBS plans to run mainly batched oriented traffic over VSAT to make
for more optimal usage of a VSAT's bandwidth.

Our setup is in flux right now, so I'll have to get back to you
on that if you want more details ....

Brian

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 00:22:43 GMT
From:      heberlei@cs.ucdavis.edu  (Louis Todd Heberlein)
To:        comp.protocols.tcp-ip
Subject:   ICMP dropping options for IP

Hi,

I have been trying to develop an alternate traceroute
program, but I am having trouble with the design.

The design goes as follows:
    Like traceroute, I send a packet to an unknown port on the
	destination host.
    Unlike traceroute, I have turned on the record route option in
	the IP header.

    What I think SHOULD happen is the remote machine returns an ICMP
	error message which should include the IP header of my
	probe packet and therefore, the recorded route.  Thus, I
	would have a single probe version of traceroute.


Unfortunately, the IP header returned inside the ICMP message is marked
with a header length of only 20 bytes; the minumum for the IP header.
All my IP options and recorded route are missing.

Does anyone know why ICMP does not include options in the IP header
that is returned?

Thanks,

Todd				heberlei@cs.ucdavis.edu

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 1993 00:49:19 GMT
From:      Henry_Choy@engr.usask.ca (Henry Choy)
To:        comp.protocols.tcp-ip,sci.research
Subject:   Info is so scattered!

I was trying to interpret my IP header, which was transmitted on
ethernet. How can I ever find information that talks about both
subjects? One of my resources is the rfc's. The IP protocol standard
is discussed in rfc x. I manually searched for occurrences of
"ethernet" and "header" in x, which leads me to a set of rfcs.
Finally I find an rfc that tells me what is happening.


--

Henry Choy
choy@cs.usask.ca

Anything worth doing is worth overdoing.  - R. Heinlein
          is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 01:42:31 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.protocols.tcp-ip
Subject:   Broadcast RPC


Hello,

While developing an RPC/UDP application, I thought it would be more efficient
to contact rpc daemons on my local network with broadcast RPC, rather than
calling each host in turn. It would seem that if the number of hosts is n,
then calling each host would result in 2n udp packets for every call (barring
complications), while a broadcast scheme would involve n+1 packets - one for
the broadcast, and n replies.

However, I see that every host is responding to a clnt_broadcast() call four
times, so I see 4n+1 packets. I have verified that the RPC libraries in SunOS
4.1.3 and DG/UX 5.4.1 both do this. The source to clnt_broadcast() looked
opaque to me, so I used etherfind to sniff rpc/udp on my network. When I
make a clnt_broadcast() call, the rpc client sends out four, rather than
one broadcast packet.

Is this a bug?

--
ben@piglet.cr.usgs.gov

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 02:08:00 GMT
From:      vanessa@twg.com (Vanessa Gibb x7289)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Wollongong and SCO ODT 2.0

In article <1993Oct6.023624.17293@huey.csun.edu> secssxn@mx.secs.csun.edu (Scott Neugroschl) writes:
>Hi.  I'm running SCO ODT 2.0 as an LPD server.  On another 486 PC,
>I'm running Wollongong Pathway Access and Pathway Client NFS.  The Network
>Driver for Windows installed.  We have an HP LJ4 hooked up to the ODT system.
>
>When we print from Windows to the LJ4 over the net, we get garbage on the
>printout.  I believe it is because there is no way to pass the -oraw option
>to the SCO spooler.
>
>I would like to know if anyone else is using this sort of configuration,
>and if so, if they have gotten this to work.
>
>Thanks
>
>-- 
>Scott "The Pseudo-Hacker" Neugroschl
>-- Beat me, Whip me, make me code in Ada

Scott,

There are a couple of things that you should check:

Firstly, assuming that you are using LPRINT to print, make sure that you
are using the -Os option (with LPRQ).  When this option is used, the file
to be printed will be sent as postscript.

Secondly, (a long shot :-)), ensure that the printer supports postscript -
if it does not, the file would print as garbage.

If neither of these suggestions help, please contact Wollongong Product
Support on 415-962-7140.  We will be happy to run through your setup and
debug your printing problems.

Thanks,

Vanessa G. Gibb
The Wollongong Group, Inc.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 02:09:15 GMT
From:      tschach@math.fu-berlin.de (Carsten Tschach)
To:        comp.protocols.tcp-ip
Subject:   Using PC as Terminal/Printer-Server ?

Hi,

I'm looking vor a software that let a PC act like a terminal-server. The PC
hast no other function, therefor I don't need any slow TSR's.

First of all I want to use the two parallel ports to connect to the printers 
and than maybe connect modems to the serial port.

It would also be great if you can log into the 'PC-Terminal-Server' and 
do the administative things or use the modem for dialouts.

The PC I currently use is a 286-16 with a wd8003 ethernet-card and a boopd-
bootprom.



Please send any responses to:   tschach@math.fu-berlin.de



Bye, Carsten
-- 
/ Carsten Tschach         tschach@cs.tu-berlin.de  tschach@math.fu-berlin.de  \
|                                                                             |
|   Du sollst Dir den Kopf nicht nach Frauen verdrehen, die zu alt UND zu     |
\   huebsch fuer Dich sind.                                      (Boris Kemp) /

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 1993 03:58:07 GMT
From:      samson@cssun2 (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   yyparse()???

Hello everybody,
	I'd like to thank all the guys who answered my question here. Now I
know how to use select() to do I/O multiplexing. I should study harder. It
is detail on Steven's book.
	I have another little problem. When I read the source of FTPD
(wu-ftpd, Washington University), I found there is an infinite loop
yyparse() at the last statement of main(). But I cannot find its real
source. I can neither find it on system call. Just now, I saw yyparse()
again on the source of Berkeley BIND. I will be very appreciate if someone
can tell me where to find the real body of yyparse(). Thanks to all.

Samson Chen
samson@chpi.edu.tw
Chung-Hua Polytechnic Institute, Hsin-Chu, Taiwan
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 05:22:51 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   timed vs. NTP (was: Specifying IP)

> >Even with timed, you have to set -M on at least one of the systems....

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

> NO!  NO!  NO!  EACH AND EVERY TIMED SHOULD BE RUNNING WITH -M EVERYWHERE!
> Sorry, but I've heard and fought that nonsense so many times that
> it is very painful.

We're going to disagree violently on this one, then.  I want -M on one,
maybe two systems so that I can synch those systems and push the fixed date
out with rdate.  Before we got Internet access, we (like lots of sites) did
this by having the timed master dialup to the NIST.  Even better, now I
have systems here running both NTP and F.F. Jacot Guillarmod's timed+ntp
which broadcasts timed updates from a server which is set via NTP - this
lets me mix NTP and timed on a single net, in synch.  But, one specific
system must be the timed master.

I suspect that many people agree with me - SCO ODT 1.0 was shipped with -M
as the default, and I think SCO got so much grief for this that they
changed the default to non-M and have left it there in all later versions.
Many admins, including me, wasted hours going around to hundreds of systems
stomping out the -Ms.

And in this case, I don't think it's relevant that the vast majority of
non-Internet-connected users don't care if their clocks are off by a few
minutes.  Defaulting to -M optimizes for people who don't care if their
clocks are wrong, with a heavy penalty for those of us who want to get it
right.

Actually.... did you change timed so that "date <new-time> ; rdate" works
on systems other than the master?  That's only a partial fix, but it's far
better than not having it at all.

> About only the reason to turn off -M is 
> to mess up time in a network, although the perpetrators usually do not
> realize or acknowledge as much.

The reason is to set timed's idea of the time to something better than just
the average of a bunch of unreliable sysems.

> I have heard claims that NTP uses far more CPU cycles than a point-to-point
> hack named "timeslave", which uses ICMP timestamps, the UDP time port,
> and lots of naive filtering to ride even intermittently asymmetrically
> loaded low speed links.

It might be more expensive than a simpler scheme, but at less than 4 CPU
seconds/day, I consider NTP a bargain.  I do regret the 100 KB of resident
memory, tho.

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


-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 12:50:58
From:      billingt@ccmail.dell.com (Tom Billingsley)
To:        comp.protocols.tcp-ip
Subject:   CNE Study Group

I am looking for a newsgroup that has some focus on people who are working on 
the CNE tests. Is there such a group or possibly a related group.
Thx in advance
TDB 

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 08:30:21 GMT
From:      tschach@math.fu-berlin.de (Carsten Tschach)
To:        comp.protocols.tcp-ip
Subject:   Using PC as Terminal/Printer-Server ?


Hi,

I'm looking vor a software that let a PC act like a terminal-server. The PC
hast no other function, therefor I don't need any slow TSR's.

First of all I want to use the two parallel ports to connect to the printers 
and than maybe connect modems to the serial port.

It would also be great if you can log into the 'PC-Terminal-Server' and 
do the administative things or use the modem for dialouts.

The PC I currently use is a 286-16 with a wd8003 ethernet-card and a boopd-
bootprom.



Please send any responses to:   tschach@math.fu-berlin.de



Bye, Carsten
-- 
/ Carsten Tschach         tschach@cs.tu-berlin.de  tschach@math.fu-berlin.de  \
|                                                                             |
|   Du sollst Dir den Kopf nicht nach Frauen verdrehen, die zu alt UND zu     |
\   huebsch fuer Dich sind.                                      (Boris Kemp) /

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 09:35:48 GMT
From:      RINDFUSS-S@medea.wz-berlin.de (Peter Rindfuss)
To:        comp.protocols.tcp-ip
Subject:   How to SLIP away?

I successfully set up cslip-2.6 on our Sun and can connect to it from my
home MSDOS PC. Now I wonder whether and how I can use this interface to 
attach to other computers than the Sun (which has the modem).
I assume that I have to define some routing information, but I don't have
enough Unix experience to figure it out myself.

Peter Rindfuss (Wissenschaftszentrum Berlin)

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 11:30:41 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.sys.apollo,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: HELP: RJ45 to BNC conversion, how do I do it?

In article <1993Oct6.192959.14005@netman-gate.netmanage.com> Boris Yanovsky <boris@netmanage.com> writes:
>
>In article <284tnh$dk0@quad.wfunet.wfu.edu>, <ahn@wfu.edu> writes:
>
>> What we have is an RJ45 cable that runs between the two machines, but 
 there
>> is no way to connect the RJ45 cable to the Apollo w/ the BNC connector.
>Even if you get the converter just runing an RJ45 cable between 2 machines 
>will not work.  You need a 10Base-T concentrator. 
>
You can buy a thin-to-10baseT transciever: These are around 200 UK pounds
here - my guess is $200 us.
Leo


-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 1993 12:14:14 GMT
From:      Paul.Terray,,,5-2@aedi.insa-lyon.fr (Paul Terray)
To:        comp.protocols.tcp-ip
Subject:   Re: yyparse()???


Hi,

yyparse is, like any function starting with yy, either a lex or a yacc
function. Lex and Yacc are two parser generator stantdard in C. You
could probably find the description of your parser in a file ending in
.y (If I remember well, yyparse is  generated by yacc). For any
other information, read the manual pages for lex and yacc.

Paul

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 12:49:51 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: yyparse()???

samson@chpi.edu.tw writes:
}	I have another little problem. When I read the source of FTPD
}(wu-ftpd, Washington University), I found there is an infinite loop
}yyparse() at the last statement of main(). But I cannot find its real
}source. I can neither find it on system call. Just now, I saw yyparse()
}again on the source of Berkeley BIND. I will be very appreciate if someone
}can tell me where to find the real body of yyparse(). Thanks to all.

   If it is like other ftp daemons I have seen there is a file
   called ftpcmd.y which is run through a program called yacc
   to generate C code.

   If you look through all the code, you will no doubt find a
   call to exit().

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

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 12:53:30 GMT
From:      kenter@cs.utwente.nl (Arjan Kenter)
To:        comp.protocols.tcp-ip
Subject:   Re: yyparse()???

In article <29044f$5bh@news.csie.nctu.edu.tw>, samson@cssun2 (Samson Chen)
writes:

> Hello everybody,
> 	I'd like to thank all the guys who answered my question here. Now I
> know how to use select() to do I/O multiplexing. I should study harder. It
> is detail on Steven's book.
> 	I have another little problem. When I read the source of FTPD
> (wu-ftpd, Washington University), I found there is an infinite loop
> yyparse() at the last statement of main(). But I cannot find its real
> source. I can neither find it on system call. Just now, I saw yyparse()
> again on the source of Berkeley BIND. I will be very appreciate if someone
> can tell me where to find the real body of yyparse(). Thanks to all.
>
> Samson Chen
> samson@chpi.edu.tw
> Chung-Hua Polytechnic Institute, Hsin-Chu, Taiwan
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

yyparse() is never the same thing... It's the parser function that yacc
(Yet Another Compiler Compiler) produces from an LR(1) grammar. On Unix
systems yacc (or its Gnu counterpart) is very often used to implement
computer (programming/specification) languages. In fact, the function yyparse()
_is_ always the same, the difference is in the parsing tables. If you want
the code, it is usually in /usr/lib/yaccpar (on my Sun: /usr/ccs/bin/yaccpar).
Otherwise, the man page on yacc may tell you where to find it.

I think it is enough for you to know that yyparse() implements a parser, but
if you are interested, browse through some books on compiler writing.

Regards,

Arjan Kenter

---

    ___
 __/   \__________
|  \___/          | ir. H.J.H.N. Kenter                 kenter@cs.utwente.nl
|___ _   __   ___ | University of Twente                tel. +31 53 893747
| |  |  /  \ (__  | Tele-Informatics & Open Systems     tfx. +31 53 333815
| |  |  \__/ ___) | P.O. Box 217   7500 AE Enschede
|_________________| The Netherlands

 I can make it all worthwhile... as a Rock 'n Roll star --- David Bowie



-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 15:14:49 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: timed vs. NTP (was: Specifying IP)

In article <CEIHM4.7EI@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>> >Even with timed, you have to set -M on at least one of the systems....
>
>vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>
>> NO!  NO!  NO!  EACH AND EVERY TIMED SHOULD BE RUNNING WITH -M EVERYWHERE!
>> Sorry, but I've heard and fought that nonsense so many times that
>> it is very painful.
>
>We're going to disagree violently on this one, then.  I want -M on one,
>maybe two systems so that I can synch those systems and push the fixed date
>out with rdate.  Before we got Internet access, we (like lots of sites) did
>this by having the timed master dialup to the NIST.  Even better, now I
>have systems here running both NTP and F.F. Jacot Guillarmod's timed+ntp
>which broadcasts timed updates from a server which is set via NTP - this
>lets me mix NTP and timed on a single net, in synch.  But, one specific
>system must be the timed master.

You are simply wrong, in the company of many other people.  -M does not
mean "master" to the 4.*BSD timed.  Turning off -M on machines that have
bad clocks or open root accounts does not improve time in your system.
With the 4.3BSD timed as well as its descendents, the `date` command on
any system sends the desired change to the current "moderator" (miss-named
"master"), which blithely changes its clock and sends corrections to all
other participating systems.  This part of the protocol lacks any
consideration for authentication, although it is possible to hack in some
simple authorization checks into the code as I did for 4.4BSD.  The so
called master averages the clocks of all participating systems, including
those without -M, no matter how bad their crystals.  Read the code.

Specifically, notice that -M only affects the Mflag variable, and then
look at the 13 places where Mflag is used.  Notice in master.c that
measure() is called for all systems, and that later in networkdelta() is
called to average all of the ticks, no matter how bad.  (The 4.3BSD code
simply computed the arithmetic average after excluding obvious bogons.
I changed it to compute the median, and made it a much faster besides.)

Timed was a master's degree project by some Berkeley students.  It was
clearly intended for a very few commonly administrated VAX's on a single
ethernet.  As such, they did not really think through nor implement the
implications of real "non-master" machines.  Their hooks for gateways in
the code and the protocol were wrong.  My -F and -G additions fix the
trustworthy systems problem, and fix gateway problems at the cost of
administrative hassles.  Of course, there are other glaring errors in the
protocol, but with -F/-G it works well enough.

>I suspect that many people agree with me - SCO ODT 1.0 was shipped with -M
>as the default, and I think SCO got so much grief for this that they
>changed the default to non-M and have left it there in all later versions.
>Many admins, including me, wasted hours going around to hundreds of systems
>stomping out the -Ms.

I wouldn't be surprised if SCO changed their minds, but it would be due to
uninformed complaints and misunderstandings.

You and others indeed waste hours going to hundreds of systems stomping
out -Ms, because you did yourself only harm.  You did not exclude the bad
ticks or untrusted `date` commands of those systems.  You exclude those
systems from being elected as moderators should your trusted systems die.

-M does not really mean "master" to timed, despite the fact that the code
and documentation uses the word "master".

>And in this case, I don't think it's relevant that the vast majority of
>non-Internet-connected users don't care if their clocks are off by a few
>minutes.  Defaulting to -M optimizes for people who don't care if their
>clocks are wrong, with a heavy penalty for those of us who want to get it
>right.

Wrong.  -M does not functionally mean "master".  Turning off -M only
reduces the stability of time in your network.

>Actually.... did you change timed so that "date <new-time> ; rdate" works
>on systems other than the master?  That's only a partial fix, but it's far
>better than not having it at all.

Which `rdate` did you use?  What did it do?

`date newtime` should have always worked.  In the system we've mentioned
with the heavily changed timed, I introduced a bug in one release that
hung on for a long time because of operating system release schedules.
It has long since been fixed.

The original 4.3BSD `date` command was changed to send a TSP message to
the local timed daemon, which if it was not the current "master" (really
moderator) would send the new time to the current "master" (really
moderator) which would adjust its clock and forward the result to all machines
including the originator where the `date` command ran.  This mechanism is
not and was not affected by -M on the local system, except that without
-M you could be sure the current "master" (really moderator) is not the
local system.  Systems without -M are still able to change time in the
entire system (unless you use -F or -G in the 4.4BSD version or unless
your `timed` is otherwise changed).

>> About only the reason to turn off -M is 
>> to mess up time in a network, although the perpetrators usually do not
>> realize or acknowledge as much.
>
>The reason is to set timed's idea of the time to something better than just
>the average of a bunch of unreliable sysems.

Wrong.  The unreliable time of all system, unreliable or not, is collected
and averaged into the time redistributed by the so called master.


Vernon Schryver    vjs@rhyolite.com

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 1993 15:50:36 GMT
From:      stephen@orchid.UCSC.EDU ()
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   FTP PC/TCP 2.2, Windows 3.1 and remote printing

I have just recently installed the PC/TCP 2.2 software for DOS and
Windows on a 486 machine.  Everything seems to work fine except
for remote printing.

For several days I have been working on the problem, and have been
trying to get through to someone at FTP without much luck.

Remote printing under DOS seems to work fine using 'lpr' command.

But when trying to access remote printers via windows apps, it just
doesn't behave itself.  

I have gone through the setup procedure several times-  under FTp Network
Icon, then to printers, I setup a host:printer, username=nobody, type=pcnfs
port=lpt2, then I connect, and everything seems to be OK.

When I print I get several different results- the main one being that I
get nothing, but I have another strange effect, The PC (Windows) will hang
for about 30 seconds, and the speaker emits a click noise about every 
5 seconds.

I know this is sketchy but maybe there are some known problems.


Thanks alot

Stephen Hauskins
UCSC


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 93 20:02:29 GMT
From:      ereynold@tad.eds.com (Edward S. Reynolds)
To:        comp.protocols.tcp-ip
Subject:   BGP and Policy Routing

Perhaps someone in this group could answer some questions I have regarding policy-based 
routing and more specifically BGP.

Can I use BGP to allow 2 organizations to share a common IP backbone with access to common 
resources yet prevent them from accessing each other.  The configuration might be something like this.

Networks A and B share a common backbone network C and have common access to resources 
in network D.  Network C is a transit network and networks A, B and D are stub networks.

Can BGP prevent A and B from accessing each other by limiting route advertisements in network C ?  
Is this secure or merely an inconvenience for a network hack ?  That is, could someone in network B 
access network A via source-routing or some other scheme ?  Can the border routers prevent this 
since they have no knowledge of each other ? 

I realize true and trusted security will require the use of Kerberos, RSA or other authentification and 
encryption methods.  The intent here is to control the use of private network resources while providing 
a common transport backbone.

Can BGP-3 handle this ??  BGP-4 ??


Thanks,

Ed Reynolds                     (ereynold@tad.eds.com)
EDS Technology Architecture

+-------------------------------------------------------------------------+
| DISCLAIMER:  My comments are just that... Mine !!!                      |
|              And do not represent those of my employer or anyone else.  | 
+-------------------------------------------------------------------------+ 

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 21:16:56 GMT
From:      svanarts@lmsc.lockheed.com (Scott VanArtsdalen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet Addressing Summary

dcc@scitor.com (Dennis Coyle) writes:

( Text Deleted )

>RFC References: RFC1219, RFC1009, RFC950, RFC1122, RFC942
 
>Thanks to all that applied, I hope this helps out some other newbe :) !


Not really, I didn't catch the first part of this thread. |:^[

Can anyone tell me where I can get hold of these RFCs and some info
on subnetting in general?  Sorry for the newbie-ish question but that's
what I am...   ?:^]
--------------------------------------------------------------------------    
    \    /\                                           Aeronca 7AC Champ
     \  /__\                                          =(*)= N3115E =(*)=
Scott \/an  \rtsdalen                                "The Boonie Bouncer"
--------------------------------------------------------------------------
        Opinions expressed here do not necessarily reflect those of
           Lockheed Missiles & Space Co., Inc. or its management.   =*
--------------------------------------------------------------------------

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Oct 1993 21:47:59 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: IP over VSAT network

In article <28v5cg$1c4@servo.ac.com>, cassasd@servo.ac.com (Devin Cassas) writes:
|> 
|> I have RS/6000s communicating over a Hughes VSAT network.  The RS/6000s are
|> running TCP/IP and the application is having problems with timeouts.  Packets
|> are always delivered reliably, but I'm not sure about the round trip time.
|> PING gives me consistantly round trip times in the 3-7 second (yes thats
|> SECONDS) range.
|> 
|> My question is: does anybody have any experience or knowledge of tuning the
|> TCP/IP protocol stack to make it work better over satellite network?
|> 
|> If it helps, the IP is encapsulated in SNA at the earth station before it is
|> beamed into space.
|> 
|> Thank you for your help.
|> 
|> Devin Cassas
|> devin.cassas@ac.com

I am a lead engineer on a competitive product, the AT&T Tridom Clearlink
VSAT.  There are differences between their product and ours (theirs is
a bridge and ours is a Router).  These differences may come into play but
I can tell you about ours and you can apply that to your knowledge of
your network and see if it makes sense.

The RS/6000 at one of our customer sites is running FTP (TCP/IP based)
and the ping times are in the 1 to 2 second range.  That is from a 
VSAT to the Customers data center (one satellite hop).  If your destination
is on another VSAT then the double hop and switch decision would probably
double that.  So, the low end of your range seems reasonable and the high
could be caused by congestion and queueing.  

The RS/6000 measures the round trip and computes a running average.  Most
use the formula srtt = (meas. rtt +  (7 * srtt))/8.  Twice this value is
usually the time our value.  In /usr/include/netinet there are header files
that set the initial values and then the time out adjusts to the delay.

As long as the delay doesn't double, no time out will occur.  If it does,
a retransmission will occur.  My experience is that the RS/6000 worked
well in our environment.  

Hope this helps (and that people at Hughes can help with any differences).

-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1993 07:08:44 -0400
From:      erik@rat.SE (Erik Heimdahl)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Dos and Windows


Does anybody know if there are any _CHEAP_ TCP/IP implementations for  
Dos and Windows (PD or SW also welcome). I have to interface between  
both Dos- and Windows-applications and a UNIX application using  
Sockets.

	/erik

PS.

	_Please_ awnser by _mail_, I don't get this newsgroup to my 	  

	site.

DS.



-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 08:48:25
From:      dwbrown@wco.ftp.com (Derek Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC



>I think you loose here because the RPC servers are not all on the same
>port.  The scenario you have (if I get RPC right) is as follows:
 
>1. The client broadcasts on the net to the portmappers (UDP port 111) asking
>   on which port and which version is supported on the various hosts. (1
>   packet).
 
>2. The client receieves replies from all the portmappers telling it what port
>   to use in order to talk to your UDP server (n packets).
 
>3. The client starts talking to each server individually, because almost all
>   of them sit on a different port broadcast isn't used here (another n
>   packets sent and another n packets recived).
 
>That gives 3n+1 if I count it right, dunno where the other n packets came
>from,  maybe the client asks the portmappers twice in case it lost some
>replys (that's what rup does, for instance).
 
>Maybe tcpview can give you more details about the packets.
 
>Hope this helps,
 
>--Amos


This isn't quite right... The way rpc broadcasts work is this:
1) The client broadcasts to port 111, so that the portmapper can hear it, 
    the portmapper is the only thing that a) the client knows about and b)
    knows what port the servers are on.

2) When the portmapper receives the broadcast, it behaves as a proxy agent, 
    and makes the call to the intended server.  The server replies to the 
    portmapper, and the portmapper sends the reply to the server.

This leaves you with 2n + 1 packets.

The reason you are seeing more is that the RPC code has a loop, in which
(at least in the original Sun RPC 4.0 code) would broadcast a total of 6 times,
increasing the timeout for the response each time.  Also, each time a response
is received, the clnt_broadcast() calls a callback. This loop can be broken if 
the callback returns false.  There are two ways, then, of getting 2 responses 
from the servers, or 4n+1 packets

1)  Your library has been modified to only send out two broadcasts (rather 
than six) to shorten the broadcast timeout.  

2)  Your callback is maintaining a list of addresses who have replied, and is 
stopping when it receives a duplicate list.

Hope this helps,
dB
----------------------------------------------------
F                                       Derek Brown
  T                                     db@wco.ftp.com
    P                                   (415) 543-9001
Software                                (fax) 543-9002

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1993 16:24:45 -0600
From:      hleal
To:        comp.protocols.tcp-ip
Subject:   Diferences using RPC with UDP and TCP?

Does anybody has some information about wich the diferences between UDP and TCP when using RPC protocol?

Any information will be apreciatted.

please send e-mail to:
hleal@mtecv2.mty.itesm.mx

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 93 12:48:00
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC

ben@piglet.cr.usgs.gov (Ben A. Mesander) writes:

|While developing an RPC/UDP application, I thought it would be more efficient
|to contact rpc daemons on my local network with broadcast RPC, rather than
|calling each host in turn. It would seem that if the number of hosts is n,
|then calling each host would result in 2n udp packets for every call (barring
|complications), while a broadcast scheme would involve n+1 packets - one for
|the broadcast, and n replies.
 
|However, I see that every host is responding to a clnt_broadcast() call four
|times, so I see 4n+1 packets. I have verified that the RPC libraries in SunOS
|4.1.3 and DG/UX 5.4.1 both do this. The source to clnt_broadcast() looked
|opaque to me, so I used etherfind to sniff rpc/udp on my network. When I
|make a clnt_broadcast() call, the rpc client sends out four, rather than
|one broadcast packet.
 
|Is this a bug?

I think you loose here because the RPC servers are not all on the same
port.  The scenario you have (if I get RPC right) is as follows:

1. The client broadcasts on the net to the portmappers (UDP port 111) asking
   on which port and which version is supported on the various hosts. (1
   packet).

2. The client receieves replies from all the portmappers telling it what port
   to use in order to talk to your UDP server (n packets).

3. The client starts talking to each server individually, because almost all
   of them sit on a different port broadcast isn't used here (another n
   packets sent and another n packets recived).

That gives 3n+1 if I count it right, dunno where the other n packets came
from,  maybe the client asks the portmappers twice in case it lost some
replys (that's what rup does, for instance).

Maybe tcpview can give you more details about the packets.

Hope this helps,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right,
C.S. System Group, Hebrew University,  |  but who is left"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |                 -- Anonymous?

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1993 08:36:51 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: BGP and Policy Routing

In article <1993Oct7.200229.6778@tad.eds.com> ereynold@tad.eds.com (Edward
S. Reynolds) writes: 
    
    Can I use BGP to allow 2 organizations to share a common IP backbone
    with access to common resources yet prevent them from accessing each
    other.  The configuration might be something like this.
    
    Networks A and B share a common backbone network C and have common
    access to resources in network D.  Network C is a transit network and
    networks A, B and D are stub networks.
    
    Can BGP prevent A and B from accessing each other by limiting route
    advertisements in network C ?  

BGP can prevent some route redistribution.  A can reject routes leading
into B.  C can also not advertise B's routes to A.  And vice versa for
both.

    Is this secure or merely an inconvenience for a network hack ?
    That is, could someone in network B access network A via source-routing
    or some other scheme ?   

A _minor_ inconvenience.  Any undergraduate worth their salt will, as you
note, source route around this, or tunnel through it.  This is not a
security mechanism.  You've just asked for an unlisted phone number.  The
telemarketeers will still find you.  ;-(

    Can the
    border routers prevent this since they have no knowledge of each other?

Given that the border routers are probably also packet filters, yes, the
border routers could probably implement most of what you want.  However,
this is completely orthogonal to BGP.
    
    I realize true and trusted security will require the use of Kerberos,
    RSA or other authentification and encryption methods.  The intent here
    is to control the use of private network resources while providing a
    common transport backbone.
    
    Can BGP-3 handle this ??  BGP-4 ??
    
Yes, BGP-3 can handle the routing portion of this problem as long as each
site is one or more IP networks.

I suggest you contact your router vendor directly for more assistance.  ;-)

Tony

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 09:43:59 GMT
From:      svaidya@shakti.ncst.ernet.in (Prashant N.Vaidya)
To:        comp.protocols.tcp-ip
Subject:   network mgmt s/w - tcpip & ipx - help !!!


Hi,

We have a problem implementing a metwork management software on a
company wide network.

The background is this. We have a number of LANs at various locations 
in the country. The LANs are connected to each other over leased lines
and using X.25 links. The LANs itself are very heterogenous. There are 
UNIX machines using TCPIP to communicate to each other. Then there are
PCs connected by Novell's netware and using ipx/spx to communicate to
each other. On such a network we want to develop a n/w mgmt s/w that 
recides on a dedicated unix machine. Among other functions it has also 
to sample data and carry out analysis of the network traffic. That's where
the problem comes. 

Analysing captured packets is  quite simple. It is merely having a 
series of filters. We haven't yet found a way to capture all the 
packets. From what we know about socket programming, we can only capture TCPIP packets from a socket. I don't have much experience with raw sockets. 
Knowledgeable netters can throw more light. Besides even with sockets, we can 
only capture TCPIP packets. And after that we have to bind a particular port.
So we are actually listening only onto TCPIP packets at a particular port and 
not onto all the traffic on the ethernet. Thus, theoretically, while it i
possible that we can "just turn on our machine and listen onto all the traffic 
on the network", practically we cannot achieve it. Additionally, there
is the problem that we cannot capture ipx/spx packets at all. 

Does anybody know a solution? Thanks.

This is for a friend og mine. You can post your answers to the net.

svaidya.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 12:02:20 GMT
From:      mollett@lexmark.com (Vic Mollett)
To:        comp.protocols.tcp-ip
Subject:   SYN in Time-wait state

I have recently noticed that one of my UN*X machines will sometimes do the
following (where XXXX is some constant):

	  SYN handshake with remote host from port XXXX
	  send data from port XXXX
	  FIN handshake with remote host from port XXXX
	  (note, we are in time-wait state here)
	  attempt SYN handshake with remote host from port XXXX with a sequence
	     number that is significantly greater than the one from the FIN

My question is, is this legal??  RFC 793 on page 69 seems to suggest that the
remote host should retransmit its last ack (from the FIN handshaking) and
toss the incoming packet.  However, it seems intuitive that the host is wanting
to establish a new connection and is setting up a new sequence number (which is
what a SYN is supposed to do).  Any ideas??

BTW, the two hosts do get synchronized (after a RST), but this little side-step
has me wondering.

-- 
                                             /\    Vic Mollett
 These opinions are my own and do not       /  \   Lexmark International, Inc.
 necessarily reflect those of my employer.  \  /   mollett@lexmark.com
                                             \/  

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 13:21:16 GMT
From:      courtney@bml4380.cpg.cdc.com (Joseph D. Courtney)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: FTP PC/TCP 2.2, Windows 3.1 and remote printing

 (stephen@orchid.UCSC.EDU) wrote:
: I have just recently installed the PC/TCP 2.2 software for DOS and
: Windows on a 486 machine.  Everything seems to work fine except
: for remote printing.
: 
: For several days I have been working on the problem, and have been
: trying to get through to someone at FTP without much luck.
: 
: Remote printing under DOS seems to work fine using 'lpr' command.
: 
: But when trying to access remote printers via windows apps, it just
: doesn't behave itself.  
: 
: I have gone through the setup procedure several times-  under FTp Network
: Icon, then to printers, I setup a host:printer, username=nobody, type=pcnfs
: port=lpt2, then I connect, and everything seems to be OK.
: 

  I also cannot get printing to work using type=pcnfs, but it works fine
  when I use the LPR protocol.  You must first setup the printer in Control
  panel.  I assigned my printer to LPT2 and made the connection to
  \\host-name\printer-name.  Then I used the FTP Network Icon to complete
  the setup.

: When I print I get several different results- the main one being that I
: get nothing, but I have another strange effect, The PC (Windows) will hang
: for about 30 seconds, and the speaker emits a click noise about every 
: 5 seconds.
: 
  I have also noticed this clicking noise.  It seems to happen when the
  network is not responding.

--------------------------------------------------------------------------------
Joe Courtney                        | "Remember that no matter where you go...
Control Data Systems, Inc.          |  there you are!"
Email: jdc1@cdsmail.cdc.com         |                  Buckaroo Bonzai
Compuserve: 71644,500               |

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Oct 93 13:49:55 GMT
From:      mcgrath@quantum.qnx.com (Tom McGrath)
To:        comp.protocols.tcp-ip
Subject:   statd and lockd

I am looking for a public domain version of
statd and lockd. Does anybody know of one and
if so where is it?


-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Oct 93 13:53:17 GMT
From:      mcgrath@quantum.qnx.com (Tom McGrath)
To:        comp.protocols.tcp-ip
Subject:   statd and lockd

Is there a public domain version of
lockd and statd? If so how can I get
it?


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1993 22:15:26 -0400
From:      jordan@imsi.com (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP versus UDP, many clients - / few servers

Jeff Martin <jeff@astph> writes:

	UDP methods increase speed ...

In what way?

/jordan

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1993 15:43:10 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC

amoss@picton.cs.huji.ac.il (Amos Shapira) writes:

>1. The client broadcasts on the net to the portmappers (UDP port 111) asking
>   on which port and which version is supported on the various hosts. (1
>   packet).
 
>2. The client receieves replies from all the portmappers telling it what port
>   to use in order to talk to your UDP server (n packets).
 
>3. The client starts talking to each server individually, because almost all
>   of them sit on a different port broadcast isn't used here (another n
>   packets sent and another n packets recived).


This is not right. Broad cast rpc works like this:

	- a broadcast call is send to port 111.
	  this is an indirect call.
	- all portmappers in turn call the procedure specified
	  indirectly. the daemons reply to the protmapper and
	  in turn the portmapper replies to the client.

Since broadcast is lossy, clnt_broadcast broadcast a number of
times (3 times?). All the portmappers will reply to those requests
again.

clnt_broadcast will continue to do so until ``eachresult'' returns
true or a timeout is reached.

Best way to limit this broadcasting is keeping track of
all servers that have responded. As soon as the duplicates are coming
in, have eachresult return true.

Casper

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1993 15:48:19 GMT
From:      xia@cs.mcgill.ca (Xiao Feng QIAN)
To:        comp.protocols.tcp-ip
Subject:   FAQ

Hello, guys.

I am a novice of this group.
I think I 'd better to have a look at this group's FAQ first instead
ask some s... questions.

Could anyone tell me where I can find the faq about this group?
Thanks a lot.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 16:34:49 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP dropping options for IP

In article <CEI3pv.MGE@ucdavis.edu> heberlei@cs.ucdavis.edu writes:
>Hi,
>
>I have been trying to develop an alternate traceroute
>program, but I am having trouble with the design.
>
>The design goes as follows:
>    Like traceroute, I send a packet to an unknown port on the
>	destination host.
>    Unlike traceroute, I have turned on the record route option in
>	the IP header.
>
>    What I think SHOULD happen is the remote machine returns an ICMP
>	error message which should include the IP header of my
>	probe packet and therefore, the recorded route.  Thus, I
>	would have a single probe version of traceroute.
>
>
>Unfortunately, the IP header returned inside the ICMP message is marked
>with a header length of only 20 bytes; the minumum for the IP header.
>All my IP options and recorded route are missing.
>
>Does anyone know why ICMP does not include options in the IP header
>that is returned?

Sounds like a bug.  The specs say that the received IP header plus
at least the first 8 bytes of data above the IP header should be
returned (to allow port numbers to be found).  This would include
any option fields in the received IP header.

Art


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 21:05:21 GMT
From:      jeff@astph (Jeff Martin)
To:        comp.protocols.tcp-ip
Subject:   TCP versus UDP, many clients - / few servers

i am coding a network database and wish to optimize speed.

we hope to use a many to few client/server model.  that is many
client processes 100-200 will be served by 5-20 database server
processes on the network file server.

UDP methods increase speed and simplify the many to few client/server
model.  however UDP lacks reliablity and increases complexity when
the transaction size is > than MAX message size.

TCP methods include reliability however they also seem to make the
many to few client/server model impossible unless we create a
new socket connection for each database transaction, which is way
too costly.

what protocol do network programmers use to optimize network speed?

is their such a thing as a reliable datagram service?  that is a
reliable protocol that allows a client process to send a transaction
to the server machine not neccessarily directed to a specific process,
but instead a group of server processes all waiting to read from
the same socket.

adTHANKSvance,  jeff
-- 
Jeff Martin, dbms programmer,		Philadelphia Phillies
INET:	astph!jeff@attmail.com		Voice:	(814)234-8592x32
UUCP:	attmail.com!astph!jeff		FAX:	(814)234-1269

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Oct 1993 23:58:12 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.protocols.tcp-ip
Subject:   Re: OpenView Product Requirements

In article <1993Oct1.211603.19383@iplmail.orl.mmc.com> Openview_forum@dmewrk1.orl.mmc.com writes:

[Large logo barphic deleted]

   We want to tell HP & HP OpenView Premier partners the types of requirements,
   comments/suggestion, Hot Issues, etc that will need to be addressed by the 
   speakers at the conference. (We want the correct people present at the 
   conference to answer the MAIL!!!)

   We want to make sure that speakers come prepared to address issues most 
   important to YOU!! With that in mind, would you please:

[...]

Sure, but only if you promise to:

- Omit large annoying logos from your articles.

- Use only one (1) exclamation mark per sentence.

--Ben

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Oct 1993 00:11:48 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC

In article <AMOSS.93Oct8124800@picton.cs.huji.ac.il> amoss@picton.cs.huji.ac.il (Amos Shapira) writes:
   I think you loose here because the RPC servers are not all on the same
   port.  The scenario you have (if I get RPC right) is as follows:

   1. The client broadcasts on the net to the portmappers (UDP port 111) asking
      on which port and which version is supported on the various hosts. (1
      packet).

   2. The client receieves replies from all the portmappers telling it what port
      to use in order to talk to your UDP server (n packets).

   3. The client starts talking to each server individually, because almost all
      of them sit on a different port broadcast isn't used here (another n
      packets sent and another n packets recived).


No. What is happening is there are four separate broadcasts being made for
every one time you call clnt_broadcast(). It is most lame, and appears to be
an attempt to make UDP reliable. For this application, reliability is less
important than being lightweight. Four times all the remote portmaps look
up the remote port, contact the servers, and the servers respond.

Playing with etherfind, I can definitely show -four- identical broadcast 
packets being sent every time I call clnt_broadcast()

--Ben



-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Oct 1993 01:39:14 GMT
From:      wow001@acad.drake.edu (Line & Wade)
To:        comp.protocols.tcp-ip
Subject:   SLIP on VAX????

Does anyone have any recomendations for SLIP on a VAX 4000?


I would really like to hear any share/freeware products that are out
there and what is involved in installing them.

Please forward responses to my email address.

wow001@acad.drake.edu


-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Oct 1993 06:11:52 GMT
From:      secssxn@mx.secs.csun.edu (Scott Neugroschl)
To:        comp.protocols.tcp-ip
Subject:   Firewall -- how to set one up?

I will be setting up a firewall soon.  I will have the following
connections (addresses not yet received from our info systems dept)...


	Company Net     _______
	    |          |  SCO  |
	    +----------+  ODT  +--- lab ethernet
		       |  2.0  |
		       | server|
			-------

The ODT 2.0 server will have 2 ethernet cards and act as a gateway
(and hopefully a firewall).  Also do I have my terminology confused?
What I really want is to allow access out of the lab net, but not into it.
How do I go about setting this up?

I apologize if this is not clear.

Scott Neugroschl
secssxn@mx.secs.csun.edu
-- 
Scott "The Pseudo-Hacker" Neugroschl
-- Beat me, Whip me, make me code in Ada

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 93 06:23:35 GMT
From:      mark@cairo.anu.edu.au (Mark)
To:        comp.protocols.tcp-ip
Subject:   ICMP unreach bombing (nukes)

Hi all,

I am interested in getting as much information about what can be done to 
reduce the effect of ICMP nukes sent by malicious cracker types. It's a
fairly common occurence these days to get a nuke at least once a day from
various places. Some sites have programs/machines setup to monitor and
record them but as to what is done about them afterwards, thats a gray area.

Some admins think that patching their machines would stop the problem for them,
notably patch 100567-04 for Sun machines being an example. What happens at
times is that the patches dont go all the way to protecting oneself from the 
nukes, as it's still possible to get hit. Wether it's impossible to stop or
they just didnt do it right isnt something I can say with any certainty.
Any advice in that area would be appreciated.

If a site is identified as being a frequent source of such nukes is it prudent
to ask the ip supplier for that site to restrict packets from the machine or
subdomain? I dont think replying in kind is really the way to go so what can
one do about it? 

Also would one of the net.gurus like to lay out exactly what happens when a
nuke is sent, I basically know but I want to make sure I didnt miss anything.
I have several sources for the nukers (DONT email asking for them) and have 
access on a limited basis to kernel code to study both so as much detail as
possible would be good.

Awaiting any and all replies. Email to me directly would be preferred.
Thanks,
Mark
mark@blackplague.gmu.edu
mark@cairo.anu.edu.au

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 93 09:44:10 GMT
From:      avalon@cairo.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP unreach bombing (nukes)

mark@cairo.anu.edu.au (Mark) writes:

[...]
>Some admins think that patching their machines would stop the problem for
>them,
>notably patch 100567-04 for Sun machines being an example. What happens at
>times is that the patches dont go all the way to protecting oneself from the 
>nukes, as it's still possible to get hit. Wether it's impossible to stop or
>they just didnt do it right isnt something I can say with any certainty.
>Any advice in that area would be appreciated.

Use a Unix which uses the patched NET-2 network code or doesn't use the
4.3BSD networking code but its own properly constructed code.  One example
is NetBSD 0.9.  It is based on NET-2 and the bug patched.  It is possible
to stop them all, but in doing so you are resigned to waiting for connect
to timeout rather than report "host unreachable".  The main problem with
the 4.3 code is that an error received and processed for one TCP connection
effects all connections that match the host IP pair, not just the one the
error was received for.  To fix the problem entirely was easier to change
over the entire networking code which was done with Solaris2 I believe.

[...]
>Also would one of the net.gurus like to lay out exactly what happens when a
>nuke is sent, I basically know but I want to make sure I didnt miss anything.
>I have several sources for the nukers (DONT email asking for them) and have 
>access on a limited basis to kernel code to study both so as much detail as
>possible would be good.

Quite simple I think.  ICMP error is received by one side, assuming it is
a legit reply, does error processing which closes down the socket locally.
Next packet sent along to the victim side is for a connection which no
longer valid, kernel sends back a reset and the other side closes.

Darren

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Oct 93 10:30:08 GMT
From:      db15@ukc.ac.uk (Damiano Bolla)
To:        comp.protocols.tcp-ip
Subject:   Any paper on variable length addressing ?

Can anybody point to one or more papers on performance
issues and impact on routing of a variable length addressing
scheme ?

This can be either for CO or CL networks.

Thanks !

Damiano

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 1993 15:39:02 GMT
From:      pottier@univ-brest.fr (Bernard Pottier)
To:        comp.protocols.tcp-ip
Subject:   Point to Point or SLIP between Sun and Mac & modem

Could somebody help to find a quick solution to carry TCP/IP
over a modem link with  SUn 4.1 on one side and Mac Sys7 on the
other end? The goal is to run MacX using a 14.4 modem.

Thanks. pottier@univ-brest.fr




-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 1993 17:14:56 GMT
From:      bobdobbs@illuminati.io.com (Shane Vincent Cantwell)
To:        comp.protocols.tcp-ip
Subject:   Wanted: DOS/Windows-based SLIP


	Cheap or PD preferred - reply E-mail, please. cantwell@mesa2.mesa.
colorado.edu is my preferred address. Thanks.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Oct 1993 00:28:15 GMT
From:      cmilono@netcom.com (Carlo Milono)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a 5 hub limit on UTP tcp/ip?

In article <CE1527.Lq6@world.std.com> jimr@world.std.com (James A Robinson) writes:
>Sorry for what is probably a very newbie question, but if a network
>has five hubs (four UTP hubs and a UTP/BNC repeater) will it mean that
>the computers on hub one will not be able to talk to the computers on
>hub five because the signal cannot go over five hub hops?

The earliest implementations of 802.3 used repeaters to regenerate the signal
to gain a distance advantage.  These early products were such that the spec
was written so that it appeared 'etched in stone' that four repeaters were
the absolute limit.

...time passes.  10BASE-T emerges.  Vistas open, etc.

Actually, what you must concern yourself with is 'round-trip bit delay'.  In
a bus-oriented media, you must find the longest possible path (without a
bridge or router), and calculate each hop (Computer-wire-hub-wire-hub-etc.)
and each element has a value that can be applied to the bit delay.  Your NIC
must still be transmitting to sense a collision of its own transmission!  You
cannot launch a packet (take the smallest possible one) and forget about it!
You must watch it and listen (round trip).

Another factor: preamble erosion.  If your hubs do not support preamble 
regeneration, you may have another limit to worry about. Each hub will waste
a few bits of the preamble to get in sync, and then it will pass the packet
along all routes...and through more hubs...until it is possible that you have
no more preamble to sync up to.  This is also sometimes called 'inter-packet
gap shrinkage', but that is a slightly different story.

-- 
+--------------------------------------------------------------------------+
|  Carlo Milono:  cmilono@netcom.com                                       |
|"When a true genius appears in the world, you may know him by this sign,  |
|that the dunces are all in confederacy against him."   - Jonathan Swift   |
+--------------------------------------------------------------------------+

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Oct 1993 19:32:37 -0800
From:      jmasud@csulb.edu (Jeff masud)
To:        comp.protocols.tcp-ip
Subject:   Re: Eudora for mac using slip

In article <st002073.5.2CB89EED@brownvm.brown.edu>,
st002073@brownvm.brown.edu (Brian Robert Perkins) wrote:

> I'd like to get Eudora running on my friends mac via slip.  I got Eudora, and 
> I got the slip connection running using the NCSA telnet with slip.  I think I 
> need something else, but I don't know.  I'm a PC man myself.  Might there be a 
> mac (slip) tcpip faq somewhere?

Yeah you can SLIP on the Mac, there is a program called MacSlip v1.0 and
VersaTerm-PRO which also has SLIP software in their package if memory
serves me right.  They are both commercial programs, so he'll have to go
out and buy'm.

Jeff

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 03:11:14 -0800
From:      wcheung@sdcc13.ucsd.edu (Wilson Cheung)
To:        comp.protocols.tcp-ip
Subject:   Re: Eudora for mac using slip

In article <jmasud-101093193237@mac6.cecs.csulb.edu>, jmasud@csulb.edu
(Jeff masud) wrote:

> In article <st002073.5.2CB89EED@brownvm.brown.edu>,
> st002073@brownvm.brown.edu (Brian Robert Perkins) wrote:
> 
> > I'd like to get Eudora running on my friends mac via slip.  I got Eudora,
> > and I got the slip connection running using the NCSA telnet with slip.  I
> > think I need something else, but I don't know.  I'm a PC man myself.  Might
> > there be a mac (slip) tcpip faq somewhere?
> 
> Yeah you can SLIP on the Mac, there is a program called MacSlip v1.0 and
> VersaTerm-PRO which also has SLIP software in their package if memory
> serves me right.  They are both commercial programs, so he'll have to go
> out and buy'm.

Besides the commercial packages MacSLIP and VersaTerm SLIP, there's one
more SLIP client packet driver available for the Mac...InterSLIP, and it's
FREE!

InterSLIP 1.0.1 is available via anonymous FTP from:

ftp.intercon.com:/InterCon/sales/InterSLIP1.0.1.image.hqx

-- 
Wilson Cheung
wcheung@sdcc13.ucsd.edu

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Oct 93 22:33:00 -0500
From:      tom.kauffman@channel1.com (Tom Kauffman)
To:        comp.protocols.tcp-ip
Subject:   Internic Mail Daemon Address

Help! I got this lovely memo from the Internic reference desk last week
on using the mail daemon to request RFCs -- but it doesn't include the
mail daemon address. I've tried ds.internic.net and ds@internic.net
(from what I remember of the conversation with the reference desk) and
both bounced.

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Oct 1993 21:52:43 GMT
From:      jkellett@netcom.com (Joe Kellett)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: IP over VSAT network

Mark Reardon (mwr@eng.tridom.com) wrote:

: The RS/6000 at one of our customer sites is running FTP (TCP/IP based)
: and the ping times are in the 1 to 2 second range.  That is from a 
: VSAT to the Customers data center (one satellite hop).  If your destination
: is on another VSAT then the double hop and switch decision would probably
: double that.  So, the low end of your range seems reasonable and the high
: could be caused by congestion and queueing.  

<deletions>

: As long as the delay doesn't double, no time out will occur.  If it does,
: a retransmission will occur.  My experience is that the RS/6000 worked
: well in our environment.  

How well does telnet work with this kind of delay (your low-end delay)?  I
understand characters echo back from the far end when using telnet, which (I
speculate in total ignorance) would cause an annoying "type-behind" effect.
I suppose ftp could be tuned for this kind of environment with larger window
sizes?  I have experience with SNA over GTE Spacenet (using poll spoofing),
and they're also talking about having a "router" function "soon".

Thanks.
-- 
Joe Kellett
jkellett@netcom.com

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Oct 1993 23:46:53 GMT
From:      st002073@brownvm.brown.edu (Brian Robert Perkins)
To:        comp.protocols.tcp-ip
Subject:   Eudora for mac using slip

I'd like to get Eudora running on my friends mac via slip.  I got Eudora, and 
I got the slip connection running using the NCSA telnet with slip.  I think I 
need something else, but I don't know.  I'm a PC man myself.  Might there be a 
mac (slip) tcpip faq somewhere?

Happily using slip on PC, but expanding my horizons

                                            Brian R Perkins
                                            Brian_Robert_Perkins@brown.edu or
                                            st002073@brownvm.brown.edu 

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 00:53:36 GMT
From:      roadkill@shell.portal.com (Roy - Kim)
To:        comp.protocols.tcp-ip
Subject:   rfc(s) on ports and port configurations?

I am trying my darndest to find the rfc's that document port and
port configuations on machines.

i.e.  telnet uses port info along with the i.p. address.

Any info on this would be greatly appreciated.

Please either post or e-mail responses.

Thanks,

-Roy
--
===============================================================
Roy Kim (roadkill@shell.portal.com)
"The future is here for those who have the vision to grab it."
Disclaimer:  1 + 1 = 3            This is an Alchemic solution.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 01:28:49 GMT
From:      dpm@cactus.org (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   dynamic address BOOTP server


I am trying to set up a SLIP server running on a BSD/386 box.  Users
will dial in on a rotary and will receive a "random" (port-based) IP
address each time they login.  I would like it to behave similarly to
a CISCO box so that I can adapt client-side software written for that
environment.

My biggest problem right now is getting a BOOTP server that knows how
to deal with this.  The BOOTP requests from the SLIP clients have null
IP addresses and either zeroed or nonsense hardware addresses.  Since
the request itself is meaningless, the BOOTP server needs to craft a
response based on the SLIP interface on which a request arrives.
Unfortunately, with datagram sockets, there seems to be little tracking
information available.

I've been looking at the NetBSD source (assuming it's pretty close to
the BSDI code), and haven't quite figured out how to discover the
originating interface for a datagram.  Does the IP address of the SLIP
interface get stored anywhere when the message comes in?  It looks
like some of the source routing code might be useful, but it appears to
be partially ifdef'ed out.

Any suggestions?  I'll keep experimenting to see if I come up with
an answer, but I would appreciate any hints.

Thanks,
David

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

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 03:21:34 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: timed vs. NTP (was: Specifying IP)

In article <CEJ90p.Er@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>>Actually.... did you change timed so that "date <new-time> ; rdate" works
>>on systems other than the master?  That's only a partial fix, but it's far
>>better than not having it at all.
>
>Which `rdate` did you use?  What did it do?

The rdate in question merely notifies the time daemon using the same TSP PDU 
used by the 4.3BSD date command.  It exists as a separate command only because
it was not feasible for us to change the OS date command.  It is unfortunately
mis-named which causes confusion with the rdate command found in other systems
(e.g. SunOS).

For purposes of this discussion, treat "date;rdate" on a SCO system as
equivalent to "date" on a 4.3BSD system.

I don't recall that the PDU in question needs to be sent to the "master"; I
believe it is sent to the local timed, which in turn notifies the "master." 
(if the local daemon is not the "master").  That is what the TSP document says,
although it could be wrong, I suppose.  Better go check the code...

Vernon, is there a summary of the differences between the 4.3-Tahoe and 4.4
versions of timed? (yeah, yeah, I'll look at the code... :-)
-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 05:07:38 GMT
From:      matt@ra.oc.com (Matthew Lyle)
To:        comp.protocols.tcp-ip
Subject:   Re: Eudora for mac using slip

jmasud@csulb.edu (Jeff masud) writes:
>In article <st002073.5.2CB89EED@brownvm.brown.edu>,
>st002073@brownvm.brown.edu (Brian Robert Perkins) wrote:
>>I'd like to get Eudora running on my friends mac via slip.  I got Eudora, and 
>>I got the slip connection running using the NCSA telnet with slip.  I think I 
>>need something else, but I don't know. I'm a PC man myself.  Might there be a 
>>mac (slip) tcpip faq somewhere?
 
>Yeah you can SLIP on the Mac, there is a program called MacSlip v1.0 and
>VersaTerm-PRO which also has SLIP software in their package if memory
>serves me right.  They are both commercial programs, so he'll have to go
>out and buy'm.

MacSlip is now up to version 2.0.  FYI.

-- 

Matthew Lyle                                           matt@oc.com
                                                       matt@utdallas.bitnet
OpenConnect System, Dallas, Texas                      (214) 888-0474

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 11:35:31
From:      backman@[128.127.125.119]  (Larry Backman)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: FTP PC/TCP 2.2, Windows 3.1 and remote printing

In article <CEKyFG.456@cdsmail.cdc.com> courtney@bml4380.cpg.cdc.com (Joseph D. Courtney) writes:

 >> : When I print I get several different results- the main one being that I
 >> : get nothing, but I have another strange effect, The PC (Windows) will hang
 >> : for about 30 seconds, and the speaker emits a click noise about every 
 >> : 5 seconds.
 >> : 
 >>   I have also noticed this clicking noise.  It seems to happen when the
 >>   network is not responding.
 >> 
The click indicates that the NFS redirector is retranmitting a
request.  That's probably why your NFS printing is failing.
You ought to send our support dept (support@ftp.com) a trace
of the network traffic when the click occurs.

Larry Backman
FTP Software


-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 93 07:04:03 GMT
From:      sac@stan.xx.swin.OZ.AU (Shane Catton)
To:        comp.protocols.tcp-ip
Subject:   winqvtnet and bootpd

We have netware lan with PCs. We are trying to get winqvtnet 
working with bootp server on our netware server.

is any one using winqvtnet and bootp.

I'm sure the bootp server is OK as NCSSA telnet works fine.
Its just winqvtnet comes back with error BOOTP failure.

we have netware 3.11 server
we have version 3.3 winqvtnet
we have BOOTP.NLM from Hellsoft software.

any help greatly appreciated.

shane catton
email: shane@admino.tafe.swin.edu.au

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 09:06:38 GMT
From:      zlsiimw@info.mcc.ac.uk (Mark Whidby)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PC-NFS 5.0 over packet driver ?

In article <28r8ls$8vm@trsun1.ingres.com>, jpmens@ingres.com (Jan-Piet Mens)
writes:
|> I would like to run PC-NFS 5.0 over a packet driver. I believe I 
|> need a new \NFS\PCNFS.SYS for this. Can someone enlighten me ?
|> Where can I get the PCNFS.SYS file for packet driver (archie doesn't
|> say much... :-)

You need a driver called PKTD.SYS (no new PCNFS.SYS);
you can get it from ftp.york.ac.uk and other places
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 11:32:37 GMT
From:      ccaajac@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Diferences using RPC with UDP and TCP?


see paper in IEEE Networks by wakeman et al jauary 1992 - covers RPC over tcp, (though
its about a performance problem).

-- 
jon crowcroft (hmmm...)

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 1993 11:55:49 GMT
From:      langstoeger@venus.kapsch.co.at (Peter Langstoeger)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip
Subject:   Unknown IP address

Hi.

Can anybody tell me, what the IP address [224.0.0.2] is ?
It is not a class A, B or C address.

I found a new workstation in my network, which generates messages to this IP
address and uses 010065000002 as target DLC (multicast) address, which is
again unknown to me. (SNIFFER says IANA, but what is it ?)

TIA

-Peter
--------------------------------------------------------------------------------
Peter "EPLAN" LANGSTOEGER        Tel.    +43 1 81111-2382
Network and VMS system manager   Fax.    +43 1 81111-888
Technical Computer Center (ADV)  E-mail  Peter.Langstoeger@kapsch.co.at
KAPSCH AG      Wagenseilgasse 1  PSImail PSI%(0232)281001141::Peter.Langstoeger
A-1121 VIENNA  AUSTRIA           "I'm not a pessimist, I am a realist"

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 12:23:32 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: IP over VSAT network

In article <jkellettCEpBFv.nn@netcom.com>, jkellett@netcom.com (Joe Kellett) writes:
|> Mark Reardon (mwr@eng.tridom.com) wrote:
|> 
|> How well does telnet work with this kind of delay (your low-end delay)?  I
|> understand characters echo back from the far end when using telnet, which (I
|> speculate in total ignorance) would cause an annoying "type-behind" effect.
|> I suppose ftp could be tuned for this kind of environment with larger window
|> sizes?  I have experience with SNA over GTE Spacenet (using poll spoofing),
|> and they're also talking about having a "router" function "soon".
|> 
|> Thanks.
|> -- 
|> Joe Kellett
|> jkellett@netcom.com

Telnet usually supports a local echo option (mode line) that
allows the characters to be echoed locally.  Then the delay is at the
end of command lines.  The responses to commands are slower but you 
are after all using a satellite link.  Also, be aware of applications
that echo characters other than those typed.  They must be run in 
mode character.


-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 12:48:52 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown IP address

langstoeger@venus.kapsch.co.at writes:

}Can anybody tell me, what the IP address [224.0.0.2] is ?
}It is not a class A, B or C address.
 
}I found a new workstation in my network, which generates messages to this IP
}address and uses 010065000002 as target DLC (multicast) address, which is
}again unknown to me. (SNIFFER says IANA, but what is it ?)

% whois 224.0.0.0
University of Southern California (NET-MCAST-NET)
   Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey, CA 90292-6695

   Netname: MCAST-NET
   Netnumber: 224.0.0.0
        :
        :

Indeed, it appears to be an IP multicast.

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

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 13:53:37 GMT
From:      leighd@syma.sussex.ac.uk (Leigh Dodd)
To:        comp.protocols.tcp-ip
Subject:   NE2000 Software Tester

Hi All
        Does any one know of a GOOD bit of software that will test the NE2000
card and give me some info back?.

         I'm having problems getting one to work with NDIS or ODI drivers and
on various machines. The NDIS driver reports back with "ADAPTER RAM TEST FAIL"
but I've tried every Address and Interrupt combination. The fault is a
conflict with another board but I need a bit more info on the card. BTW. It's
not the NE2000 card, I have another 10 and they are the same.

Thanks

Leigh

--
*******************************************************************************
* Leigh Dodd (Sun System Administrator)  |      Three Steps to Heaven         *
* University of Sussex                   | 1). C.B.T. ----- Passed            *
* Brighton, England.                     | 2). Part 2 ----- Passed            * 
* INTERNET: leighd@eaps.susx.ac.uk       | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 93 21:17:01 MDT
From:      sl88k@benson.declab.usu.edu (869883 Desai Rutvij Chandrahas)
To:        comp.protocols.tcp-ip
Subject:   ERROR IN gethostbyaddr() call

hi,
	I  have some problem in gethostbyaddr() system call. It is returning
	NULL.
	The segment of my code is like this:

	sockfd2 = accept(sockfd1,(struct sockaddr *) &cli_addrp,&addrlen);
	 hp = gethostbyaddr((char *)&cli_addrp->sin_addr,sizeof(structin_addr),
                            cli_addrp->sin_family);

           if (hp)
             hostname = hp->h_name;
           else
             hostname = inet_ntoa(cli_addrp->sin_addr);

	 my program is going into the else part because hp is NULL.

	I don't know why?
	Please send any suggesion.
							Thanks
							rutvij

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 15:23:56 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown IP address

In article <29bhk5$b72@theben.kapsch.co.at> langstoeger@venus.kapsch.co.at writes:
>Hi.
>
>Can anybody tell me, what the IP address [224.0.0.2] is ?
>It is not a class A, B or C address.
>
>I found a new workstation in my network, which generates messages to this IP
>address and uses 010065000002 as target DLC (multicast) address, which is
>again unknown to me. (SNIFFER says IANA, but what is it ?)

224.0.0.2 is the All Routers IP multicast address.  If the packet happened
to be an ICMP packet, I'd guess that it might be a Router Discovery Query.
Is this a fairly new release of TCP/IP software?

Art


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 17:14:40 GMT
From:      heberlei@cs.ucdavis.edu  (Louis Todd Heberlein)
To:        comp.protocols.tcp-ip
Subject:   IP level socket options

Aaauugggghhhhh!

I have been trying to set an IP option on a raw
socket for several days, but my setsockopt keeps
failing.  I have tries a number of combinations, but
no luck yet.  The error code returned is not of much
use since according the man page IP(4P) the error that
I am receiving (22 or EINVAL) can mean:
	An unknown socket option was given
	The IP option field was improperly formed;
		an option field was shorter than the minumum value,
		an option field was longer than the option buffer provided

Could someone send me, or point me to, some sample source code where
an IP options are set?

Any help would be greatly appreciated.

Thanks,

Todd Heberlein			heberlei@cs.ucdavis.edu

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 93 18:24:53 GMT
From:      ash@fender.Berkeley.EDU (Ashvini Nangia)
To:        comp.client-server,comp.protocols.tcp-ip,comp.os.misc,comp.unix.sys5.r3,comp.unix.sys5.misc
Subject:   Where can I get NTP for SVR4 ?

Where can I find a port of NTP (Network Time Protocol) for SVR4 based systems. 
If anybody out there is working on such a port or knows where to get one
please let me
know. Thanks in advance.

- Ash Nangia
   ash@mpd.tandem.com
   512-244-8045

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 18:34:36 GMT
From:      ian@zelator.in-berlin.de (Ian Leveson)
To:        comp.protocols.tcp-ip
Subject:   Can FTP's PC/TCP coexist with MS Win. for WG?


I've just tried installing Microsoft's Windows for Workgroups on a PC which
already has access to a unix server via FTP PC/TCP's NFS utilities. Has
anyone managed to retain access to the TCP/IP network at the same time as
connecting the PC to others via Windows for Workgroups? If so, how?  I
suspect that an appropriate network.inf and oemsetup.inf file would help do
the trick: are such files available?

Thanks in advance.


Ian Leveson

-- 

  Ian Leveson          internet: ian@zelator.in-berlin.de
  Berlin               Zerberus: Ian_Leveson@tbx-2.zer
  Germany              Fax.: +49 (030) 853 10 82 


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 93 18:35:17 GMT
From:      matt@marge.math.binghamton.edu (Matt Brin)
To:        comp.protocols.tcp-ip
Subject:   more than one interface on one net

We would like to split our local net into two parts.

Can we do this by putting a SUN with two ether interfaces
in between the two parts?  Both interfaces will have different
IP addresses, but will be on the same net.  We would run
arpserv to have machines trying to reach "across" this machine
use the etheraddress of this machine for their destinations.

Will the "bridge" machine know how to forward properly?

_____________________________________________________________________________
matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147
matt@math.binghamton.edu      	INTERNET
mbrin@bingvaxa			BITNET
-----------------------------------------------------------------------------


-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 93 00:18:49
From:      leinwand@mead.cisco.com (Allan Leinwand)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Is RMON a standard yet?

>   Can anyone out there tell me if RMON has become a standard yet? If 
>   it is not a full standard, what are the groups that have been stand-
>   arized? 

Hello Gerard,

    To the best of my knowledge, the RMON MIB is standardized in RFC
1271.

Thanks,

Allan Leinwand
cisco Systems
(510) 831-4730
leinwand@cisco.com

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 1993 20:46:30 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: Design of parallel TCP. Is it possible

I have an IP which is able to be symetrified, 
my TCP/UDP is based off the same model but it would be best 
to keep each connection locked to a local single processor, 
and it ( TCP ) has not been tested for true parallelism. The model
does allow ~line speed ethernet TCP.  
---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"

			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
---------*----------*----------*---------*---------*---------*



-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 1993 21:09:00 GMT
From:      valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown IP address

In article <29bhk5$b72@theben.kapsch.co.at> langstoeger@venus.kapsch.co.at writes:
>Can anybody tell me, what the IP address [224.0.0.2] is ?
>It is not a class A, B or C address.

Congradulations.  You've found a "multicast" address group.
Most likely, it's a newer Sun or DEC (maybe HP) workstation that has the
kernel support for IP multicast (which has been around for
ages but nobody supported correctly).

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 21:33:47 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: timed vs. NTP (was: Specifying IP)

In article <1993Oct11.032134.8771@i88.isc.com> stevea@lachman.com (Steve Alexander) writes:
>...
>The rdate in question merely notifies the time daemon using the same TSP PDU 
>used by the 4.3BSD date command.  It exists as a separate command only because
>it was not feasible for us to change the OS date command.  It is unfortunately
>mis-named which causes confusion with the rdate command found in other systems
>(e.g. SunOS).
>
>For purposes of this discussion, treat "date;rdate" on a SCO system as
>equivalent to "date" on a 4.3BSD system.

Ugh.  I would never have guessed that `rdate` does that.  Why not simply
change the date command?  Why not chose a better name than rdate?  How do
you avoid races with `timed` changing things between the `date` and the
`rdate` in `date;rdate`?  That's why the 4.3BSD `date` relies on timed to
do the change.  Oh, well.  I know of and have particpated in the
"non-technical issues" that cause such foulups.


>I don't recall that the PDU in question needs to be sent to the "master"; I
>believe it is sent to the local timed, which in turn notifies the "master." 
>(if the local daemon is not the "master").  That is what the TSP document says,
>although it could be wrong, I suppose.  Better go check the code...

Yes, of course, you're right.

>Vernon, is there a summary of the differences between the 4.3-Tahoe and 4.4
>versions of timed? (yeah, yeah, I'll look at the code... :-)

The code is the only useful summary of differences.  It's hard to remember
the whats of years of hacking, let alone the whys you seem to have done
whatever you did.  There was a "changes" file on vangogh.  Enclosed below
is most it.


Vernon Schryver    vjs@rhyolite.com

   -----
improve `timedc msite` to accept a list of hostnames.

change slave-masters to answer the packets generated by `timedc msite`
    with the name of the real master, not their own.  This makes it
    possible to "chase the chain" of slave servers to the ultimate
    master.

much improve the log caused by `timedc trace on`:
    -made `timed -t` work.
    -suppression of repeated entries, which both slowed down the daemon
        (sometimes catastrophically) and tended to make disks fill up
        even more quickly.
    -better time stamps on log entries
    -more messages
    -dump information about slaves, master, and so on each time
        a message asking the log be turned on is received, and
        when the log is turned off.
    -fewer CPU cycles

use a hash table to keep track of slaves, instead of the stupid linear
    list.  This becomes handy with hundreds of slaves, instead of
    the original design limit of "a room with a few VAX's."

separate the main protocol timer from that used to look for other networks
    to master.

time stamp packets received by the daemon, so that time corrections
    are not made (even more) inaccurate by waiting in the internal,
    timed queue while the daemon is processing other messages.

made -n and -i work with subnets not named in /etc/networks

compute the median of the measured clocks, instead of the average
    of "good" times.

vastly improve the accuracy of the clock difference measure by 
    `timedc clockdiff`.

use adjtime() when possible, and directly set the clock only when
    necessary.

when the requested adjustment is small, perform only part of it, to
    damp oscillations and improve the long term accuracy of the
    adjustments.

fix uncounted core-dumps on machines that do not allow dereferencing 0
    in both the daemon and timedc.

fix "master loop detection".

fix several cases in which multi-homed masters could get into shouting 
    matches, consuming all available network bandwidth and CPU cycles
    (which ever runs out first), and convincing all bystanders to stop
    advancing their own clocks.

refuse to behave badly when other machines do.  Instead of arguing forever,
    go off and sulk when other machines refuse to play by the rules.

increase the maximum number of clients.

add "-F host,host2,..." to "freerun" or "trust" only some hosts.  This
    is handy both when only some machines should be trusted to let
    root use the `date` command to change time in the network.

    It is also handy when one machine has some other way of adjusting
    its clock, whether NTP or a direct radio or atomic connection.
    "-F localhost" causes `timed` to "trust" only itself.

    It is also handy to build a hierarchy of timed masters crossing
    networks.  The TSP protocol has no provision of "goodness of clock",
    no natural way to completely heal network paritions.  Judicious
    use of -F or -G can cause each gateway to trust only itself and
    machines closer to a central machine with a radio or atomic clock.

add #ifdef code that supports NIS "netgroups" of trusted hosts, which
    can be easier to administer than -F.

add #ifdef code to compute an aged total adjustment.  This can be used
    in systems that can make long term changes in their system clock
    frequency, e.g. "timetrim" in the Silicon Graphics kernel.


Problems observed by others that are unresolved include:

Practically any users can send to the master TSP messages and this
        way corrupt the reliability of the system.  Authentication
        of messages should be provided.  Unfortunately, that would
        require changing the protocol with all of the implied
        compatiblity problems.  Fortunately, the new -F and -G args
        can be used to cause the daemon to ignore time changes from
        untrusted machines.

MAN.    The limit of 1013 on the number of slaves hosts should be doc'ed.

        It should be dynamically allocated with no limit.  On a
        large network, one host could possibly master over many
        more than 30 hosts.   Given the timers in the code and
        effectively in the protocol, and the time required by each
        master to talk to each slave, it is not practical to have
        more than 200-300 slaves.  The master cannot keep up because
        the slave-chatting is single-threaded.  when the master
        gets behind, slaves start demanding elections.  To
        significantly increase the number of slaves would require
        multi-treading things, and given that a network with more
        than 300 directly addressable machines has worse problems
        than keep the time of day right, not worth worrying about.

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Oct 1993 23:27:09 GMT
From:      Christopher.Vance@adfa.oz.au (CJS Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown IP address

In article <29bhk5$b72@theben.kapsch.co.at> langstoeger@venus.kapsch.co.at writes:
| Can anybody tell me, what the IP address [224.0.0.2] is ?
| It is not a class A, B or C address.
| 
| I found a new workstation in my network, which generates messages to this IP
| address and uses 010065000002 as target DLC (multicast) address, which is
| again unknown to me. (SNIFFER says IANA, but what is it ?)

It's a class D address. Dig says

; <<>> DiG 2.0 <<>> -x 
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6
;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 0
;; QUESTIONS: 
;;      2.0.0.224.in-addr.arpa, type = ANY, class = IN

;; ANSWERS:
2.0.0.224.in-addr.arpa. 86400   PTR     ALL-ROUTERS.MCAST.NET.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 00:27:28 GMT
From:      smilie@lsupoz.apana.org.au (Anthony Rumble)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general
Subject:   Looking for alternative to pc-route...

Does anyone know of an alternative/replacement for pc-route.

Be it Free, GNU, Shareware or Commercial..

Basic requirments..

Has to run on a PC based machine.

Has to have SLIP and either CSLIP or PPP.

Has to be able to handle RIP and Western Digital Ethernet cards.

Thankyou in advance..
-- 
root@lsupoz.apana.org.au   APANA Sydney UUCP regional hub (feeds available)
Anthony Rumble             Linux Support OZ (02) 418-8750 v.32bis - 3 lines
Voice (02) 418-8220	   For information on APANA mail info@apana.org.au

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 00:46:13 GMT
From:      smilie@lsupoz.apana.org.au (Anthony Rumble)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general
Subject:   Re: Looking for alternative to pc-route...

Anthony Rumble (smilie@lsupoz.apana.org.au) wrote:
: Does anyone know of an alternative/replacement for pc-route.
 
: Be it Free, GNU, Shareware or Commercial..
 
: Basic requirments..
 
: Has to run on a PC based machine.
 
: Has to have SLIP and either CSLIP or PPP.
 
: Has to be able to handle RIP and Western Digital Ethernet cards.

Oh.. P.S.. Don't suggest KA9Q.. It's too slow.
-- 
root@lsupoz.apana.org.au   APANA Sydney UUCP regional hub (feeds available)
Anthony Rumble             Linux Support OZ (02) 418-8750 v.32bis - 3 lines
Voice (02) 418-8220	   For information on APANA mail info@apana.org.au

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 1993 23:06:17 +0100
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: problems with large packets on UDP

In comp.protocols.tcp-ip, article <10225@laas.laas.fr>,
  owe@labiche.laas.fr writes:
> 
> 	So I would like to know if it is a well known problem of IP segmentation, 
>or if I have forgotten an operation whose missing makes the sending of 
>messages longer than 30400 bytes impossible. For the moment I do not 
>understand what happens, and why the sending of packets whose size is around 
>40000 bytes is impossible while UDP sockets allow it. 
> 
[ Please keep your lines to <80 characters ]

Looks like a signed 16-bit integer to me... i.e., a kernel bug.

If I were you, I wouldn't send one large UDP packet and let the IP layer 
split it -- split it yourself, say to 8k or so (same as NFS...). That way you 
receive bits and pieces of your picture, enabling you to keep old picture 
fragments around in case a packet gets lost. If that happens to your big UDP 
packet, the whole picture gets tossed when the kernel times out (which can be 
a few seconds).

-- 
Adam was but human -- this explains it all.  He did not want the apple for
the apple's sake, he wanted it only because it was forbidden.
                       -- Mark Twain, "The Tragedy of Pudd'nhead Wilson"
-- 
Matthias Urlichs        \ XLink-POP Nürnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstraße 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 08:25:48 -0400
From:      morris@ucunix.san.uc.edu (Ted Morris)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   IPX via SLIP/PPP?

Our University is instituting SLIP access through Zyplex multiprotocol
terminal servers.  A project I'm working on is going to install the
"same" equipment so they can be managed together.  PPP is not planned
immediately but is an option with this server.

Supposedly, it ought to be possible to "tunnel" IPX packets through IP;
I think I've also heard that upcoming Novell releases will allow the use
of TCP or IPX to move the Novell information (?)...

Has anyone -successfully- put a pc running IPX/NETx in touch with a
remote Novell server through a SLIP or PPP connection to the Novell's
LAN?  I recognize that 1) the Novell server must be running TCP/IP in
some flavor (LAN Workplace?), 2) the pc must be running both TCP/IP and
IPX (LAN Workplace again?) (at present), and 3) the pc must be running a
SLIP or PPP package and communicating with a suitable SLIP/PPP server on
the same internetwork as the Novell server.

From what we've read, we think this -could- be do-able, but haven't
heard of any successful installations yet.  We want to make our remotely
connected pcs both nodes on the TCP/IP network and clients of the Novell
server, basically, so they can run some of the Novell-stored MS-DOS/etc.
software.    (Yes, we know that will be slow...)

Thanks for any comments/suggestions/pointers.

Theodore Allan (Ted) Morris, University of Cincinnati Medical Center,
513-558-0177V, -2682F, MORRIS@UCUNIX.SAN.UC.EDU, MORRISTA@UC.EDU, WB8VNV
Previous politically-incorrect tag-line removed.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 08:02:49 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: problems with large packets on UDP

In article <29clcp$2v5@smurf.sub.org> urlichs@smurf.sub.org (Matthias
Urlichs) writes: 
    
    If I were you, I wouldn't send one large UDP packet and let the IP
    layer split it -- split it yourself, say to 8k or so (same as NFS...).
    That way you receive bits and pieces of your picture, enabling you to
    keep old picture fragments around in case a packet gets lost. If that
    happens to your big UDP packet, the whole picture gets tossed when the
    kernel times out (which can be a few seconds).
    
In fact, if you can fragment your data yourself, it's much better to send
path MTU sized datagrams.  NFS is not a particularly good model, as those
8k packets do get fragmented.  Any loss of a single fragment implies
retransmission of all fragments for that packet.

Tony


-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 08:12:12 GMT
From:      ccaajac@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown IP address

In article <29ci1c$rb2@solaris.cc.vt.edu>, valdis@black-ice.cc.vt.edu (Valdis Kletnieks) writes:
|> In article <29bhk5$b72@theben.kapsch.co.at> langstoeger@venus.kapsch.co.at writes:
|> >Can anybody tell me, what the IP address [224.0.0.2] is ?
|> >It is not a class A, B or C address.
|> 
|> Congradulations.  You've found a "multicast" address group.
|> Most likely, it's a newer Sun or DEC (maybe HP) workstation that has the
|> kernel support for IP multicast (which has been around for
|> ages but nobody supported correctly).

most likely its an SGI, which has had multicast support 
for quite a while:-)

or a proteon router...

-- 
jon crowcroft (hmmm...)

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 13:10:48 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Unknown IP address

In article <29ci1c$rb2@solaris.cc.vt.edu> valdis@black-ice.cc.vt.edu (Valdis Kletnieks) writes:

> Congratulations.  You've found a "multicast" address group.  Most
> likely, it's a newer Sun or DEC (maybe HP) workstation that has the
> kernel support for IP multicast (which has been around for ages but
> nobody supported correctly).

	Regrettably, we can be quite certain that it isn't an HP
workstation.  HP is, per usual, behind in their TCP/IP and UNIX
products and does not support IP multicasting at all.  There are
rumours that IP Multicast will be added when HPUX 10.x is released in
a few years, but HPUX 9.x doesn't support it.

	It is probably an _SGI_ or a newer Sun or DEC machine.  SGI
was the first to ship IP multicast support, though Sun was not long
behind (Solaris 2.x).  DEC apparently supports IP multicast in their
OSF/1 release only.  SGI deserves some credit for being the most
diligent vendor with regard to their TCP/IP networking feature set,
correctness of implementation, and also performance.

Ran
atkinson@itd.nrl.navy.mil



-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 13:13:20 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.client-server,comp.protocols.tcp-ip,comp.os.misc,comp.unix.sys5.r3,comp.unix.sys5.misc
Subject:   Re: Where can I get NTP for SVR4 ?

In article <1993Oct11.182453.20414@integrity.uucp>,
	ash@fender.Berkeley.EDU (Ashvini Nangia) writes: 

>Where can I find a port of NTP (Network Time Protocol) for SVR4 systems.  

	Despite wide crossposting, you didn't ask in the right place.
The place to ask is in comp.protocols.time.ntp and I think the answer
is that xntp3 does support many SVR4 implementations.

	Followups have been suitably redirected.  This answer was
posted rather than emailed in hopes of helping other folks find the
right newsgroup for NTP material.



-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 13:54:20 GMT
From:      nakkala@cs.tamu.edu (Venkatesh Nakkala)
To:        comp.databases.oracle,comp.protocols.tcp-ip
Subject:   HELP !!! ..Socket call in FORMS 3.0 User Exits giving an error....


  Howdy,
        I am trying to open connection to 2 TCP/IP servers from a user_exit
   in the PRE_FORM Trigger... after making the runform30 executable and
   running the form I get an error.......

   Too many open files.........this is on the socket system call in the 
   user_exit...

   Thanks in advance for any help,

   Venkatesh Nakkala
   nakkala@photon.cs.tamu.edu
-- 
       Venkatesh  Nakkala    nakkala@cs.neuron.tamu.edu 
 Off : (409)845-5481                       Res : (409)846-7638
 Dept. Of Comp Sci.,Texas A & M Univ.      Fax : (409)847-8578 
-----------------------------------------------------------------------------

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 14:15:37 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP/OSI Convergence - from EWOS


To all those interested in TCP/IP and OSI Transport & Network layer
protocols,  here is a message/invitaion from EWOS (European Workshop on OPen
Systems):



TCP/IP/OSI Convergence - Information from EWOS
-----------------------------------------------

Discussions are currently underway in EWOS (the European Workshop for
Open Systems) on the potential convergence of TCP/IP and OSI. Parties
both within and outside EWOS are being invited to submit contributions
to these discussions, and particularly to an initial EWOS meeting on
the subject of TCP/IP/OSI convergence to be held October 25th 1993.

Information and contributions concerning TCP/IP/OSI convergence are
being made available on the EWOS Information Server. 

This document provides details of how to access TCP/IP/OSI directory
on the EWOS Information Server and where to send comments and
contributions. 

Submission of Comments and Documents on TCP/IP/OSI Convergence 
---------------------------------------------------------------

Please send contributions to:

EWOS Secretariat
Rue de Stassart 36
B-1050 Brussels
Belgium

Telephone: +32 2 511 7455
Fax:       +32 2 511 8723

X.400: c=be; a=rtt; p=y-net; o=sp1; s=ewos
rfc mail: ewos@sp1.y-net.be

OR

Chris Makemson
EWOS TCP/IP/OSI Convergence Coordinator

CMC Ltd
22 Bourne Firs
Lower Bourne
Farnham GU10 3QD
United Kingdom

X.400: c=gb; a=gold 400; p=level-7 ltd; o=cmc ltd; s=makemson; g=chris
rfc-822: c.makemson@eurokom.ie

Telephone: +44 252 783 8855
Fax:       +44 252 783 8855

Accessing the TCP/IP/OSI Directory on the EWOS Information Server
-----------------------------------------------------------------

This directory is called tcp-ip-osi and is located in the top level
menu.  


The server can be accessed interactively or via Email.

Interactive Addresses

     X.25:                 EuropaNET network:    2043 3450 3999 66
                           Public X.25:          2342 3440 0193 66

     Telnet:               concise.level-7.co.uk 
                           146.97.32.62

     Dialup Access:        Telephone:            +44 344 868 436
                           Use following settings on terminal emulator:
                           no parity, 8 bits, 1 stop bit, half duplex
                         
     User-id:              Login: ewos
                           Password: ewos

Electronic Mail Addresses

     X.400:          s=ewos; o=concise; p=level-7 ltd; a= ; c=gb
                     (try a="gold 400" if a=" " does not function)
     
     RFC-822:        ewos@concise.level-7.co.uk

To be sent a user guide for the server, email the following message:

                           start
                           help user-guide


Automatic Delivery of Documents
-----------------------------------

If you would like all documents which appear in the tcp-ip-osi
directory to be automatically emailed to you, send a message containing
the following instructions to the Server:

           start
           goto /tcp-ip-osi
           register new-info


If you need further help accessing the EWOS Information Server contact:

EWOS Information Server Helpdesk
Level-7 Ltd, Centennial Court, Easthampstead Road, Bracknell,
Berkshire, RG12 1YQ, UK 

Telephone: +44 344 360049       Fax: +44 344 868442

X.400: S=helpdesk; O=CONCISE; P=Level-7 Ltd; A= ; C=GB (or A="GOLD
400")

RFC-822: helpdesk@concise.level-7.co.uk

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

forwarded by:

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 14:16:22 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: New IP protocol?

In article <28gbsf$fqj@news-feed-2.peachnet.edu> Jerry@PeachNet.EDU (Jerry W. Segers) writes:
>Are these two <requirements> for <real time> video as real as Dale and
>many in the telephony industry seem to believe?
>
>My understanding is that any real time video over a network will be
>compressed in some way, at least to the extent needed to remove the
>redundant information (e.g. MPEG).  I also understand that current
>compressors are required by current telephony standards to emit
>constant output streams.  Thus each compressor will use a relatively
>large frame buffer that is filled from the output of the compression
>process then emptied into the communication path at a constant rate.  
>
>Is it not reasonable to change the approach when using a transport
>method like IP that has a variable transmission rate?  For example has
>there been any work done along the lines of moving the buffer to the
>other end of the path.  That is, send the variable output from the
>compressor directly to the network and collect it in a buffer at the
>receiving end.  If the data arrives too late or is lost, the buffer
>will empty but the display software can repeat the last frame thus
>causing the display to stutter then jump but the picture quality will
>not degrade.  The same argument would seem to apply to audio as well.
>Instead of duplicating the output on buffer empty just output silence.

	I think that this is the basis for some of the digital cellular
telephone protocols which are being developed to make most practical use
of the radio spectrum which is available for this purpose.  The systems
use linear predictive coding to encode and decode the voice.  When
conversation is happening, the data rate increases to about 9600 bits/sec,
but pauses while the other person is talking or while one is on hold or just
thinking mean that the encoder just repeats the same background noise or
silence which doesn't have nearly as much information in it and so it can
drop down to a few hundred bits per second.  The receiver will deliver the
correct sound to the ear so a user won't even know anything has changed.

	I am not an engineer, nor do I play one on T.V., but there seems to
be a fundamental truth that it is much easier to have a slightly dirty network
than it is to have a perfect one.  Everything in life, from human conversation
to highway traffic has to base its operation on the idea that chaos reigns
and that all we can do is make the best of an uncertain situation.  I cast my
lot with those who say that we should find ways to make all types of data
coexist rather than engineering a new protocol each time somebody comes up
with a new application.  

	Saying all that, it is also true that networks can only stand so
much degradation before everybody becomes unhappy.  Big buffers won't help
you at all when the gaps in throughput become to long to sustain minimum
bandwidth.  If this is not the case, however, then one should be able to
run video, voice and anything else with no trouble at all as long as the
buffers can absorb the variations in throughput which come from a busy
network.

	I have always been most interested in protocols like TCP-IP and
"Kermit" because they are based on the chaos of the real world and they work
under terrible conditions.  This doesn't mean that there is no room for
improvement, but only that chaos is the rule and that the future belongs
to whoever can best manage it.

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

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 14:32:32 GMT
From:      weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general
Subject:   Re: Looking for alternative to pc-route...

Hello,

Anthony Rumble (smilie@lsupoz.apana.org.au) wrote:
>: Does anyone know of an alternative/replacement for pc-route.
 
>: Be it Free, GNU, Shareware or Commercial..
                                 ^^^^^^^^^^

Ok: Novell Multi-Protocoll-Router. Basing on a Runtime Version of Novells
Netware 3.11 it has extensive ip routing capapbilities (according to what they
told me on Networld). PPP Support, Don't know about SLIP. Needs a 386sx
box minimum, and probably advanced hardware for serial connections.

BTW why not take one of the free Unix versions ? Linux ? NetBSD (or what 
they call it this week) ?

>Oh.. P.S.. Don't suggest KA9Q.. It's too slow.

Well, then...

Regards

Christoph Weber-Fahr

-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de 
  Universitaet Kaiserslautern,  KIT     |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-67653 Kaiserslautern
--------------------------  My personal opinion only    ---------------------

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 15:19:54 GMT
From:      bleimeyp@wolf.mayo.edu (Paul Bleimeyer)
To:        comp.protocols.tcp-ip
Subject:   WINQVT / PCNFS 5.0 and Hgopher


Hello,

I am looking for someone who has gotten the Hgopher Client to pass the 
internet address and port # to their telnet session while running either
pcnfs 5.0 or WinQVT 3.9x. You have to define this in the dialog for  
calling the telnet session when connecting to a telnet based site. Has  
anyone figured out how to do this? I have tried to do this under WINQVT  
and PCNFS but they see the environment variables as setup files. If you  
got this to work, could you send me the string that you put in the dialog  
box?

regards,
--
Paul Bleimeyer
Mayo Foundation
Bleimeyp@mayo.edu


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 16:33:20 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Information Service


	What is a good way to provide those who don't have accounts on this
system access to certain information.  We use this system as a remote print
server, among other things, and we have the problem of tracking print jobs
from the host which actually originated the job to the printer.  When something
goes wrong, there is no way for a person who does not have an account on
datacomm.ucc.okstate.edu to see if their job ever got that far.  For the sake
of peace and quiet and a lessening of interruptions, it would be nice to
provide everybody concerned with a finger-like program that they could
telnet to or finger which would let them see a listing of all the printers
and their statuses or even look at the emerging log file to see if their
job was ever printed.

	Needless to say, we would only want to do this if it was possible
to do it with a reasonable expectation that it could not be subverted to some
other purpose for which we hadn't planned.  Please let me know your ideas
on this topic and I will post the best suggestions.  Thank you.

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

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 93 16:58:43 GMT
From:      wwg@coutts.UUCP (Warren W. Gay VE3WWG)
To:        comp.protocols.tcp-ip
Subject:   IP Protocol RFC(s) & ftp/listserv site(s)???

Can some kind person direct me to the necessary RFC documents that I
need to get the TCP & IP protocol specifications? I want to know the
implementation details, packet formats, state diagrams, encoding etc.

Having identified the RFCs, my next need is, a source for these. Listserv
access is preferred, but I can always ftp via decwrl if I must.
Can someone suggest electronic sources for the above RFC document(s)?

Please email the reply.  Thanks in advance.

--------------------
Warren W. Gay VE3WWG		John Coutts Library Services Limited		
wwg@coutts.UUCP			Niagara Falls, Ontario, Canada

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 18:57:26 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: more than one interface on one net

In article <matt.750364517@marge> matt@marge.math.binghamton.edu (Matt Brin) writes:
>We would like to split our local net into two parts.
 
>Can we do this by putting a SUN with two ether interfaces
>in between the two parts?  Both interfaces will have different
>IP addresses, but will be on the same net.  We would run
>arpserv to have machines trying to reach "across" this machine
>use the etheraddress of this machine for their destinations.
 
>Will the "bridge" machine know how to forward properly?

Sorry, this won't work. Each NIC must be on a unique net; the software
can't route between two networks that have the same network number.

You'll have to subnet in order to split things up, or get a repeater
and use it if your problem is length or too many connections.


-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chairman of the Board and the CFO speak for SCI. I'm neither.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 14:20:18 +0300
From:      orel@oeaix.oea.ihep.su (Oleg Orel)
To:        comp.protocols.tcp-ip
Subject:   Question to all users of libftp

	Attention to all users of libftp!

I wonder, if you can answer to the author of libftp on the following questions:

	1. What's the name of your organisation?
	2. How many people use it?
	3. Which purposes do you use this library for? 
	4. What kind of software do you produce with it's help?
	5. Which standard operations are to be added?

	If you found some errors in the program and fixed them, 
	please, let me know and send me your patches.


Thanks.
---
						Oleg Orel
						orel@oea.ihep.su
-- 
---------------------------------------------------------------------------
| Oleg Orel, Russia, Protvino       |   orel@lpuds.oea.ihep.su            |
| Institute of High Energy Physics  |   Home Phone: 49106                 |
---------------------------------------------------------------------------

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 19:35:13 GMT
From:      bff@next.pvh.org (Brendan F. Forsyth)
To:        comp.protocols.tcp-ip
Subject:   Routing with SLIP

I have a machine (machA) with both SLIP and ethernet connections.  The  
ethernet is attached to our local net and the SLIP is a connection to a  
terminal server attached to the internet via an Internet VAR.

This local machine (machA) can connect to all systems, Internet and local,  
without difficulty but none of the local ethernet systems can connect to  
Internet systems.  The local network machines all have IP addresses that  
are not registered with the NIC.  Only the SLIP address has a valid class  
'C' number assigned by the NIC.

I put a serial analyzer on the SLIP connection and when a request is made  
from one of the ethernet machines for Internet access the source IP  
address field has the ethernet machine's IP address contained within.  It  
would seem apparent that when the packet hits the other side of the SLIP  
connection it is getting delivered to the destination IP address but when  
the corresponding packet is sent back it gets lost because the return  
address is one that may be in use by a node on the Internet.  This  
legitimate node then probably throws away the packet since it did not  
originate it.

If I understand ARP correctly, hardware address and IP address are  
utilized to perform routing.  But the SLIP connection does not use  
hardware addresses in its limited encapsulation scheme.

Is it possible to have the SLIP connection work as a gateway/router for  
the local machines to connect to Internet services since a SLIP connection  
does not use hardware addresses in its packets to associate IP addresses  
with hardware addresses?

If it is possible, what am is the solution to routing traffice through the  
SLIP connection>

Any and all suggestions would be greatly appreciated.

Thanks
Brendan
bff@pvh.org

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 21:05:35 GMT
From:      nam@peregrine.esl.com (Nam N. Nguyen)
To:        comp.protocols.tcp-ip
Subject:   SLIP over modem line?

I and my colleagues are scratching our heads trying to make SLIP
working over a modem connection.  With direct cable connection,
it is working fine.  Now, when each end is connected to a modem,

what is the proper procedure for attaching slip, using standard
SunOS tools (tip, ...)?

When we try to tip to make a modem connection, quitting tip
causes the line to drop (NO CARRIER).  NO good!

If we leave tip there, slip-attach cannot access the port.

Any netter has successfully done this,  PLEASE help!

Thanks,

Nam N.




-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 21:13:44 GMT
From:      waynej@ncs.com (Wayne Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC

In article <BEN.93Oct6204231@piglet.cr.usgs.gov> ben@piglet.cr.usgs.gov (Ben A. Mesander) writes:
>
>Hello,
>
>While developing an RPC/UDP application, I thought it would be more efficient
>to contact rpc daemons on my local network with broadcast RPC, rather than
>calling each host in turn. It would seem that if the number of hosts is n,
>then calling each host would result in 2n udp packets for every call (barring
>complications), while a broadcast scheme would involve n+1 packets - one for
>the broadcast, and n replies.
>
>However, I see that every host is responding to a clnt_broadcast() call four
>times, so I see 4n+1 packets. I have verified that the RPC libraries in SunOS
>4.1.3 and DG/UX 5.4.1 both do this. The source to clnt_broadcast() looked
>opaque to me, so I used etherfind to sniff rpc/udp on my network. When I
>make a clnt_broadcast() call, the rpc client sends out four, rather than
>one broadcast packet.
>
>Is this a bug?

I've been using clnt_broadcast() for one of our products and I found that we
transmit one packet on each one of our interfaces (loopback, and two ethernet
interfaces), but the pain is that the RPC client (also in the same box) receives
all three and replies to them.  This is on a RS/6000 running AIX 3.2.4.

With all the problems we've had with this and other related things (i.e. how
not to send to certain systems where you have test software and vise versa...)
I almost wish the original writer hadn't used them.
-- 
Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
     National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
                                           - Jim Elliott

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 21:24:22 GMT
From:      eddjp@huber.com (Dewey Paciaffi)
To:        comp.protocols.tcp-ip
Subject:   Duplicate IP Numbers

We have an environment mix of IBM workstations/servers and PCs,
in a wide area Internet. Recently we've seen an increase of PCs running 
TCP/IP. Along with this increase has come an alarming number of 
duplicate IP addresses being configured into the PCs. The PCs hang
until the situation is cleared up, of course. We are also able to
make workstations and servers hang using PCs. Some people here are
understandably distressed about this. My question is how are others 
in this type environment dealing with this issue, be it malicious or
innocuous in intent. 
-- 
Dewey Paciaffi    
eddjp@huber.com       

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 21:34:58 GMT
From:      johnson@tigger.jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing with SLIP

bff@next.pvh.org (Brendan F. Forsyth) writes:

>This local machine (machA) can connect to all systems, Internet and local,  
>without difficulty but none of the local ethernet systems can connect to  
>Internet systems.  The local network machines all have IP addresses that  
>are not registered with the NIC.  Only the SLIP address has a valid class  
>'C' number assigned by the NIC.

You have correctly identified the problem: trying to use an
unregistered IP network number on the Internet.

>If I understand ARP correctly, hardware address and IP address are  
>utilized to perform routing.  But the SLIP connection does not use  
>hardware addresses in its limited encapsulation scheme.

ARP is used to resolve addresses within an IP network, not for
routing between IP networks, i.e. across the Internet.

>Is it possible to have the SLIP connection work as a gateway/router for  
>the local machines to connect to Internet services since a SLIP connection  
>does not use hardware addresses in its packets to associate IP addresses  
>with hardware addresses?

In general, yes.  Use or lack of hardware addresses is not the issue.

>If it is possible, what am is the solution to routing traffice through the  
>SLIP connection>

Get a registered IP network number for your local machines.
Talk to your internet service provider to determine what
must be done to get packets routed to your local network
via the various IP backbones.

>Any and all suggestions would be greatly appreciated.

Don't try and route non-registered IP addresses out onto the
internet at large.  At best, it won't work.  At worst, it will
cause headaches for some other people.

-Steve

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1993 22:01:56 GMT
From:      Colen Garoutte-Carson <colen_garoutte-carson_at_sym-be@symantec.com>
To:        comp.protocols.tcp-ip
Subject:   The telnet protocol

	If there is another newsgroups in which I'd be more likely to get an
answer, please let me know.

I have written BBS software which, in addition to handling modem
connections, handles telnet connections.  Unfortunatly, the terminal
emulation (PC-ANSI BBS) doesn't interface too well with most telnet
terminals.  Now, I understand that there is a way to change the settings
of the remote terminal with telnet IAC sequences.  Is there a way to tell
the remote terminal :

not to send LFs after it's CRs
not to echo characters, the host will echo them back
not to buffer characters on a line basis

If this is at all possible, could someone give me the EXACT escape code
sequence needed?  I don't plan on supporting the telnet IAC sequences. 
All I'm doing now is responding to IACs with "Uh... I dunno how to do
that" for every option they suggest, so all I want to do is send this
string of IAC sequences once the telnet connection had been establish.

Any help is greatly appreciated!

 - Colen Garoutte-Carson

Please send replies to my email address : 
colen_garoutte_carson_at_sym-be@symantec.com

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Oct 1993 22:06:26 GMT
From:      subbu@cup.hp.com (Subbu Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   Info needed:"fail-safe" FTP

I would like to know if there is a public domain FTP that can do retries
etc. while transfering files over unreliable links? I believe it is
sometimes referred to "relibale" FTP.

WO|uld appreciate if you can email the info to me

Thanks,

-Subbu
Email:subbu@cup.hp.com


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 93 10:28:11 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   Re: Is NIC running out of unique IP addresses?

In article <28ukf1$jee@gaia.ucs.orst.edu>, larsen@OES.ORST.EDU (Scott Larsen) writes:
|> In article <WYNN.93Oct5111625@haduk.cms-stl.com>,
|> Tim Wynn <wynn@cms-stl.com> wrote:
|> 
|> >	One of my co-workers is in a UNIX course on TCP/IP right 
|> >now, and he tells me that his instructor said that NIC is running 
|> >out of unique IP addresses.  Because of this, he says, NIC is 
|> >calling people to ask for any unused addresses they might have 
|> >requested in the past.  Furthermore he said, it's next to impossible 
|> >to get contiguous blocks of addresses anymore, and getting any 
|> >addresses takes 6 weeks or more.
|> 
|> Not true.  3 weeks ago I requested 6 type "C" addresses and they are 
|> contiguous.  They arrived in about 3 days.
|> 
|> ...
|> 
|> However, address depletion is a serious issue.  According to "Supernetting:
|> an Address Assignment and Aggregation Strategy", by V. Fuller, T. Li, J. Yu,
|> and K. Varadham, all class "B" addresses could be exhausted within the next
|> 15 months, if the present rate of growth is maintained.  In exchange, large
|> quantities of class "C" addresses are being given out to avoid this.  This,
|> though, puts a larger load on routers, as they have larger tables to maintain.
|> 
|> Current research is being done by the ROAD (Routing and Addressing) group of
|> the IETF (Internet Engineering Task Force).
|> 

As Scott Larsen mentions, all of this is a serious issue, which is taken
seriously. The IAB/IESG/IETF have been working on this problem for several
years. In short, the Internet has been experiencing a rapid and sustained
growth in the past years, doubling its "size" every year or maybe faster. If
nothing had been done, the following problems would have occured:

1) exhaustion of the "class B" numbering space between 1993 and 1994,

2) explosion of the size of the routing tables,

3) exhaustion of the network numbering space between 1997 and 2004.

The ROAD working group, under the leadership of Peter Ford, analyzed these
problems and provided a set of recommendations in Spring 1992. One of the
results of these is the recommendation of the class less addressing
architecture (CIDR). The idea is to taylor address assignments to the exact
needs of the requesting organization: if you have 1000 hosts, you will get 10
or maybe 11 bits of address space (4 or 8 contiguous class C) instead of one
class B (16 bits). This is already implemented; it will make the address
utilization more efficient, and avoid the "class B exhaustion" pitfall (number
1 above).

Indeed, assigning more "class C" has the immediate effect of speeding up the
"routing table exhaustion" problem. The NSFNET tables listed 10057 
configured networks by March 1993, 17092 by October 93. Out of these, 13063
were class C. The answer to this problem is to deploy the second part of CIDR,
classless routing. Suppose you have received 8 contiguous class C networks:
there is no need to represent them by 8 entries in the routing tables; a 21
bits long prefix would carry the same information. Now, suppose that assignment
of addresses somehow follows "network topology", e.g. that all networks in the
island of Tahiti are numbered out of a single range of class C addresses, with
a common 14 bits prefix: it would be sufficient to carry that prefix in the
routing tables, instead of 1000 separate networks. This will get us rid of the
second pitfall, "routing table exhaustion" -- with one condition though: we
must deploy routing protocols capables of routing on variable length masks,
like OSPF version 2, RIP version 2 or the last version of BGP.

The third danger is more difficult to avoid completely. There are currently
about 2 million hosts in the Internet. If the size of the net keeps doubling
every year, there will be more than 4 billion hosts in the net in 11 years,
and there will be no way to assign them unique numbers out of a 32 bits space.
In fact, we will very likely run out of 32 bits addresses before registering 4
billion hosts -- we don't assign address very efficiently now, and there are
many cases of a class C net with just a dozen hosts. On the other hand, nobody
has the slightest idea of future growth rates -- doubling every year for 11
years is not necessarily going to happen. As a result, the opinions of experts
vary considerably. Some think that a combination of CIDR + claiming back
unused address + renumbering when appropriate would lead us "well into the
XXIst century", while other think that the danger is more imminent and that we
should deploy relatively fast a "next generation of IP". Several working
groups are currently studying possible IP next generation designs, based on
either extending the IP address to 64 bits (SIP and PIP, TP-IX) or replacing
IP by ISO-CLNP (TUBA) -- comparing these solutions would make this message way
too long!

In the short term however, there is no such thing as an address shortage.

On CIDR, I recommend the reading of:

1520  I    Y. Rekhter, C. Topolcic, "Exchanging Routing Information Across 
           Provider Boundaries in the CIDR Environment", 09/24/1993. (Pages=9)
           (Format=.txt)                                                      
 
1519  PS   V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain 
           Routing (CIDR): an Address Assignment and Aggregation Strategy", 
           09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338)           
 
1518  PS   Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with 
           CIDR", 09/24/1993. (Pages=27) (Format=.txt)                        
 
1517  PS   R. Hinden, "Applicability Statement for the Implementation of 
           Classless Inter-Domain Routing (CIDR)", 09/24/1993. (Pages=4) 
           (Format=.txt)                                     
 
1481  I    C. Huitema, I. Architecture Board, "IAB Recommendation for an 
           Intermediate Strategy to Address the Issue of Scaling", 07/02/1993.
           (Pages=2) (Format=.txt)                                            
 
1467  I    C. Topolcic, "Status of CIDR Deployment in the Internet", 
           08/06/1993. (Pages=9) (Format=.txt)                                
 
1466  I    E. Gerich, "Guidelines for Management of IP Address Space", 
           05/26/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1366)           
 
Christian Huitema

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 10:36:23 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   How do I tie in remote PC's & CRT's without SLIP/PPP Maybe a "Net Modem"?

I need a way to tie in 2 remote sites that will have term servers
and PC's running PCNFS.  I need to be able to telnet to the host,
use host printers and mount remote file systems.  I have seen a
net modem by Rockwell that does just this, but it's only for dialup
lines at 14.4 baud.  I need something to go over a leased digital
line.  Can anyone give me some direction?  I'm very new to this
area of networking, so please be easy on me! 


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 93 16:39:49 MDT
From:      slmt9@cc.usu.edu (Joshua Dinerstein)
To:        comp.protocols.tcp-ip
Subject:   HELP with TELNET options in binary mode!

	Hello all,

	I desprately need some help with a telnet aplication. I have been
working on a telnet port of sorts. And I have a problem. My problem is that
when I switch the telnet session into binary mode, using "set binary on" and
then try to connect to the local Unix host I am forced to enter a ^J to get the
proper username and password entered instead of just using the return key. So
I have to do:

slmt9^J
xxxxx^J

	rather than

slmt9<ret>
xxxxx<ret>

	In looking at the telnet code, it appears that it is just passing the
CR (\r) onto the remote end. Where the remote end is waiting for a LF (\n)
(or even a CRLF).

	So my question: Is there a way to tell the remote system to react to
just a CR rather than a LF or CRLF combination? I do not want just swap the CR
and LF as this telnet client allows binary file transfers and swapping the
codes would mess this up completely.

	Any help or ideas would be greatly appriciated,

	Joshua
	SLMT9@cc.usu.edu

-- 
**************************************************************
*                     *                                      *
*  Joshua Dinerstein  *  Nothing matters and what if it did? *
*  SLMT9@cc.usu.edu   *            - Who Knows!!!            *
*                     *              Anyone?? Anyone??       *
**************************************************************

If it's a raincoat why does it have to be dry cleaned?
        - Some Guy on some comody show

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 11:36:30 GMT
From:      a866700@hp9000.csc.cuhk.hk (Wong Siu To)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Routing on machines with 2 network interface...

Hi there,

I apologize if this's a FAQ...

We've a unix machine (HP9000/755) with 2 network interface connected to
2 different subnets (e.g. 137.189.6 and 137.189.7).  I wonder if the
machine will act as a router to route packets to and fro these 2
subnets.  If the answer is yes, how can we stop that ?

Would anyone pls advise ?  Any help will be appreciated.

Regards,

-- 
S.T. Wong             	            | BITNET: A866700@CUCSC.BITNET      
Computer Services Centre            | Internet: st-wong@cuhk.hk 
The Chinese University of Hong Kong | Tel. No: (852) 609 8825      
Shatin, N.T., Hong Kong	            | FAX  No: (852) 603 5001

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 11:41:06 GMT
From:      oproque@scosysv (Pedro Miguel M R Marques)
To:        comp.protocols.tcp-ip
Subject:   Re: Information Service

Martin McCormick (martin@datacomm.ucc.okstate.edu) wrote:

: 	What is a good way to provide those who don't have accounts on this
: system access to certain information.  We use this system as a remote print
: server, among other things, and we have the problem of tracking print jobs
: from the host which actually originated the job to the printer.  When something
: goes wrong, there is no way for a person who does not have an account on
: datacomm.ucc.okstate.edu to see if their job ever got that far.  For the sake
: of peace and quiet and a lessening of interruptions, it would be nice to
: provide everybody concerned with a finger-like program that they could
: telnet to or finger which would let them see a listing of all the printers
: and their statuses or even look at the emerging log file to see if their
: job was ever printed.
 
: 	Needless to say, we would only want to do this if it was possible
: to do it with a reasonable expectation that it could not be subverted to some
: other purpose for which we hadn't planned.  Please let me know your ideas
: on this topic and I will post the best suggestions.  Thank you.
 
: Martin McCormick WB5AGZ   Stillwater, OK
: O.S.U. Computer Center Data Communications Group

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 12:29:02 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Text Descriptions with FTP's "ls" command

john@iastate.edu (John Hascall) writes:

>nelson@crynwr.com (Russell Nelson) writes:
>}In article <CE6AAH.2BA@news.iastate.edu> john@iastate.edu writes:
>}
>}   PS, I really love how programs like NcFTP send junk like:
>}       NLST -FC file
>}   assuming that all (unix) LIST/NLSTs are ls-based...   (*sigh*)
>}
>}That's why the FTP protocol needs a new XLST command, which is
>}guaranteed to return information in a parsable format.  The obvious
>}choice is the output of "/bin/ls -lg".  That makes implementing XLST
>}just a matter of making an alias for NLST.
 
>   ... all the world's Unix disease again ...

I'm in agreement with John here. FTP servers can be running Unix, DOS,
Windows NT, OS/2, VMS (several flavours of server on each of these).

When I'm using an FTP server, at least the anonymous variety, I'd like
to know a description. Good maintainers have README, INDEX etc - maybe
there should be a preferred place and format for this info, so that
clients can try to fetch it automatically.

On file statistics, I do *not* usually want to know the permissions,
owner or group of the file - I can get this from DIR if I need it, but
it should not contain any useful information.  Maybe, occasionally, I'd
like to know if there's write-permission on a directory.  I do like to
know the size of the file, to a rough estimate if necessary, and
whether it's a plain file or a directory. It's sometimes useful to know
the last-modified date as well. These concepts should apply to pretty
well any server.

I usually do "ls -sCF" if it looks like a consenting Unix. This
presents what I want to know with a minimum of screen real-estate; but
I'd vote for a one-file-per-line name/size/type, with the types being
plain file or directory. Maybe split "plain file" into text, binary and
others - i.e. the "preferred" mode of the server when you fetch it.

This, if adopted (if!) would make life a lot easier for writers of FTP
client front-ends, who currently have to do some nasty heuristic
grovelling to work out if that thing there is a directory, which is
their main worry.

Ian
-- 
--- 
Ian Phillipps. Tech support manager, Unipalm.	If you ask me, all conspiracy
Phone +44 223 250103, Fax 250101		theories are put about by the
Pipex phone +44 223 250120. Internic: IP4.	same bunch of people.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 93 13:23:33 GMT
From:      luce@dunk.ccit.duq.edu (Douglas Luce)
To:        comp.protocols.tcp-ip
Subject:   Re: more than one interface on one net

Gary Heston (gary@sci34hub.sci.com) wrote:
: In article <matt.750364517@marge> matt@marge.math.binghamton.edu (Matt Brin) writes:
: >We would like to split our local net into two parts.
 
: >Can we do this by putting a SUN with two ether interfaces
: >in between the two parts?  Both interfaces will have different
: >IP addresses, but will be on the same net.  We would run
: >arpserv to have machines trying to reach "across" this machine
: >use the etheraddress of this machine for their destinations.
 
: >Will the "bridge" machine know how to forward properly?
 
: Sorry, this won't work. Each NIC must be on a unique net; the software
: can't route between two networks that have the same network number.
 
: You'll have to subnet in order to split things up, or get a repeater
: and use it if your problem is length or too many connections.

It might work: for each machine you add to the network, a static route
can be put on the Sun, and a proxy ARP entry as well.  This will make
the sun respond to ARP requests for certain machines, and then be able
to route packets that come in for that machine.

It requires that every host you add to the network gets a route and
proxy ARP entry on the Sun.  If you want to exercise fascist control,
this is doable, but for convenience, it's pretty unwieldy.  If you
just want to tie two nets together, a bridge is probably what you
want.  (Maybe Sun has a product that'll turn a Sun station into a
bridge?)

Doug Luce
Duquesne University CCIT

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 13:25:32 GMT
From:      hoosh@netcom.com (Hooshmand Afsar-zadeh)
To:        comp.protocols.tcp-ip
Subject:   Is there an application for dumping tcp-ip packets

I am looking for a way to write the data that is being received
by a proprietary database application (via tcp/ip) to a logfile
in order to use that data to populate a database on a pc for
novice users. I am looking for an application that allows me to
intercept the data stream and if possible even do more things
like parsing out the packet headers and creating a data file. The
hardware is an HP workstation. I have heard of tcpdump, how can
I get it? Is there anything better or more complete available?

Thanks in advance.

Regards,
hOOsh*


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 14:06:43 GMT
From:      lance@indiana.edu (Lance Speelmon)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: IPX via SLIP/PPP?

We are doing IPX tunneling here with FTP's PCTCP 2.2.  Novell's LAN Workplace 
for DOS also includes the tunneling drivers.  Both packages support slip and 
ppp.

Lance

In article <29e7oc$lhg@ucunix.san.uc.edu> morris@ucunix.san.uc.edu (Ted 
Morris) writes:>From: morris@ucunix.san.uc.edu (Ted Morris)
>Subject: IPX via SLIP/PPP?
>Date: 12 Oct 1993 08:25:48 -0400
 
>Our University is instituting SLIP access through Zyplex multiprotocol
>terminal servers.  A project I'm working on is going to install the
>"same" equipment so they can be managed together.  PPP is not planned
>immediately but is an option with this server.
 
>Supposedly, it ought to be possible to "tunnel" IPX packets through IP;
>I think I've also heard that upcoming Novell releases will allow the use
>of TCP or IPX to move the Novell information (?)...
 
>Has anyone -successfully- put a pc running IPX/NETx in touch with a
>remote Novell server through a SLIP or PPP connection to the Novell's
>LAN?  I recognize that 1) the Novell server must be running TCP/IP in
>some flavor (LAN Workplace?), 2) the pc must be running both TCP/IP and
>IPX (LAN Workplace again?) (at present), and 3) the pc must be running a
>SLIP or PPP package and communicating with a suitable SLIP/PPP server on
>the same internetwork as the Novell server.
 
>From what we've read, we think this -could- be do-able, but haven't
>heard of any successful installations yet.  We want to make our remotely
>connected pcs both nodes on the TCP/IP network and clients of the Novell
>server, basically, so they can run some of the Novell-stored MS-DOS/etc.
>software.    (Yes, we know that will be slow...)
 
>Thanks for any comments/suggestions/pointers.
 
>Theodore Allan (Ted) Morris, University of Cincinnati Medical Center,
>513-558-0177V, -2682F, MORRIS@UCUNIX.SAN.UC.EDU, MORRISTA@UC.EDU, WB8VNV
>Previous politically-incorrect tag-line removed.


 ============================================================================
|  Lance Speelmon                  |     University Computing Services       |
|  lance@indiana.edu               |     LAN Systems Support Specialist      |
 ============================================================================

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 15:03:35 GMT
From:      weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general
Subject:   Re: Looking for alternative to pc-route...

Hello,

following up om myself...
weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) writes:
>Anthony Rumble (smilie@lsupoz.apana.org.au) wrote:
>>: Does anyone know of an alternative/replacement for pc-route.
 
>>: Be it Free, GNU, Shareware or Commercial..
>                                 ^^^^^^^^^^
 
>Ok: Novell Multi-Protocoll-Router. Basing on a Runtime Version of Novells
>Netware 3.11 it has extensive ip routing capapbilities (according to what they
>told me on Networld). PPP Support, Don't know about SLIP. Needs a 386sx
>box minimum, and probably advanced hardware for serial connections.

Another one: I just saw an ad (sort of) for a packet driver based software 
router from IPSWICH software. It seems to be rather inexpensive, and, since
it was specifically advertized for dual channel ISDN routing, it should be
able to process that kind of speed.

>BTW why not take one of the free Unix versions ? Linux ? NetBSD (or what 
>they call it this week) ?

That question seems to remain unanswered.

Regards

Christoph Weber-Fahr

-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de 
  Universitaet Kaiserslautern,  KIT     |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-67653 Kaiserslautern
--------------------------  My personal opinion only    ---------------------

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 15:12:31 GMT
From:      eddjp@huber.com (Dewey Paciaffi)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Static Arp Tables

I was experimenting with the arp command under AIX 3.2.[2-4]. The
FM lead me to believe that the "arp -s" command could create a 
"permanent" table entry. My test showed that if a system with
a hardware address different from the one in the permanent arp
entry logged in, the system with the entry would cache the new hardware
address, leaving the entry marked "permanent".

Does "permanent" in this case mean "won't be dynamically dropped"
or "will never change" ? If it's the latter, then my arp is
broken.


-- 
Dewey Paciaffi    
eddjp@huber.com       

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 15:16:34 GMT
From:      eddjp@huber.com (Dewey Paciaffi)
To:        comp.protocols.tcp-ip
Subject:   RARP

I have remote PCs accessing Unix machines across the wide area through
Cisco routers. Can RARP work through routers?


-- 
Dewey Paciaffi    
eddjp@huber.com       

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 15:17:31 GMT
From:      douglas@micmac.ctr.columbia.edu (Paul Douglas)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP freeware for 68k?

Hi Everyone,

	I'm looking for TCP-IP freeware (or low-costware) that will
run or can be easily ported to a 68k system running pSOS.

Does anyone out there know of such software?
Thanks, Paul
douglas@ctr.columbia.edu

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 16:38:54 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing on machines with 2 network interfa

I think there is a 'gated' program on HPs. Just follow the directions
on how to build the /etc/gated.conf (man gated-config).






+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
| "The expressed opinions are of my own"   + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 17:45:35 GMT
From:      addy@meiko.co.uk (David Addison)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing on machines with 2 network interfaces

For Solaris 1.x and Solaris 2.x I think the answer is yes, packets will be
forwarded automatically between the two networks.
This forwarding is performed inside the kernel and does not require a daemon.
To disable it you need to set the kernel IP variable 'ip_forwarding' to 0.
Don't know how you do that on a HP - sorry!.


Addy.

---

David Addison				Email:	addy@meiko.co.uk
Meiko,					   or:  addy@meiko.com			
650 Aztec West,				Tel  :	+44 (0)454 616171		
BRISTOL, BS12 4SD.			Fax  :	+44 (0)454 618188	


-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 18:16:48 GMT
From:      hjb@netcom.com (hwajin bae)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP freeware for 68k?

In article <29h66b$8gu@sol.ctr.columbia.edu> douglas@micmac.ctr.columbia.edu (Paul Douglas) writes:
>
>	I'm looking for TCP-IP freeware (or low-costware) that will
>run or can be easily ported to a 68k system running pSOS.
>
>Does anyone out there know of such software?

i don't know about pSOS but i've done ports of various versions of 
BSD TCP/IP, including net-2 BSD code.  the net-2 code works well
and can be easily ported to a simple RTOS (i'm working on a free
port of this to my own RTOS for 68k, so stay tuned...) i know....
vaporware alert!  ;-)

hwajin

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 19:39:36 GMT
From:      mwilensky@lotus.com (Marshall Wilensky)
To:        comp.protocols.tcp-ip
Subject:   What characters are illegal in a TCP/IP hostname?

What characters are illegal in a TCP/IP hostname?  If it's easier, answer the
converse question:  Which special characters are legal?  I'm only concerned
with the printing US ASCII characters found on most keyboards.

I've been looking for a while and haven't been able to find a definitive
answer.  Is there a formal definition for hostname?  Even a pointer to an
appropriate RFC or FAQ would help.

Before anyone goes off the deep end, I'm not planning to start using bizarre
system names.  I know that various command line interpreters have their own
ideas about what these characters mean and I've also spent enough time with
sendmail.cf files to realize that special characters should be avoided almost
at all costs.  But I still need to know.

Here's what I have so far:

  space			( )	ILLEGAL
  exclamation point	(!)
  at sign		(@)
  pound sign		(#)
  dollar sign		($)
  per cent		(%)
  caret			(^)
  ampersand		(&)	ILLEGAL
  asterisk		(*)
  left parenthesis	(()
  right parenthesis	())
  hyphen		(-)	LEGAL
  underscore		(_)
  equal sign		(=)
  plus sign		(+)
  backslash		(\)
  vertical bar		(|)
  left bracket		([)
  left brace		({)
  right bracket		(])
  right brace		(})
  semicolon		(;)
  colon			(:)
  apostrophe		(')
  quotation mark	(")
  back quote		(`)
  tilde			(~)
  comma			(,)
  less than		(<)
  period		(.)
  greather than		(>)
  slash			(/)
  question mark		(?)


Thanks in advance.

--
Marshall Wilensky                               mwilensky@lotus.com
Lotus Notes Technical Support
Lotus Development Corporation                   Voice   +1 617 693 1810
55 Cambridge Parkway                            FAX     +1 617 693 5561
Cambridge, MA   02142

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 93 20:22:53 GMT
From:      Brad.Hedstrom@engr.UVic.CA (Brad  Hedstrom)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: FTP PC/TCP 2.2, Windows 3.1 and remote printing

On 7 Oct 1993 15:50:36 GMT, stephen@orchid.UCSC.EDU () said:
>Remote printing under DOS seems to work fine using 'lpr' command.
 
>But when trying to access remote printers via windows apps, it just
>doesn't behave itself.  
 
>I have gone through the setup procedure several times-  under FTp Network
>Icon, then to printers, I setup a host:printer, username=nobody, type=pcnfs
>port=lpt2, then I connect, and everything seems to be OK.

Make sure that you're not running the kernel in extended memory. Also
make sure that you have the correct EMMExclude in you system.ini for
your NIC.

>When I print I get several different results- the main one being that I
>get nothing, but I have another strange effect, The PC (Windows) will hang
>for about 30 seconds, and the speaker emits a click noise about every 
>5 seconds.

Sounds like your using NFS printing. Try switching to LPR. Also get
version 2 of PCNFSD.

I've had both LPR and NFS printing under Windows working fine (using
the 3c503 kernel). 
--
_________________________________________________________________________
Brad Hedstrom, Ph.D.                      Internet: hedstrom@engr.UVic.CA
   Consultant in DSP, LabVIEW, Networking, Sun, Macintosh, and now PCs

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 22:53:22 GMT
From:      maf@dunedin.acs.ohio-state.edu (Mark Fullmer)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP Numbers

In article <29f7a6$dch@muddy.huber.com> eddjp@huber.com (Dewey Paciaffi) writes:
>We have an environment mix of IBM workstations/servers and PCs,
>in a wide area Internet. Recently we've seen an increase of PCs running 
>TCP/IP. Along with this increase has come an alarming number of 
>duplicate IP addresses being configured into the PCs. 

If you you have a unix box on your network capable of running tcpdump, take
a look curiosity.cob.ohio-state.edu:/pub/arpmon/* (anonymous ftp).

>-- 
>Dewey Paciaffi    
>eddjp@huber.com       
 
-- 
mark
maf+@osu.edu


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1993 23:05:31 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP

In article <29h64i$dfm@muddy.huber.com> eddjp@huber.com (Dewey Paciaffi)
writes: 
    I have remote PCs accessing Unix machines across the wide area through
    Cisco routers. Can RARP work through routers?
    
Currently, RARP must be bridged through the routers....

Tony


-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Oct 1993 23:40:46 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: What characters are illegal in a TCP/IP hostname?

> What characters are illegal in a TCP/IP hostname?

In general, starting with RFCs 1122 and 1123 for host related issues is the
best approach (nearly equivalent to a FAQ).  And sure enough, RFC 1123, p. 13
says:

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.
 
      Host software MUST handle host names of up to 63 characters and
      SHOULD handle host names of up to 255 characters.
 
and RFC 952, p. 1 says
 
   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  Note that periods are only allowed when
   they serve to delimit components of "domain style names". (See
   RFC-921, "Domain Name System Implementation Schedule", for
   background).  No blank or space characters are permitted as part of a
   name. No distinction is made between upper and lower case.  The first
   character must be an alpha character.  The last character must not be
   a minus sign or period....

Note that RFC1123 supercedes RFC 952 on name length as well as use of
digits.

Craig

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 1993 11:49:31 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Routing on machines with 2 network interface...

In article <1993Oct13.113630.4559@hp9000.csc.cuhk.hk> a866700@hp9000.csc.cuhk.hk (Wong Siu To) writes:
>Hi there,
>
>I apologize if this's a FAQ...
>
>We've a unix machine (HP9000/755) with 2 network interface connected to
>2 different subnets (e.g. 137.189.6 and 137.189.7).  I wonder if the
>machine will act as a router to route packets to and fro these 2
>subnets.  If the answer is yes, how can we stop that ?
>

   If there is no typographic error in your posting, host IP addresses
   137.189.6
   137.189.7
   would be two different hosts on the same IP network.

   Depending on implementation, you may have some "interesting
   issues on your hands.

   Is that really the IP addresses?  What's your netmask?


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 1993 00:32:41 GMT
From:      jdlacour@dlsunf.dal.mobil.com (J. D. La Coursiere [Jeff])
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Routing on machines with 2 network interface...

In article <1993Oct13.113630.4559@hp9000.csc.cuhk.hk>, a866700@hp9000.csc.cuhk.hk (Wong Siu To) writes:
> Hi there,
> 
> I apologize if this's a FAQ...
> 
> We've a unix machine (HP9000/755) with 2 network interface connected to
> 2 different subnets (e.g. 137.189.6 and 137.189.7).  I wonder if the
> machine will act as a router to route packets to and fro these 2
> subnets.  If the answer is yes, how can we stop that ?
> 
> Would anyone pls advise ?  Any help will be appreciated.
> 
> Regards,
> 
> -- 
> S.T. Wong             	            | BITNET: A866700@CUCSC.BITNET      
> Computer Services Centre            | Internet: st-wong@cuhk.hk 
> The Chinese University of Hong Kong | Tel. No: (852) 609 8825      
> Shatin, N.T., Hong Kong	            | FAX  No: (852) 603 5001


Hmm.  The answer to this depends on your control over the machines
in both subnets.  If you want the HP to be able to talk to machines on
both subnets, then you will have routes to pass packets to each ethernet
card.  If you disable the routes on the other machines so they can't 
resolve external addresses (flush the table, kill routed, add static
route for appropriate subnet ONLY), then they will give a message like:
"no route to host" when told to connect to an outside machine.  

You didn't mention if the subnets had other gateways to escape the 
subnet.  If this is the case, you should add a default route on each machine
pointing to the desired gateway (as well as flushing the table, killing
routed).

The first option will allow the machines to talk to all others on
the subnet (including the HP) but nothing outside the subnet.

The second option (if another gateway exists) will allow full 
communication for all hosts but all packets destined to outside hosts
will NOT be routed through the HP.

If you don't have this kind of control over the machines in both
subnets, there is nothing to stop them from adding you as a default gateway
to the other subnet.  The HP, receiving a packet that it knows how to
pass on, will gladly do so.

Jeff LaCoursiere
Network Admin
Mobil Research Facility
Dallas, TX

lacoursj@dal.mobil.com

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 02:27:54 GMT
From:      bff@csn.org (Brendan Forsyth)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing with SLIP

Steven L. Johnson (johnson@tigger.jvnc.net) wrote:
: bff@next.pvh.org (Brendan F. Forsyth) writes:
 
: >This local machine (machA) can connect to all systems, Internet and local,  
: >without difficulty but none of the local ethernet systems can connect to  
: >Internet systems.  The local network machines all have IP addresses that  
: >are not registered with the NIC.  Only the SLIP address has a valid class  
: >'C' number assigned by the NIC.
 
: You have correctly identified the problem: trying to use an
: unregistered IP network number on the Internet.

A proper routing config will protect the Internet from erroneous traffic.

: Get a registered IP network number for your local machines.
: Talk to your internet service provider to determine what
: must be done to get packets routed to your local network
: via the various IP backbones.

Getting a registered number for over 50 nodes and then reconfiguring each
is not a feasible solution.

Once again could we open a discussion of routing and SLIP connections?
I am sure that I am not the only one experiencing this problem.

Thanks
Brendan

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 04:35:41 GMT
From:      dpm@cactus.org (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   IP header checksum calculation


I known I am missing something obvious here.  I am trying to write a
routine that computes an IP header checksum.  I have read both Comer's
book and RFC791.

Here is Comer's description of the checksum calculation:

"The IP checksum is formed by treating the header as a sequence of
16-bit integers (in network byte order), adding them together using
one's complement arithmetic, and then taking the one's complement of
the result.  For purposes of computing the checksum, field HEADER
CHECKSUM is assumed to contain zero."

Here is the tcpdump output for a random packet off my network (taken
on a i486 NetBSD box):

22:15:24.38 clave.depend.com.login > archons.depend.com.1023: P 1:28(27) ack
0 \win 7300 [tos 0x10]
                         4510 4300 cd02 0000 3c06 565d c6bb cc02
                         c6bb cc01 0102 ff03 0100 0000 0000 0000
                         5018 841c f90f 0000 7463 7064 756d 703a
                         206c 6973 7465

The IP header is 5<<2 = (20 octets) = (10 16-bit words) long.  The
checksum field is the 6th 16-bit word (0x565d).

No matter what I try, I cannot reproduce the correct checksum.  I
tried doing it by hand.  I tried writing my own algorithm and
executing it.  I even tried extracting the code from in_cksum.c in the
NetBSD sources.  The "sum" I get is 0x496a (or 0x6a49 if I byte-swap).

What am I doing wrong?

Thanks,
David
(feeling really dumb at the moment)



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

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 07:44:49 GMT
From:      crd@hplb.hpl.hp.com (Chris Dalton)
To:        comp.protocols.tcp-ip
Subject:   Re: IP header checksum calculation

David P. Maynard wrote:

| I known I am missing something obvious here.  I am trying to write a
| routine that computes an IP header checksum.  I have read both Comer's
| book and RFC791.

It's not that obvious, so don't feel bad.  The problem is that tcpdump
is lying through its miserable teeth.  To be more accurate, it has
presented certain fields - 16 and 32 bit numbers - in the IP header
with the wrong byte-ordering, but others (such as the checksum)
are all right.  I guess someone thought this was a feature.

| 22:15:24.38 clave.depend.com.login > archons.depend.com.1023: P 1:28(27) ack
| 0 \win 7300 [tos 0x10]
|                          4510 4300 cd02 0000 3c06 565d c6bb cc02
|                          c6bb cc01 0102 ff03 0100 0000 0000 0000
|                          5018 841c f90f 0000 7463 7064 756d 703a
|                          206c 6973 7465

If this were presented in network byte order, it would look like this:

    4510 0043 02cd 0000  3c06 565d c6bb cc02
    c6bb cc01

The checksum of that comes out OK.  The TCP header also looks badly
garbled:  the source port, destination port, sequence, acknowledgement,
and window fields are all wrong-endian.


Chris

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 1993 16:25:06 -0500
From:      ILJACOB%orion.cpqd.ansp.br@UICVM.UIC.EDU (Eduardo Jacob)
To:        comp.protocols.tcp-ip
Subject:   telnet ^M + ^J problem

        I have a problem with my telnet for IBM PC. When I type something and
press ENTER (^M), if I press ^J right after, the host doesn't answer to the ^J.
The host seems to  "ignore" a ^J (LF) after a ^M (CR). ^J after ^J is OK. Does
this happen due to some parameter my telnet isn't negociating with the host
telnet ?

        Another question : does anybody know of a free ftp server source
code ?

        Please, reply to the following email address (not to me !)  :

                                roja@dcc.unicamp.br

        Thanx in advance.

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 93 15:32:10
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: What characters are illegal in a TCP/IP hostname?

In article <1993Oct13.153936@lotus.lotus.com> mwilensky@lotus.com (Marshall Wilensky) writes:
   What characters are illegal in a TCP/IP hostname?  If it's easier,
   answer the converse question:  Which special characters are legal?
   I'm only concerned with the printing US ASCII characters found on
   most keyboards.

The short answer is:  Hyphen ("_") is allowed (but not as a leading or
final character), and period (".") is allowed (but has special
meaning, of course).

RFC 1034 has this to say:

    3.5. Preferred name syntax

    The DNS specifications attempt to be as general as possible in the rules
    for constructing domain names.  The idea is that the name of any
    existing object can be expressed as a domain name with minimal changes.
    However, when assigning a domain name for an object, the prudent user
    will select a name which satisfies both the rules of the domain system
    and any existing rules for the object, whether these rules are published
    or implied by existing programs.

    For example, when naming a mail domain, the user should satisfy both the
    rules of this memo and those in RFC-822.  When creating a new host name,
    the old rules for HOSTS.TXT should be followed.  This avoids problems
    when old software is converted to use domain names.

    [...]

    Note that while upper and lower case letters are allowed in domain
    names, no significance is attached to the case.  That is, two names with
    the same spelling but different case are to be treated as if identical.

    The labels must follow the rules for ARPANET host names.  They must
    start with a letter, end with a letter or digit, and have as interior
    characters only letters, digits, and hyphen.  There are also some
    restrictions on the length.  Labels must be 63 characters or less.

RFC 1178 has some further useful advice.  (Including the non-obvious:
Don't choose names consisting solely of legitimate hexadecimal
digits.)

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Nothing frustrates me more than the twentieth century adherence to the
notion that you can find out what "actually happened" and that it is
necessary for fiction to set out a linear, quantitative and absolute
reality for the reader's consumption and assurance.

I think EVERYTHING is like the Kennedy assassination(s); riddled with
inconsistencies, false trails overlapping stories and considerations;
distortions wrapped inside fabrications and coated with lies. The
sooner we get over the idea that reality isn't like this, the sooner
we'll be able to put together a world that fits our circumstances as
they are; not as they never were and will never be. I'm not holding my
breath.

-- Dave Sim

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 11:16:43 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.sys.novell,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Novell & Banyan & TCP/IP

khai@adi.com (S. Khai Mong) writes:

>I have this application which uses Novell's TCP/IP API and compiled
>and linked with Novell's TCP/IP product.  This works fine on
>Novell client workstations.
 
>My question: Is there a chance that such an application will run on a
>client workstation that has _only_ Banyan and Banyan's TCP/IP software
>installed?  Is there any quick answer why it won't work?  (I am
>thinking of getting Banyan's TCP/IP software)


No chance since the API calls are specific to the Novell TCP/IP stack.
A windows application that is compiled to run over the Windows Sockets
API will run over most TCP/IP stacks but otherwise you will need to 
compile and link your application with a Development kit appropriate
to the TCP/IP stack you will be using.

(There are many ways to run multiple protocol stacks on one card, the
golden rule is only one of each type. So you can run Banyan+TCP/IP+Netware
from the same box but cannot run (for instance) Lan Workplace (TCP/IP) 
with PC-NFS (TCP/IP).

Which drivers you use for the card may make this easy or difficult and WILL
affect performance and Memory consumption. 

I have been burnt by several of the other TCP/IP stacks mentioned in this tread
concerning RAM usage and reliability. Personally I get on with PC/TCP which
is what Banyan OEMs. If you want concurrency over NDIS or ODI then Lan Workplace
should work with Banyan, if you need encapsulation PC/TCP from Banyan is your
only option. Since I have never worked on a Banyan site I will not offer any
recommendations that might mislead.


>-- 
>Sao Khai Mong  Applied Dynamics, 3800 Stone School Road, Ann Arbor, MI 48108
>Voice: (313) 973-1300x263      Fax: (313) 668-0012      E-mail: khai@adi.com  

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 12:02:38 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Text Descriptions with FTP's "ls" command

ian@unipalm.co.uk (Ian Phillipps) writes:
}john@iastate.edu (John Hascall) writes:
}>nelson@crynwr.com (Russell Nelson) writes:
}>}That's why the FTP protocol needs a new XLST command, which is
}>}guaranteed to return information in a parsable format.  The obvious
}>}choice is the output of "/bin/ls -lg".  That makes implementing XLST
}>}just a matter of making an alias for NLST.
 
}>   ... all the world's Unix disease again ...
 
}I'm in agreement with John here. FTP servers can be running Unix, DOS,
}Windows NT, OS/2, VMS (several flavours of server on each of these).
 
}On file statistics, I do *not* usually want to know the permissions,
}owner or group of the file - I can get this from DIR if I need it, but
}it should not contain any useful information.

  One possible use for permissions would be to set them the same
  (this would be most useful when "get"ing between same-kind machines,
  say, to set the execute bit).

  ftp> get foomatic
  RETR foomatic
  (file xfer)
  XMOD foomatic
  (sets permission bits on local copy just retrieved)
  ftp>

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

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 12:35:42 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: Can FTP's PC/TCP coexist with MS Win. for WG?

Ian Leveson (ian@zelator.in-berlin.de) wrote:
: I've just tried installing Microsoft's Windows for Workgroups on a PC which
: already has access to a unix server via FTP PC/TCP's NFS utilities. Has
: anyone managed to retain access to the TCP/IP network at the same time as
: connecting the PC to others via Windows for Workgroups?

Yes.

: If so, how?

I installed WfW on a PC which already had PC/TCP and it all worked
together seamlessly - much to my utter amazment.  However, this is
probably because I was already using PC/TCP over NDIS (which WfW
appears to understand).

Email me and I'll try to give real dirty specifics...

Chris
--
          VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858.  Fax +44 532 304676.  Email chrisd@visionware.co.uk
-------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" --------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 14:57:26 GMT
From:      swh@aaahq05.aaa.com (Steven Wayne Hudson)
To:        comp.protocols.tcp-ip
Subject:   FAQ request


Could someone please post a email this group's FAQ?  I would greatly
appreciate it.

---
Steve Hudson                     ///
swh@aaahq05.aaa.com             (0 0)         
-----------------------------ooO-(_)-Ooo---------------------------------


-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 15:15:19 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Networking references

	A few months ago someone posted a great listing of recommended
reading. I misplaced (erased?) it. Any help would be appreciated...

						mvmurphy@attmail.att.com

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 16:47:55 GMT
From:      daved@carbon.forge.tandem.com (Dave Dilena)
To:        comp.protocols.tcp-ip
Subject:   Testing a TCP/IP Implementation


  Hello TCP/IP group:

I'm attempting do determine how to verify my company's TCP/IP implementation.
I would like to be able to establish a dialogue with the System Under Test
and proceed to fragment datagrams into small pieces and verify that our TCP/IP
can re-assemble properly, and perhaps send fragments out of order.  I might
also have the test TCP/IP cause a datagram to be fragmented so I can verify that
the algorithm is correct.   
I'd also like to be able to drop TCP packets, say every 100th packet to 
determine the response to error conditions.  

I've been looking into protocol analyzers and testers, but many don't have the 
programmability necessary to perform some of these types of tests.  Is my only
recourse to build a programmable TCP/IP and use a packet driver on a PC to 
enable this type of dialogue?

HELP!     Thanks, Dave

daved@forge.tandem.com

Tandem Computers Corp.
18922 Forge Dr.
Cupertino, Ca 95014
MS 216-51




-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 17:53:25 GMT
From:      rgallen@muug.mb.ca (Rennie Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing with SLIP

In <CEv86J.o7@csn.org> bff@csn.org (Brendan Forsyth) writes:

>Steven L. Johnson (johnson@tigger.jvnc.net) wrote:
[munch..]

>Getting a registered number for over 50 nodes and then reconfiguring each
>is not a feasible solution.


	1. You do not need to obtain 50 class 'C' addresses.  You already
	   have a class 'C' address, you can assign the host portion of
	   the address as you see fit.

	2. Reassigning 50 addresses is a pain in the butt, but that's why
	   the NIC issues addresses without having to be on the internet,
	   so that when you do go on the net, you don't have to do this.

So reassigning addresses is a feasible solution, it is the only reasonable
solution.

>Once again could we open a discussion of routing and SLIP connections?
>I am sure that I am not the only one experiencing this problem.

The issue you originally raised has nothing to do with routing or SLIP
connections.  Your IP forwarding is working (you saw the packets with your
protocol analyser), you are sending unregistered (and possibly conflicting
addresses) out on the Internet.  This is naughty.

The original followup still stands...

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 34 Riverstone Rd. 
Voice: (204) 339-8005                         Winnipeg, Manitoba, Canada R2V 4B2
Fax:   (204) 488-5943

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 18:01:20 GMT
From:      pkarrer@bernina.ethz.ch (Peter Karrer)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   IP address 224.0.0.5 ?

It seems that our Cisco routers talk to each other sending broadcasts with
a destination IP address of 224.0.0.5 (protocol 89). What is this?

The reason why I ask is that one TCP-IP package (WinQVT/Net 3.93) has
recently started to complain about "invalid destination addresses",
obviously as a reaction to these broadcasts. I'll send a bug report
to QPC software, but I'd also like to include suggestions how to handle
these "invalid" addresses.

So, what's the proper way to do it? Ignore them, or complain only about 
certain 224+ addresses, perhaps those without 0 components?

-- 
Peter Karrer                                   pkarrer@bernina.ethz.ch

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 18:02:53 GMT
From:      MMORSE@nsf.gov (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Telnet to outgoing modem pool

I will be setting up a dial-out modem pool shortly, using a 3Com terminal 
server.  The idea is that PC users will use Telnet to get to the terminal 
server, and from there, connect to one of the modems for dial-out.  

I know this is not an unusual configuration, but I would still like to learn 
from the collected wisdom out there.  Do you have any configuration hints, 
gotcha's etc., you could share?

--Mike

Michael Morse                           Internet: mmorse@nsf.gov
National Science Foundation               BITNET: mmorse@NSF
1800 G St. N.W. Room 401               Telephone: (202) 357-7659
Washington, D.C.  20550                      FAX: (202) 357-7663

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 21:20:43 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Cisco router security

	Is it possible to restrict traffic on Cisco brouters by more than
subnet filters? I need to restrict ftp traffic between two machines between
two machines on two different nets, without completely disabling ftp on 
either. Our security folks say its not enough to retrict with ftp.users.
Any brouter gurus out there??

						Many Thanks,
						Mike Murphy
						mvmurphy@attmiail.att.com

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 1993 21:25:21 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: IP address 224.0.0.5 ?

In article <CEwFE9.Ks8@bernina.ethz.ch> pkarrer@bernina.ethz.ch (Peter
Karrer) writes: 
    It seems that our Cisco routers talk to each other sending broadcasts with
    a destination IP address of 224.0.0.5 (protocol 89). What is this?
    
OSPF

    The reason why I ask is that one TCP-IP package (WinQVT/Net 3.93) has
    recently started to complain about "invalid destination addresses",
    obviously as a reaction to these broadcasts. I'll send a bug report
    to QPC software, but I'd also like to include suggestions how to handle
    these "invalid" addresses.
    
They should ignore them.  

    So, what's the proper way to do it? Ignore them, or complain only about 
    certain 224+ addresses, perhaps those without 0 components?
    
In fact, if you have a decent ethernet adapter, the correct thing to do is
to ignore multicasts that you aren't expecting.  The next best thing to do
is to ignore them based on their IP address...

Tony


-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 22:30:52 GMT
From:      r-beer@onu.edu (Robert Beer)
To:        comp.protocols.tcp-ip
Subject:   Re: Static Arp Tables

In article <29h5sv$dfk@muddy.huber.com>, eddjp@huber.com (Dewey Paciaffi)
wrote:

> I was experimenting with the arp command under AIX 3.2.[2-4]. The
> FM lead me to believe that the "arp -s" command could create a 
> "permanent" table entry. My test showed that if a system with
> a hardware address different from the one in the permanent arp
> entry logged in, the system with the entry would cache the new hardware
> address, leaving the entry marked "permanent".
> 
> Does "permanent" in this case mean "won't be dynamically dropped"
> or "will never change" ? If it's the latter, then my arp is
> broken.

The perm parameter gets you an RARP.

---
Bob Beer, Ohio Northern Univ., Academic Computer Services, Ada, OH  45810
r-beer@onu.edu

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 22:30:55 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: IP address 224.0.0.5 ?

In article <CEwFE9.Ks8@bernina.ethz.ch> pkarrer@bernina.ethz.ch (Peter Karrer) writes:
>It seems that our Cisco routers talk to each other sending broadcasts with
>a destination IP address of 224.0.0.5 (protocol 89). What is this?

OSPF (probably router Hellos) IP multicast.

>The reason why I ask is that one TCP-IP package (WinQVT/Net 3.93) has
>recently started to complain about "invalid destination addresses",
>obviously as a reaction to these broadcasts. I'll send a bug report
>to QPC software, but I'd also like to include suggestions how to handle
>these "invalid" addresses.

These should only be going out on the MAC multicast of 1-0-5E-0-0-5.
If they are being sent to the MAC broadcast, check with Cisco.  If they
are using the the correct multicast, you host software shouldn't see
them, so complain to the host software vendor.

>So, what's the proper way to do it? Ignore them, or complain only about 
>certain 224+ addresses, perhaps those without 0 components?

IP multicasts that are not of interest should be ignored.
>
>-- 
>Peter Karrer                                   pkarrer@bernina.ethz.ch

Art

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 1993 23:01:39 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Cisco router security

In article <CEwoMJ.K9s@cbfsb.cb.att.com> mvm@cbnewsb.cb.att.com (michael.v.murphy) writes:
    	Is it possible to restrict traffic on Cisco brouters by more than
    subnet filters? I need to restrict ftp traffic between two machines between
    two machines on two different nets, without completely disabling ftp on 
    either. Our security folks say its not enough to retrict with ftp.users.
    Any brouter gurus out there??
    
Yes, this is relatively easy.  You want to look at extended access lists.
If you have problems, please contact your appropriate support channel.

Tony



-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 23:03:27 GMT
From:      hunter@Oswego.EDU (Eric Hunter)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for SysVR3 on NCR Tower32

I'm currently running AT&T UNIX SYS V R.3 on an NCR Tower32/650, and to
the best of my knowledge, it does not include TCP-IP.  Would it be possible
to install it, and if so where could I obtain the required software/hardware?

Thanks, (in advance)

Eric Hunter 
-----------------------------------------------------------------------
hunter@oswego.oswego.edu        | Duct tape is like The Force; 
{rutgers}!sunybcs!oswego!hunter | it has a Light Side, and a Dark Side, 
hunter@snyoswva.bitnet          | and it holds the universe together

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Oct 1993 23:23:39 GMT
From:      Dan Lacey <lacey@dsea.com>
To:        comp.protocols.tcp-ip
Subject:   Registering IP Addresses

I would like to obtain my very range of IP addresses. How do I get them?

I assume the NIC, but what is the post office or Email address I use to
get an application?

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 93 01:46:31 GMT
From:      shingo@sy.ssl.fujitsu.co.jp (TISP-Group*Shingo Tanaka(1992))
To:        comp.protocols.tcp-ip
Subject:   Help!!! Host names and Community names


Hi,

  I was wondering if some kindly soul could help me out on a
very basic question. What is the longest hostname and community
name that can be assigned (in terms of number of characters)? 
Is this value machine dependent?
  Any comments will be greatly appreciated.

                                          Thank You
                                        Shingo Tanaka
 
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~I have many opinions but I doubt if my company will share in them and~
~     vice-versa ! Shingo Tanaka at shingo@sy.ssl.fujitsu.co.jp       ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Oct 1993 02:04:28 GMT
From:      bleys@vpnet.chi.il.us (Bleys Ahrens)
To:        comp.protocols.tcp-ip
Subject:   IP Addressing Program/Database

We are looking for a shareware or public domain program we can FTP from
somewhere that will assist us with address assignments for a large
internet created from a class B address.

We would like to be able to plug in our class B address 167.11X
and a default mask of 255.255.255.192 and have the program generate
a flat file or database file with all the acceptable addresses
we can assign with this mask.  Ideally it would have fields for
DNS name of the device and a physical location.

It could run under DOS, Windows, OS/2, Unix or MVS, as we have all
these accessible.  

The IBM rep we had on site seemed to think this type of thing must 
exist someone.

Thanks.

Bleys 

==========================================================================
=   Bleys Ahrens                                             Chicago, IL =
=                        VPNET/Public Access Usenet                      =
=   Information gains value when shared...         bleys@vpnet.chi.il.us =
==========================================================================

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1993 03:52:27 GMT
From:      dhara_s@shu.cs.odu.edu (Sudheer Dharanikota)
To:        comp.protocols.tcp-ip
Subject:   Ip Routing Entry...


Hai,

	This is meant for those who are familiar with ip source
code. I am trying to add a new filed in IRE entry. This field
helps me in maintaining a private linked list.

	Could somebody guess what could make the system crash :-<
if this field is touched in "ire_delete" and "ire_add" routines.

sudheer.

e-mail: dhara_s@cs.odu.edu


-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 93 05:17:17 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip
Subject:   Split Subnet question

Hi,

I've got the following configuration

 Net1 - router1 - Net2 - router2 - Net3
                                 |
                                 + Net4
                                 |
                                 + Net5


Net1 is a class C network with only 4 hosts on it.
Net2 is a class C network with about 70% of the addresses assigned.
Net3, 4, and 5 are very small - half a dozen hosts each.

What I'd like to do is make Net1, Net3, 4, and 5 subnets of the same
class C address.  The problems is that router1 and router2 faithfully
implement RFC 1009 (Gateway requirements) and refuse to route from
Net1 to Net3 because "The distinction of between the subnets of such
a subnetted network must not be visable outside that network."

Is there any way of doing this shy of moving router2 to Net1?

Thanks,

// marc
-- 
// primary:	marc@dumbcat.sf.ca.us	pacbell!dumbcat!marc    
// secondary:	marc@ascend.com		uunet!aria!marc

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1993 06:35:54 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Split Subnet question

In article <1993Oct15.051717.21883@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us
(Marco S Hyman) writes: 
    
    I've got the following configuration
    
     Net1 - router1 - Net2 - router2 - Net3
                                     |
                                     + Net4
                                     |
                                     + Net5
    
    
    Net1 is a class C network with only 4 hosts on it.
    Net2 is a class C network with about 70% of the addresses assigned.
    Net3, 4, and 5 are very small - half a dozen hosts each.
    
    What I'd like to do is make Net1, Net3, 4, and 5 subnets of the same
    class C address.  The problems is that router1 and router2 faithfully
    implement RFC 1009 (Gateway requirements) and refuse to route from
    Net1 to Net3 because "The distinction of between the subnets of such
    a subnetted network must not be visable outside that network."
    
    Is there any way of doing this shy of moving router2 to Net1?
    
Yes, but you need to update your router software and run a routing protocol
that supports discontiguous subnets.  Your alternatives are currently:
OSPF, Integrated ISIS, and RIPv2.

Tony

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 93 13:52:24 MDT
From:      sl88k@mendon.declab.usu.edu (869883 Desai Rutvij Chandrahas)
To:        comp.protocols.tcp-ip
Subject:   How to convert The IP addresses

hi,
	Can any one tell me how can I convert the IP address e.g. 129.123.4.50

to a name string e.g. mendon.declab.usu.edu  and  vice versa.

note : I am looking for the system call that takes either IP address(32 bit) or
	the dotted decimal address and gives the char string.  On my system
	gethostbyaddr() is returning NULL if the entry is not found in /etc/hosts   file. So I am looking for a system call other than gethostbyaddr()
	to do this.

	Send me a mail directly or reply on net.
								Thanks
								rutvij

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Oct 1993 15:13:42
From:      edwin@lard.ftp.com  (Edwin Chow)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Internet Service Providers in LA area

Does anyone know of names/numbers of Internet service providers in the
Los Angeles area?

If so please mail me at edwin@wco.ftp.com

Thanks,

Ed

--
                   ,,,                                ,,,
                  (o o)                              (o o)
______________oOO__(_)__OOo______________________oOO__(_)__OOo______________

Edwin Chow					
FTP Software Inc., West Coast Office		Internet: edwin@wco.ftp.com
785 Market Street, 12th Floor			Phone:    415-543-9001	
San Francisco, CA 94103				Fax:	  415-543-9002	
____________________________________________________________________________
	      (__)     (__)  			 (__)     (__)  


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 93 20:38:44 +0930
From:      xtasc@levels.unisa.edu.au
To:        comp.protocols.tcp-ip
Subject:   Timed, NTP, XNTP ?? The low-down !


Howdy all,

I have a few suns and a load of smaller devices that all support rfc-868? that
I'd like to have time sych'd across the net. With all the discussion about
timed, ntp, xntp etc, Ive been trying to find something to run to keep
everything within a 'reasonable tolerance' :-), like within a minute or
two would be just fine.

Is there an archive site somewhere I can zip off a copy of something straight-
forward to achieve this. I assume this means timed, but Ive never looked into
this area much.

The destination systems are sol 1.1 (os 4.1.3) on ss2's and 10's. I cant find
anything cept rdate on the std dist.

Any help would be appreciated. (pref something _stable_ if poss)

Rob Mayfield
Snr Tech Analyst
Australian Submarine Corporation Pty Ltd.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Oct 1993 18:14:22
From:      fks@lard.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: Can FTP's PC/TCP coexist with MS Win. for WG?

In article <Z44HBVXK@zelator.in-berlin.de> ian@zelator.in-berlin.de (Ian Leveson) writes:

> I've just tried installing Microsoft's Windows for Workgroups on a PC which
> already has access to a unix server via FTP PC/TCP's NFS utilities. Has
> anyone managed to retain access to the TCP/IP network at the same time as
> connecting the PC to others via Windows for Workgroups? If so, how?  I
> suspect that an appropriate network.inf and oemsetup.inf file would help do
> the trick: are such files available?

Currently, you can not use our Windows network driver as a secondary
network driver. The only feature this will prevent you from using is
transparent network printing from Windows applications. Pctcpnet NFS
drives will be available from our network icon, but not from File
Manager. Other than these limitations, the two packages will work
simultaneously.

There are two ways to get PC/TCP 2.2 working with WfW - they can
share an NDIS driver and run side by side, or WfW can run over our
NetBIOS.  For the latter configuration, you will need a 2.22 patch
for NetBIOS.  This is free on request to licensed 2.2 users. Send to
support@ftp.com. 

regards,

--
Frances K. Selkirk		                            support@ftp.com
FTP Software, Inc.       Technical Support            (800) 382-4FTP
--------------------------------------------------------------------


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1993 12:05:43 +0100
From:      mike@horus.mch.sni.de (Mike Hoffmann)
To:        comp.protocols.tcp-ip
Subject:   Simple code example for net-daemon under inetd control needed

Hello!

I'm a newbie to network programming and would like to ask if someone
could provide me with pointers or sources for a simple example
of a server-process that is started under inetd control.

Most books I have here only provide theoretical assistance and the sources
I looked into (like ftpd) are a bit deterring as start-off point.

Thanks in advance for any help you can give!

Cheers
Mike
-- 
Mike Hoffmann - Internet Administrator, Siemens-Nixdorf AG, SNI SU AP 1123
INTERNET: Mike.Hoffmann@mch.sni.de
We don't know where M[ars] O[bserver] is, if it's listening, or if it's capable
of replying. It might not even be transmitting at the expected frequency...
 Sounds like a job for SETI. (u1452@Sdsc.Edu)

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1993 17:54:00 GMT
From:      maf@dunedin.acs.ohio-state.edu (Mark Fullmer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Addressing Program/Database

In article <1993Oct15.020428.21038@vpnet.chi.il.us> bleys@vpnet.chi.il.us (Bleys Ahrens) writes:
>We are looking for a shareware or public domain program we can FTP from
>somewhere that will assist us with address assignments for a large
>internet created from a class B address.
>
>We would like to be able to plug in our class B address 167.11X
>and a default mask of 255.255.255.192 and have the program generate
>a flat file or database file with all the acceptable addresses
>we can assign with this mask.  Ideally it would have fields for
>DNS name of the device and a physical location.

I use a combination of RCS, m4, and Perl to do this.

RCS so that multiple people can edit the database file and mistakes can be
easly backed out.  Perl to do sanity checking --  eg check for duplicate
ip addresses, hostnames, ethernet addresses, etc.  m4 just to avoid clutter --
most machines have the same nameserver, timeserver, etc.  Perl scripts also
generate a bootptab file, readable reports, and some other things.

The scripts are really short, if you want I'll stick them up for anonymous
ftp.

-- 
mark
maf+@osu.edu

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Oct 1993 17:55:52 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing with SLIP

>>> On Thu, 14 Oct 1993 17:53:25 GMT, rgallen@muug.mb.ca (Rennie Allen) said:

In <CEv86J.o7@csn.org> bff@csn.org (Brendan Forsyth) writes:

Forsyth> [ ... I am gatewaying at the IP level between an unregistered
Forsyth> class C network and the internet using a SLIP connection, and I
Forsyth> am having problems. ... ]

Rennie> The issue you originally raised has nothing to do with routing
Rennie> or SLIP connections.  Your IP forwarding is working (you saw the
Rennie> packets with your protocol analyser), you are sending
Rennie> unregistered (and possibly conflicting addresses) out on the
Rennie> Internet.  This is naughty.

It's not just naughty: if your internet access point provider catches
you gatewaying at the IP level between an unregistered network anddd the
internet they might well (and should!) terminate your connection with
great prejudice. It is a condition of the use of the internet at all
levels that all IP addresses be registered and therefore unique.

Forsyth> Getting a registered number for over 50 nodes and then
Forsyth> reconfiguring each is not a feasible solution.

If you think getting a registered C class address and renumbering 50
machines is unfeasible, too bad for you (and your organization). You
will have to choose one of the following:

	* stop gatewaying at the IP level between your unregistered
	  network and the internet.

	* have your SLIP connection terminated by your access point
	  provider as soon as they catch you.

	* setup your gateway machine as an application level gateway
	  (a so called firewall), where local users log into it and
	  then from it use internet services.

I am afraid that there are the _only_ really feasible choices.

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 93 19:02:20 GMT
From:      luce@dunk.ccit.duq.edu (Douglas Luce)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP Numbers

Dewey Paciaffi (eddjp@huber.com) wrote:
: We have an environment mix of IBM workstations/servers and PCs,
: in a wide area Internet. Recently we've seen an increase of PCs running 
: TCP/IP. Along with this increase has come an alarming number of 
: duplicate IP addresses being configured into the PCs. The PCs hang
: until the situation is cleared up, of course. We are also able to
: make workstations and servers hang using PCs. Some people here are
: understandably distressed about this. My question is how are others 
: in this type environment dealing with this issue, be it malicious or
: innocuous in intent. 

We've not implemented a plan here at Duquesne, but here's what I had
in mind:

We have nearly 20 buildings on campus, each with their own Ethernet
backbone.  Each of these building have been assigned a subnet, and each
has their own port on an IP router.  Just doing this will help a bit,
since for duplicate IP addresses to be a problem, they both have to
occur within the same building.  If someone chooses an arbitrary IP
number, they won't affect anyone outside the building, and if they
don't choose it within the building subnet, they really won't harm
anyone at all.

Of course, this doesn't get the machine working.  It's likely that a
person may try several different numbers until one works (one that's
in the building subnet).

Part of this is grounded in policy: how do people get their networking
software?  How do they set it up?

The plan here is to distribute TCP/IP disks from our computer store.
People who want to get on the network will call us or the store up,
and we'll get them the proper disks.  When they start up from these
disks, the first thing that happens is one of:

1) An ARP request is put out, and an ARP server on the ethernet will
   give out addresses on a dynamic basis,

2) the user will be queried as to his/her location on campus, and a
   IP address from a small block (2-3) of special configuration IP
   addresses are chosen.

Once a PC has it's temporary IP number, a central server is contacted.
A dialogue ensues between the PC and the server, and the user is asked
the standard info.  This info is put into a form and shipped to an
administrator, and an IP address is automatically allocated and given
to the PC.  Immediately, the  PC is up and working with a properly
allocated IP address.  The info is checked by hand, and the DNS
records updated to give a proper hostname, and the info files in the
proper place.

Of course, if someone gives bogus information, they shouldn't get that
IP address.  I'm not too sure what to do in this case, but perhaps
leave that IP address alone until we locate the person who gave us the
bad info and set them straight.

How are things done at your site with respect to getting people up on
the network?  Or is this a malicious problem you're dealing with?

Doug Luce
Duquesne University CCIT

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Oct 93 19:37:57 GMT
From:      li@leopard.nlm.nih.gov (Tin Li, Century Computing, ITB)
To:        comp.protocols.tcp-ip
Subject:   winsock, pcnfs, and pcnfs toolkit

Our software are currently using pcnfs 4.0 and the library tklibw.lib that 
come with pcnfs toolkit 4.0  We are in the process of moving to pcnfs 5.0 and
changing our application to use winsock.  The question is do I still need the pcnfs 
toolkit since pcnfs come with a winsock dll and the required header files?
Have anyone tried the winsock dll in pcnfs?  Any pointers will be appreciated.

Thanks.

Tin Li
National Library of Medicine 
National Institute of Health
Bethesda, MD

li@nlm.nih.gov



-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1993 21:54:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Simple code example for net-daemon under inetd control needed

In article <29m067$afn@horus.mch.sni.de> mike@horus.mch.sni.de (Mike Hoffmann) writes:
>I'm a newbie to network programming and would like to ask if someone
>could provide me with pointers or sources for a simple example
>of a server-process that is started under inetd control.
>
>Most books I have here only provide theoretical assistance and the sources
>I looked into (like ftpd) are a bit deterring as start-off point.

Inetd is described in section 6.16 of "Unix Network Programming" by W.
Richard Stevens.

Basically, inetd automatically does the bind(), listen(), and accept() for
you, and then runs the server program in a child process.  When your server
is started, the accepted socket is connected to fd's 0, 1, and 2 (stdin,
stdout, and stderr).  So if you have books on writing non-inetd servers,
just ignore the stuff about the above system calls, and look at the parts
of the examples after the socket has been accepted.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Oct 1993 22:49:22 GMT
From:      wgoodman@cbnewsm.cb.att.com (walter.h.goodman)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.admin,comp.unix.sys5.r4
Subject:   Lachman TCP/IP over STARlan10...PLS HELP.




	People of the Net,

	I have a 486 EISA machine running SVR4.0.3 (Consensys) with
	STARlan Lan Manager and a STARlan10 network card.  I would 
	like to configure TCP/IP over this card.  Unfortunately the
	TCP/IP that I have is the version created by Lachman Associates,
	Incorporated (LAI) not the WINTCP that AT&T sells.  I am having
	some difficulty configuring this TCP/IP over my STARlan10 NAU.
	Does anyone out there have any experience configuring the 
	Lachman brand of TCP/IP over a STARlan10 card?  Can it be done?
	I have my system up enough that I can ping myself, but no other 
	hosts on our net. (doesn't do me much good to be able to rlogin
	to myself ;-/)  

	Any assistance will be much appreciated.


	Walter H. Goodman
	AT&T IMS, Kansas City
	wgoodman@cbnewsm.cb.att.com

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Oct 1993 05:01:41 GMT
From:      vances@xenitec.on.ca (Vance Shipley)
To:        comp.protocols.tcp-ip
Subject:   Interface Based Routing


I have been experimenting with the KA9Q routing software for use
in our local MAN project (KWNet).  I have been trying to take
advantage of the software's ability to do interface based routing
which allows me to use the C Class IP network space we have been
allocated very effectively.  We currently have several routers
which each have only one IP number.  Each machine with a route to
one of these routers uses the same IP number in it's routing tables.

This has so far worked out very well.  Hosts attaching to a router
are allocated one of KWNet's numbers if they have no network of their
own.  If they do we encourage them to use one of their own numbers
for the interface.  With this arrangement we have been able to avoid
subnetting the C Class and only use up a number when we add a host
which does not have it's own IP network.

I am very happy with this arrangement and am favouring using a KA9Q
based package for this reason alone.  Despite this a number of our
group are very suspicious of this capability describing it as "strange"
or even "illegal".  I have yet to see anything which proves that this
method of "interface based routing" breaks any standards, RFCs, etc.

So I am soliciting comments.  Is "interface based routing" "illegal"?
Is it undesirable?  Or is it, as I feel, what should have been done
all along?

-- 
Vance Shipley, vances@xenitec.on.ca 

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Oct 1993 11:43:10 GMT
From:      xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   pdclk207.zip - Network tester & sets PC clock from LAN t-serv


I have uploaded to the SimTel Software Repository (available by anonymous
ftp from the primary mirror site OAK.Oakland.Edu and its mirrors):

pub/msdos/pktdrvr/
pdclk207.zip    Network tester & sets PC clock from LAN t-serv


PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.
It can use BOOTP to get IP number and other info.  PDCLKSET talks to the
network card via a packet driver (using ODIPKT or DIS_PKT you can run it
over ODI or NDIS too).

PDCLKSET can assign the proper normal or summer time timezone name to
an environment variable (TZ is used by most systems).


There is also a very powerful built in ping/echo client and server
giving important statistics on delay, load and packet loss. It can even
load a network to the full Ethernet bandwidth.  It can be used to stress
software and hardware components such as driver routines, routers,
bridges, repeaters, Ethernet cards and transceivers.


The PDTBUILD program, which is included in the ZIP package, looks at all
ARP broadcasts and generates hardware address tables with all the IP
hosts on this (sub)net.  It detects IP and hardware address duplication.


And still, PDCLKSET is so small (14 KB) you can use it even on diskette-
only PCs.


Version 2.07 of the PDCLKSET package has the following new features
compared to the 1.52 version, making it still better for network load
testing and detecting beginning component failures:

- On a VERY loaded network the ping server could run out of buffers
  (indicated by a number between packets received and diff). The code
  has now been rewritten to use far addresses for buffers and the buffer
  pool is now 300+ full size buffers as compared to 27 on 1.x versions.

  Using a good packet driver (e g the coming/new smc_wd ver 11.x) and with
  a server that is faster than the client, there should be zero packet loss
  due to software; so one can clearly see how the hardware performs.

- During pinging, packet loss is computed differently so packets in
  transit are not counted as loss. This gives a more true and stable display.

- Code optimizations has given a throughput increase of about 50 - 70 %,
  a 20 MHz 386 can load the net to 9.9 Mb/s using full length packets and a
  33 MHz 386 can load to 1/3 Ethernet capacity using minimum length packets.

- The interval parameter may have a decimal point and one decimal digit
  (more natural than the flag=32 mechanism in 1.x versions).

- A new min-size parameter can override the 34 bytes default minimum size
  when doing packet size sweep.

- Table building now looks at IP broadcasts in addition to ARP broadcasts.

- Added special handling for true SLIP and Token Ring (untested,
  no source routing).

- Flag=4096 enables IP sizes up to 4082 (for Token Ring, but also
  requires changes to the IBMTOKEN packet driver, unless true TR works).

- Echo interval algorithm changed to be more accurate and CPU speed
  independent.

- Some minor bugs fixed (and probably new ones introduced).

There is no functional change regarding setting the PC clock from the net.


Jan Engvald, Lund University Computing Center
________________________________________________________________________
   Address: Box 783                E-mail: Jan.Engvald@ldc.lu.se
            S-220 07 LUND     Earn/Bitnet: XJELDC@SELUND
            SWEDEN            Span/Hepnet: Sweden::Gemini::xjeldc
    Office: Soelvegatan 18         VAXPSI: psi%2403732202020::xjeldc
 Telephone: +46 46 107458           X.400: S=Engvald/G=Jan/O=ldc/
   Telefax: +46 46 138225                  PRMD=lu/ADMD=sunet/C=se
     Telex: 33533 LUNIVER S

_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458   Telefax: +46 46 138225   Telex: 33533 LUNIVER S
E-mail: Jan.Engvald@ldc.lu.se
X.400:  G=Jan/S=Engvald/O=ldc/PRMD=lu/ADMD=sunet/C=se

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 1993 02:42:02 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Registering IP Addresses

In article <1993Oct14.232339.19323@dsea.com>, Dan Lacey <lacey@dsea.com> wrote:
>I would like to obtain my very range of IP addresses. How do I get them?
>I assume the NIC, but what is the post office or Email address I use to
>get an application?

You could get the application form via anonymous FTP from
ftp.rs.internic.net:netinfo/internet-number-template.txt ,
or via e-mail from <hostmaster@internic.net>, or by phoning
the NIC at 800-444-4345 or 703-742-4777.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>



-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Oct 1993 15:18:35 GMT
From:      RINDFUSS-S@medea.wz-berlin.de (Peter Rindfuss)
To:        comp.protocols.tcp-ip
Subject:   SLIP and BOOTP

I'm using cslip-2.6 as a slip server on our Sun Sparc 2. I would like to 
configure the system in such a way that the bootpd daemon can respond
to bootp requests from the slip line. Bootpd gets the requests from the 
slip line, but it can't answer them because there is no hardware address
it can reply to. Does anyone have an idea how this could be established?



-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Oct 1993 15:41:01 GMT
From:      pkarrer@bernina.ethz.ch (Peter Karrer)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: IP address 224.0.0.5 ?

art@acc.com (Art Berggreen) writes:

>In article <CEwFE9.Ks8@bernina.ethz.ch> pkarrer@bernina.ethz.ch (Peter Karrer) writes:
>>It seems that our Cisco routers talk to each other sending broadcasts with
>>a destination IP address of 224.0.0.5 (protocol 89). What is this?
 
>OSPF (probably router Hellos) IP multicast.
 
>>[...]
 
>These should only be going out on the MAC multicast of 1-0-5E-0-0-5.
>If they are being sent to the MAC broadcast, check with Cisco.  If they
>are using the the correct multicast, you host software shouldn't see
>them, so complain to the host software vendor.
 
>>[...]

Here's a KA9Q trace:

Sat Oct 16 15:42:15 1993 - tok recv:
Ether: len 82 40:00:00:76:15:00->ff:ff:ff:ff:ff:ff type IP
IP: len 68 193.5.187.33->224.0.0.5 ihl 20 ttl 1 tos 192 prot 89
 ....

If I understand you correctly, this should be addressed to 01:00:5e:00:00:05
and not to ff:ff:ff:ff:ff:ff?!

This might be a configuration error on our side; we have just recently
switched from source routing bridges to Cisco routers. (BTW, "we" != ETHZ.)
Or perhaps the fact that it's a Token-Ring network makes the difference...
(Does Token-Ring support the concept of multicast?)

-- 
Peter Karrer                                   pkarrer@bernina.ethz.ch

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 1993 20:34:28 GMT
From:      kevin@cassandra.ucr.edu (Kevin Lund)
To:        comp.protocols.tcp-ip
Subject:   Help needed with routing table interpretation

I'm trying to run PPP from a Sparc LX to a mac; the PPP link comes up,
but no network traffic comes across it...so I'm looking at the routing
tables, and here's what I get:

[much deleted]

138.23.106.0         138.23.146.1          UG       0      0
198.102.62.0         138.23.146.3          UG       0      0
134.24.0.0           138.23.146.3          UG       0      0
138.23.146.0         138.23.146.195        U        3   4683  le0 <--*
224.0.0.0            138.23.146.195        U        3      0  le0
138.23.146.111       138.23.146.195        UH       2      0  dp0 <--*
default              138.23.146.3          UG       0      0

Now, the machine I'm trying to get packets to is 138.23.146.111 (the
one on the other side of the dp0 interface).  However, there is an
entry, earlier, for all of 138.23.146.*, which specifies interface
le0.  My question is, when there's a packet destined for 138.23.146.111,
will the routing table get searched in the order given here (as dumped
by netstat), thus sending the packet out the wrong interface?  If
so, how can I reorder the table?

If not, anybody have PPP going between a Solaris machine and a mac?

Thanks,

    Kevin Lund (kevin@cassandra.ucr.edu)

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Oct 1993 22:14:12 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: IP address 224.0.0.5 ?

In article <CEzy8D.F05@bernina.ethz.ch> pkarrer@bernina.ethz.ch (Peter Karrer) writes:
>art@acc.com (Art Berggreen) writes:
>>These should only be going out on the MAC multicast of 1-0-5E-0-0-5.
>>If they are being sent to the MAC broadcast, check with Cisco.  If they
>>are using the the correct multicast, you host software shouldn't see
>>them, so complain to the host software vendor.
 
>>>[...]
>
>Here's a KA9Q trace:
>
>Sat Oct 16 15:42:15 1993 - tok recv:
>Ether: len 82 40:00:00:76:15:00->ff:ff:ff:ff:ff:ff type IP
>IP: len 68 193.5.187.33->224.0.0.5 ihl 20 ttl 1 tos 192 prot 89
> ....
>
>If I understand you correctly, this should be addressed to 01:00:5e:00:00:05
>and not to ff:ff:ff:ff:ff:ff?!
>
>This might be a configuration error on our side; we have just recently
>switched from source routing bridges to Cisco routers. (BTW, "we" != ETHZ.)
>Or perhaps the fact that it's a Token-Ring network makes the difference...
>(Does Token-Ring support the concept of multicast?)

Ah, Token Ring.  I had assumed Ethernet.  Token does have the concept
of multicast, but usually "functional address" (a subset of multicast)
is used for these types of functions.  The above multicast on TR would
be bit reversed and read as 80:00:7a:00:00:a0.  Off the top of my head,
I don't remember if IP multicast has a defined TR functional address,
so I can believe that it might show up using the ff:ff:ff:ff:ff:ff
broadcast.

At any rate, your host should be ignoring these.

Art


-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Oct 1993 12:27:14 GMT
From:      samson@china8 (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   INETD fork procedure!?

Hi,all,
	Sorry, it's me again...
	I'd like to know whether the inetd fork procedure below is
correct or not!

	inetd find a connection
		|
 inetd check the port
		|
 inetd accept that connection
		|
 inetd dup the connection to stdin/out
		|
 inetd fork
		|
	inetd transfer control to another program charge for that port

	I don't know if this question is a dumb one. Anyway, thank you
for reading it.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Samson Chen
at C.H.P.I., Hsin-Chu, Taiwan.
e-mail: samson@chpi.edu.t

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 1993 18:29:20 +0100
From:      Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel)
To:        comp.protocols.tcp-ip
Subject:   Socket stuck as "CLOSING"

Some really bad TCP implementations (like in AIX 3.2) won't close
sockets if they don't get the final ACK or some of the last waited
datagram, which offten happens with crashing machines.

Those bad implementations keep the sockets definitely in a bad shape:

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  134.214.100.25.70      152.3.102.1.4077       TIME_WAIT
tcp        0    126  134.214.100.25.20      128.186.41.102.55969   CLOSING
tcp        0  16384  134.214.100.25.70      138.253.241.52.2912    LAST_ACK
[hundreds of lines ommitted]

Desperate from getting the vendors fix their software, do I have
a way to send to "shit" into the TCP layer to have those sockets
closed.

The ICMP unreachable does not work (even for normally active sockets) as
IBM decided not to follow them.  Could sending RST, FIN or I don't know
what help finishing the handshaking.  Another issue is that I have
no idea on the expected values for Ack, Seq, ...

Fortunately AIX's kernel does have raw IP sockets which allow the
user to specify the complete IP header (and fake easily the source address).

-- 
  vive les calories

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Oct 1993 01:25:41 GMT
From:      simon@lsupoz.apana.org.au (Simon Rumble (Shermozle))
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general
Subject:   Re: Looking for alternative to pc-route...

Seems like on Wed, 13 Oct 1993 15:03:35 GMT Christoph Weber-Fahr [KIT] said:
 
: >BTW why not take one of the free Unix versions ? Linux ? NetBSD (or what 
: >they call it this week) ?
 
: That question seems to remain unanswered.

Well the problem is, we're talking about Toasternet here.  We want
to repurpose old, obsolete and, importantly, cheap techology such as
XTs, 286 machines etc.  PCRoute is good at this.  You really shouldn't
need that much oompf for a maximum of 4 serial ports (although the
I/O could be a problem).
-- 
//___/////////////////////////////////////////////////////////////////////////
/|___          "What's the point of a revolution without general copulation?"/
/ ___| H E R M             simon@lsupoz.apana.org.au                         /
//////////////////////////////////////////////////////////////////////////////

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Oct 1993 01:29:02 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip
Subject:   Re: problems with large packets on UDP

In article <29dob9INN1na@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
>In article <29clcp$2v5@smurf.sub.org> urlichs@smurf.sub.org (Matthias
>Urlichs) writes:
>
>    If I were you, I wouldn't send one large UDP packet and let the IP
>    layer split it -- split it yourself, say to 8k or so (same as NFS...).
>    That way you receive bits and pieces of your picture, enabling you to
>    keep old picture fragments around in case a packet gets lost. If that
>    happens to your big UDP packet, the whole picture gets tossed when the
>    kernel times out (which can be a few seconds).
>
>In fact, if you can fragment your data yourself, it's much better to send
>path MTU sized datagrams.  NFS is not a particularly good model, as those
>8k packets do get fragmented.  Any loss of a single fragment implies
>retransmission of all fragments for that packet.

Why is it better to fragment your data into MTU-sized datagrams?
Is this always true, or only if you are retransmitting a lot?
How much better is it? Do you have any references I can look up?

I have heard people say this before, but my experimentation gives
me the opposite answer. I am working on a project where we want to
send very large files to many hosts on a LAN at once. In order to
simplify the one-to-many communication, we use multicast (if
available) and broadcast; thus, we must use UDP.
When we benchmarked our protocol for various packet sizes,
we found that the larger the packet size, the better our throughput.
We figured this was due to minimizing system calls; we just hand an
8K packet to the kernel, and let it take care of fragmenting it.
(of course, we can't use 8K packets when broadcasting)
By the way, we only end up retransmitting < 5% of all packets.

Our conclusion: system calls are expensive, so minimize them.
--
Steve Kotsopoulos  P.Eng.           mail:   steve@ecf.toronto.edu
Systems Analyst                     bitnet: steve@ecf.UTORONTO.BITNET
Engineering Computing Facility      uucp:   uunet!utai!ecf!steve
University of Toronto               phone:  (416) 978-5898

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Oct 1993 02:02:35 GMT
From:      eel@grunge (Elena Leong)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Location of gated

Hi,

the subject says it all, I need an ftp source for gated, preferably in Australia
Please mail me a reply if possible, because I dont read news that often.

Thanks,
Elena.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 1993 02:51:17 GMT
From:      riddler@seas.gwu.edu (Sageev George)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.novell
Subject:   SLIP routing software that can login w/ password ?


We are getting a SLIP connection to get our network on the Internet.
We had planned to use Wollongong's WIN/Route (very old package we had
lying around) to provide us with the SLIP routing (i.e. a PC running
this, with our thin-net Ethernet card and SLIP modem connections,
routing betwixt the two).  However, after reading the WIN/Route docs
and talking to our SLIP provider, I don't thik this will work because
the SLIP router must login to the providers machine with a userid and
password.

Thus: I need some type of software that I can run (on a PC pref. but
on our Sun if necessary) that can dial up to our SLIP account, log in
and do the SLIP nasty.

If anyone knows of any such software, PD or commercial (obviously PD
is preferred :), please let me know.

Thanks for any info.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 1993 12:07:41 GMT
From:      gpalmer@cs.strath.ac.uk (Gary J Palmer C.S.3)
To:        comp.protocols.tcp-ip
Subject:   gethostbyname()

I am writing a program that looks up a host (either by
gethostbyname() or gethostbyaddr()), and I want to
find out all the aliases for the host. But using those
two system calls, I only get *one* alias for the host, 
and only if I specify the alias as the host to find.
Using the gethostby*() system calls is it possible
to find all the aliases? I am running Sun4.1.1 on a 
Sparc ELC, with DNS set up in /etc/resolv.conf.

Thanks

Gary

-- 
JANET		: gpalmer@uk.ac.strath.cs
Other Nets	: gpalmer%cs.strath.ac.uk@ plus one of :-
BITNET: UKACRL     UUCP: ukc.uucp    Internet: nsfnet-relay.ac.uk
#include <std.disclaimer> | Ah... f**k ... NT has been released :-(

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Oct 1993 14:07:21 GMT
From:      zaitcev@ipmce.su (Pete A. Zaitcev)
To:        comp.windows.x.motif,comp.protocols.tcp-ip
Subject:   Re: HELP -- Chat - like program

In <29uveuINN190@srvr1.engin.umich.edu> fjl@led.engin.umich.edu (frank james lagattuta) writes:

> I am trying to create a program which enalbles a networked user to talk to 
>another networked user through headsets and microphones via the network 
>connection.

I am doing the same, but VER-RY slowly. I am very busy on the main work.
This theme becomes hot! A couple of months there was a discussion in
the comp.sys.sun.misc under the subject "audio talk between the sparcsta-
tions". This theme is also unfolding in the our local group
relcom.fido.ru.unix.

I think that we will face the compatibility problem soon. Someone should
establish the standard about the bidirectional transmission of sound data
over the IP. The RFC-1256 seems for me not to be suitable. It's targeted
on the broadcast transmission.

I use now the protocol from the John Walker's NetFone. It's too unsecure
and consume the extra bandwidth because of uLaw format being used in it.
Can somebody suggest anythig better? Yes, I can say "ADPCM", too :-)
But the complete protocol must include signaling capabilities and
other important things.

Please send any responces to me. I will post edited summary.

Pete

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Oct 1993 02:05:00 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Newbie needs a dummy.net IP address

In article <1993Oct27.183300.29959@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
>...
>>I'd like to set up an internal network (never seen outside the corporation)
>>and use a dummy, Class B address.  Then I can reserve my precious NIC-legal
>>Class C addresses for hosts that actually connect to the Internet.
>
>Sorry, it's not allowed. There's no way under current network software
>to make this work, unless you keep it physically isolated as well--as
>in passing email to and from it via a uucp link. Otherwise, you'll never
>get it to work reliably.
> 
>>I asked Hostmaster at Internic if there was a "test" or "experimental" IP
>>address, guaranteed never to be issued, and learned that there is none.

Hostmaster at Internic was wrong or was misunderstood.
Check 192.0.2 in Assigned Numbers.  192.0.2 was long ago designated for
exactly such uses by Jon Postel in response to my request.

>>How do I randomly pick a dummy Class B address for internal use only that
>>won't conflict with real-world addresses?
>
>There *aren't* any dummy class B addresses!

Nets 89 and 10 would serve well enough as dummy class B's for a long time,
because of different but similar histories.

Furthermore, given the officially sanctioned dummy test class C, 192.0.2,
you can build a pair of MX forwarders that would pass mail between the
Internet and an internal hidden currently actively used class B (e.g. 16),
and not have to use UUCP.


Vernon Schryver    vjs@rhyolite.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 1993 16:33:16 -0400
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP's PC/TCP MS Win. Printing woes

luce@dunk.ccit.duq.edu (Douglas Luce) writes:

>Okay, I've got a Postscript printer on my NeXT, and the latest and greatest
>PC/TCP from FTP software.  I want to print to this printer from the PC in
>my office under MS Windows.
> 
>So I install it.  Straightfoward; it works with my Ethernet card and all,
>allows me to point a queue at an lpd on my NeXT.  Everything works; NFS
>mounts great, I can FTP/Telnet.  Fine.  I print; data gets to the printer,
>but it's raw Postscript code.  At the top of the job is a mysterious 
>line: \004!%PS-Adobe
 
>Wow, I think to myself, I know exactly what this is: the Ctrl-D hack in
>Windows (I assume to attempt to flush any pending job from the printer).  
>Even better, I know the solution: find the part in my WIN.INI that says
>[Postscript, LPT1] and put a CtrlD=0 in there.  It even reiterates this
>in the MS-Win readme file.  Cool enough.
 
>So I do it.  To no effect.  FTP's tech support (on preliminary investigation)
>has no palpable clue.  
 
>Am I missing something?  Has anyone else been in this bind, and sounded out
>the brain damage?
 
>Thanks,
 
>Doug Luce
>Duquesne University CCIT

i do something similar on sco boxes.  the trick is to tell the printer
interface that all jobs from the pc are "graphics", in other words this
is a binary file which should be dumped to the printer port as is without
adding anything on the from er backup.  most unix interfaces will try
to set up the printer before sending the presumably text job.  you may
have to send the pc print jobs to an alias which is really lp -og printer
not sure how the next deals with this.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 93 16:27:25 GMT
From:      baker@oasys.dt.navy.mil (James Baker)
To:        comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   Re: Windows for Workgroups over TCP/IP



    You can get it from Microsoft for $49.00.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Oct 1993 20:48:59 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect security?

In article <1993Oct28.200822.22455@aston.ac.uk> evansmp@mb48059.aston.ac.uk (Mark Evans) writes:
>...
>: Gateways (routers) don't listen to ICMP redirects exactly for this (and
>: other) reasons.
>
>A machine sould check the source address against its routing tables.
>So that it only accepts redirects from a gateway it is using, many machines
>appear not to bother checking, thus can be spoofed.


No one who cares about security puts much faith the IP source address of
an ICMP packet or any other IP packet.  If you can forge the rest of the
contents of an ICMP packet, you obviously can forge the source address
and, if necessary, some source routing.

Even checking the MAC source address is no protection against evil on the
local wire, and depending on the gateway and what it does about source
routing and whether the target notices source routes, no protection against
remote bad guys.


Vernon Schryver    vjs@rhyolite.com

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Oct 1993 02:49:15 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ping's maximum packet size

In article <fred_sCFq1oM.E9H@netcom.com> fred_s@netcom.com (Frederick Scott) writes:
>ctkosti@afterlife.ncsc.mil (Chris Kostick) writes: 
>>
>>On a Sun (SUNOS 4.1.3) I tried
>>
>>	$ ping -s afterlife 2048
>>	PING afterlife.ncsc.mil: 2048 data bytes
>>	sendto: Message too long
 
> ...
>I don't think the problem is with sendto().  What kind of network are you
>pinging on?  An ethernet network has a maximum packet size of 1518 bytes,
>...

The Ethernet (not 802.3) MTU is 1500 bytes of IP (including ICMP) packet.

>Anyway, the point is, I don't think there's any way you can convince SunOS
>to fragment your ping packet on the local network.  You're stuck with the
>maximum packet size. ...

Only with some systems.
Other UNIX systems with TCP/IP from 4.3BSD or newer allow ICMP ECHO
Requests and Replies to be fragmented.  Besides some systems sold
by hardware vendors, BSDI's BSD386 works:

    ] PING 192.48.190.8 (192.48.190.8): 5000 data bytes
    ] 5008 bytes from 192.48.190.8: icmp_seq=0 ttl=255 time=26.102 ms
    ] 5008 bytes from 192.48.190.8: icmp_seq=1 ttl=255 time=25.211 ms
    ] 5008 bytes from 192.48.190.8: icmp_seq=2 ttl=255 time=25.127 ms
    ] 
    ] --- 192.48.190.8 ping statistics ---
    ] 3 packets transmitted, 3 packets received, 0% packet loss
    ] round-trip min/avg/max = 25.127/25.470/26.102 ms


Vernon Schryver    vjs@rhyolite.com

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 93 19:51:16 GMT
From:      razvan@bsu-cs.bsu.edu (Razvan G. Herdea)
To:        comp.protocols.tcp-ip
Subject:   ignore

ignore , test

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1993 11:36:29 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   Re: SUMMARY: Searching for WAN simulator 'black box'

In article <1993Oct29.133934.6154@jts.com> jimc@jts.com (Jim Carroll ) writes:
>
>In summary, there isn't a lot out there to choose from.  No recommendation
>at this point.
>
 
    If  you really want to simulate the WAN for various international
    connections, try the Telecom Analysis Systems units.  They have a
    competitor with the initials PTT, but I can't recall the full
    name.

    The TAS-1010 emulates a telco network...complete with delays,
    attenuation, echo, phase shift, phase hits, gain hits,
    equalization errors, etc. etc. etc. All of these parameters are
    under user control.  

    It is really designed for testing modems, but it can create the
    latency and delays of the telco network if that is what you need.
    It (and the PTT unit) is a telco channel simulator....with preset
    configs for "typical" good, bad, and ugly samples of various phone
    lines from various telco's around the world. 

    The LPCOMM TC-2000, HP-IDACOM, and Wandel & Goltermann DA-30 can
    all emulate the protocol but you'd have to know telco effects very
    thoroughly and their effect on the link levels to use one of
    those.

    If you can't find the address of TAS, post on the modem and
    telecommunications newsgroups...most modem vendors use the TAS
    for designing modems.



-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 93 03:27:40 CDT
From:      rsl11@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Questions for QVTNet 3.93 and 3.94

Hello there,

	I have the following questions about QVTnet for Windows:

1. In the file qvtnet.ini in the [nntp] section what do you need to put
for the 
		
		posthdr_distrib= option? I guess for USA you put 'usa'. 
what do you need to put for Interneational? Whatis 'na' stand for? what if you
leave this option blank?

2. Is it possible to save the file news.rc to another directory other than
c:\qvtnet?

3. Do you need to exclude the frame where the packet driver say wd8003e.com is
loaded form the Windows memory using the emmexclude statement? In other words,
if wd8003e.com is using the RAM frame cc00-cfff i.e.

	wd8003e  0x7e 10 0x300 0xcc00

do you need to put the statement 

	emmexclude=cc00-cfff

in the [386Ench] section of the system.ini  file?

4. What are the new features of QVTNet 3.94?

	I would appreciate any relevant response.

Please E-mail: rsl11@kuhub.cc.ukans.edu

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Oct 1993 23:24:56 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding hop-counts

In article <SHIRONO.93Oct31160905@gcx1.ssd.csd.harris.com> shirono@ssd.csd.harris.com writes:
>...
>The Berkeley routing table does not keep hop counts.  They are irrelevant
>to actual packet routing.  Hop counts are relevant only to distance-vector
>routing protocols, such as RIP.  Berkeley's routed(8) implements RIP.
>Other routing daemons for BSD-based networking do so as well (e.g. GateD).
>I don't know if there is a way to get them to print their internal tables.

Some workstation vendors ship something derived from the "query"
command associated with the primordial RIP daemon, 4.*BSD routed.

For another example, the query.c found with BSD386 1.0 says things like:

    44 bytes from localhost(127.0.0.1):
	(af 0) 0 0 0 0 0 0 0, metric 15
	(af 0) 30c0 be 0 0 0 0 0, metric 1

I think recent versions of Cisco's code respond to the queries generated
by `query` or `rtquery`.


Vernon Schryver    vjs@rhyolite.com

END OF DOCUMENT