The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 Nov 1992 18:26:13 GMT
From:      ashah@eos.ncsu.edu (AJAY  SHAH)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.tcp-ip.ibmpc
Subject:   TEST ...

Test Test Test ...



-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 Nov 1992 21:52:23 GMT
From:      dberry@csa.cs.technion.ac.il (dberry)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Connecting DEC Vax clusters with IBM SNA networks

We are looking for a gateway that will allow a variety of applications
including databases and file servers access to work accross a network
consisting of a number of Vax clusters, IBM mainframes and Token-Ring LANs.
The connection is accross X.25 WAN. It seems that having a gateway between
the VAX world and the SNA world will be of help. What manufacturers are
making such gateways?

Thanks, Orna
-- 
Prof. Daniel M. Berry, Computer Science Department, Technion, Haifa 32000 ISRAEL
Tel:+972-4-294325, Bitnet:DBERRY@TECHSEL
Csnet & Internet:dberry@sel.technion.ac.il

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 92 02:27:18 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   new Harvard performance numbers

fyi - the results of the new round of Harvard router performance tests
are now on-line.  Pictures to follow "soon"

Scott

Machine:	hsdndev.harvard.edu (128.103.202.40)
Directory:	pub/ndtl/results 

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 04:38:47 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirects

In article <don-301092144034@nocmac.cis.brown.edu> don@bodovipa.cis.brown.edu (Donald Wright) writes:
>When doing a 'netstat -rn', redirects often show up with the flags UGHDM. 
>I have been unable to find any documentation on what the "M" stands for. 
>Does anyone have a clue ? 
>
>Don Wright, Network Systems Specialist    
>Brown University, Providence RI
>Internet: Donald_Wright@Brown.EDU
>Phone:  (401) 863-7405
>*** Talk is cheap, words plentiful, and deeds precious - Ross Perot ***

	It stands for multiple. i.e. you have been redirected and then
	redirected again.

	If you look an <net/route.h> you will see a flag bit
	RTF_MODIFIED which indicates that it has been modified be a
	redirect rather than created be a redirect.

	Mark.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 11:07:26 GMT
From:      geertj@ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>The Sun idea is to use the standard stuff to see if ypbind is
>registered with the port mapper.  Using TCP does mean a socket is left
>in TIME_WAIT, but it also means that an answer is returned
>immediately.

While waiting for SUN to come up with a solution (solaris 3.x maybe?)
a workaround might be to make the domainname of your system EMPTY.
By default, if you don't set your domainname and don't use Yellow 
Plague, the install program sets it to 'noname' or such.
Just changing that to an empty string killed the huge amount of
TIME_WAIT calls here.

The easiest way to do this is to edit /etc/defaultdomain (sunos 4.1.x)
and make it empty.

Hope this helps,

Geert Jan


--8<--nip-nip---------------------------------------------------------------
"We trained hard - but it seemed that every time we were beginning to form up
into teams, we would be reorganized. I was to learn later in life that we tend
to meet any new situation by reorganizing, and a wonderful method it can be
for creating the illusion of progress while producing confusion, inefficiency,
and demoralisation." - possibly from Petronius, 100 BC


Geert Jan de Groot SFJ2-218, Philips CE-ADC, 
P.O. box 80002, 5600 JB Eindhoven, The Netherlands.
Email: geertj@ica.philips.nl or ..!sun4nl!philica!geertj
Phone: +31 40 797408    FAX: +31 40 732340


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 02 Nov 92 11:32:01 GMT
From:      sensei@dojo.mi.org (the Maniak)
To:        comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   Giving an Ultrix box a second IP address


For political reasons, I'd like to assign a second IP address in a
different logical network (same physical network) to an Ultrix box.
If this possible, and if so, how?

Maybe I'm pursuing this from the wrong angle.  I need to run a
TCP/IP service from one particular IP address, off a machine that
needs to have another IP address/nameservice/etc. for every other
purpose.  Am I pursuing the right track here?

                                                ...Sensei

==
 Internet:  sensei@dojo.mi.org
 UUCP:  ...!wsu-cs!dojo!sensei                      



-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 1992 13:41:24 GMT
From:      dcleek@csd4.csd.uwm.edu (Dick Cleek)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.tcp-ip.ibmpc
Subject:   cutcp docs/scripts


Where can I find documentation on cutcp, esp. ftpbin ??
Especially, writing scripts?
Thanks in advance.
-- 
..........   .........................         .......................
: |_|\/\/ :   Dick Cleek                        dcleek@csd4.csd.uwm.edu
:.centers.:   Univ.of Wisconsin Centers         dcleek@uwcmail.uwc.edu

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 15:09:59 GMT
From:      madhu@cbnewsf.cb.att.com (madhu.shekhar)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP sources with MIB-II wanted

Hello,
    Will some good samaritan out there please 
e'mail me site info on sites having public domain 
TCP/IP sources with MIB-II
    Thanks in advance

Madhu Shekhar
(908) 957-6859
madhu@mt747.att.com


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 16:20:04 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip
Subject:   Re: Who supports multicast? (summary of responses)

In comp.protocols.tcp-ip I wrote:

>Sorry if this is a FAQ, but I am trying to find out which UNIX
>operating systems support multicast (for a project I'm working on).
>So far, the only one I have found is SGI's IRIX 4.0.5.

Here is a brief summary of the replies I got:

	Ultrix: no
	SunOS 4.x: no. Patches available for 4.1.x to add it.
	SunOS 5.x alias Solaris 2.x: yes.
	It was first supported in the IRIX 3.3.x release (1990).
	CDC's EP/IX supports IP multicasting since EP/IX 1.4.3.

Thanks to the following people for their help:

	John DiMarco <jdd@cdf.toronto.edu>
	arc@xingping.esd.sgi.com (Andrew Cherenson)
	Doug.McCallum@Central.Sun.COM (Doug McCallum)
	barnett@alydar.crd.ge.com (Bruce Barnett)
	Klaus.Steinberger@Physik.Uni-Muenchen.DE
	guy@auspex.com (Guy Harris)
-- 
Steve Kotsopoulos                   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

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 17:10:28 GMT
From:      mdm@kataan.apple.com (Michael McDaniel)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Mac IP?

Hi all,

Here's a strange one.  I have a Mac IIsi connected via 50' of ethernet
to a single UNIX box (a NeXT, as it happens).  I want to login to the
NeXT from my Mac, but I don't have any kind of gateway around.  I
presume, therefore, that I cannot use MacTCP.  I think I need some way
to get the Mac to talk IP directly.

I haven't been able to get them talking yet, but I'm not even sure
that the ethernet wire is good.  The NeXT can ping itself even if the
ethernet is unbound...

Any ideas?

I'll summarize if there seems to be interest.

Michael
-- 
Michael D. McDaniel                                      mdm@apple.com
Enterprise Systems Division      {amdahl,decwrl,sun,unisoft}!apple!mdm
Apple Computer, Inc.

Beverly: "My personal feelings about Captain Picard are irrelevant to
  this investigation, and none of your business."
--Beverly, "Coming Of Age", Stardate 41416.2

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 92 17:43:37 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <1992Oct30.212442.119@novell.com>, donp@novell.com (don provan) writes:
|> In article <9213@verdix.verdix.com> mark@verdix.com (Mark Lundquist) writes:
|> >My point is that the interpretation of FIN is non-negotiable, as that
|> >is part of the TCP spec.  The interpretation of "connection completes
|> >normally" is implementation-dependent.
|> 
|> The interpretation "connection completes normally" is defined by the
|> application protocol.  Anything that automatically injects a "complete
|> connection normally" signal into the TCP data stream without the
|> permission of the application protocol implementation is just plain
|> broken, since only the application protocol implementation can know
|> what that means.
|> 
|> >I'm not familiar with the FTP spec or any implementations, but I'd say
|> >it's a fair bet that they don't rely on connection closing to signal
|> >the end of an arbitrary-length data stream.
|> 
|> You'd be wrong.  FTP indicates the end of a file being transfered by
|> closing the TCP connection that was used to transfer the file.
|> There's nothing wrong with this: it's only a problem because of the
|> broken TCP implementations we're discussing that inject a graceful
|> close into a connection they know nothing about.
|> 						don provan
|> 						donp@novell.com

I don't disagree with your statements, however, I was curious about
the systems you execute on.  Specifically, when a process is
terminated, what happens to the open file descriptors?  Aren't they
typically "closed"?  Doesn't TCP typically map this into a "normal
connection close"?  I assume that you would inject an RST in cases
where you could prove "abnormal termination".  Can you cite an RFC
which gives guidelines as to when TCP should inject an RST on behalf
of the application?  I'm sure we would benefit from clean, consistent
implementations.  

The problem I see is that most nominal BSD 
implementations do not externalize the "abort" option to the
applications (NOTE - "don't linger" doesn't do the job in the few
BSD systems I've tried). 

Here's a possible solution:

  Provide a socket option to "abort the connection" on close
  Applications using "normal completion" as a protocol event trigger
	can select this option (actually any application could use it)
  When the application is completed with the data transfer it
	can reset the option to "normal termination" on close

NOTE - this only works if the peer system does something meaningful
with the receipt of the RST, and of course, the application would
have to be in-sync with the propagation of the RST event.

This option seems clean and straight-forward.  The problem is
I am not aware of implementations "providing and using" a 
similar capability.  

Once again, I don't doubt your position.  I simply don't see
conformance in the de-facto implemenation and I don't see guidelines
in any RFC's.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 92 18:15:14 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <rqqij64@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> In article <49102@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
|> > ...
|> > Last I looked "sunrpc" was the port number for the portmapper (111).
|> > There used to be some "questionable" code in the "ONC suite" which
|> > would logically "ping" the portmapper by attempting to create a
|> > connection to the portmapper daemon.  As I recall, the code actually
|> > sits within the "yp" library code (you need to ask SUN why "pinging"
|> > the portmapper from within "yp" is useful).  This has the wonderful
|> > side-effect of leaving connections in a TIME_WAIT state.  The
|> > frequency of "pings" is usually once per process.  Consequently,
|> > when you use multi-process applications or write iterative
|> > scripts (large iteration count and short duration processes)
|> > you exacerbate the problem.
|> > 
|> > The best answer is to ask SUN for a software upgrade.
|> 
|> 
|> Hmmmph!
|> What would you do if you wanted to discover if ypbind is running?

I would send a UDP RPC request to the portmapper to find out
if ypbind was registered.  The problem is that there is code
which creates a "dummy" TCP connection just to see if the
portmapper is running (i.e. doesn't trust UDP time-outs as 
sufficient evidence that the portmapper is not running).
If the connection succeeds, it is immediately closed and then
the UDP RPC request is made to the portmapper to get the 
information about ypbind.

|> 
|> The Sun idea is to use the standard stuff to see if ypbind is
|> registered with the port mapper.  Using TCP does mean a socket is left
|> in TIME_WAIT, but it also means that an answer is returned
|> immediately.

Maybe a few scripts showing you what happens when several thousand
TIME_WAIT connections per second are left on your system will
convince you this is an issue.  What's great is that these are
all "loopback" connections (i.e. no network latency when generating
and no peer system re-use of existing ports)!

Of course, you may argue (and not be disagreed with) that this 
a good reason not to use NIS.

|> 
|> > In the short term, you could avoid using "names" (e.g. netstat -rn)
|> > or you could stop using yellow pages (a.k.a. NIS) or you could
|> > place frequently referenced names in the local files (e.g. /etc/hosts).
|> > 
|> > NOTE - there maybe a thousand other reasons for this behavior, however,
|> > this looks awfully similar to locally observed symptoms.
|> 
|> Netstat can be helped a lot by fixing getservent.c to do cache
|> /etc/services when running with NIS turned off.  The standard 
|> implementation scans the whole stupid file on every call, and also
|> pokes to see if ypbind is running.
|> 
|> 
|> Vernon Schryver,  vjs@sgi.com

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 18:57:47 GMT
From:      lucien@watson.ibm.com (Lucien Van Elsen)
To:        comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: inetd configuration questions

graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) writes:

>>Did you execute "inetimp" and "refresh -s inetd" to make sure the odm
>>had what was in the inetd.conf file?
>
>I have noticed in the "Diskless Workstation Management Guide", when
>referring to changing inetd.conf, that the command "inetimp" is omitted from
>the instructions. Does 3.2 now not use the ODM for inetd?

"refresh -s inetd" causes an "inetimp" to occur, and I believe this was true
under 3.1 as well.  However, this doesn't seem to be a documented feature
anywhere, so I wouldn't rely on it in the future.

	-Lucien


--
-----------------------------------------------------------------------
Lucien Van Elsen                                          IBM  Research
lucien@watson.ibm.com                                     Project Agora

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 92 19:08:05 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Who supports multicast? (summary of responses)

In article <Bx3K1H.4ut@ecf.toronto.edu> steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
>>Sorry if this is a FAQ, but I am trying to find out which UNIX
>>operating systems support multicast (for a project I'm working on).
>>So far, the only one I have found is SGI's IRIX 4.0.5.
>
>Here is a brief summary of the replies I got:
>	Ultrix: no
>	SunOS 4.x: no. Patches available for 4.1.x to add it.
>	SunOS 5.x alias Solaris 2.x: yes.
>	It was first supported in the IRIX 3.3.x release (1990).
>	CDC's EP/IX supports IP multicasting since EP/IX 1.4.3.

Technically, ULTRIX does not support IP multicast.  However, you
can obtain patches for ULTRIX V4.2A via anonymous FTP:
	gregorio.stanford.edu:/vmtp-ip/ipmulticast-ultrix4.2a-binary.tar
I have no direct knowledge that these patches actually work, and I'm sure
that Digital will not be able to help you with them.  But I believe that
the Stanford folks use them successfully.

This same directory also includes other related files, including source
diffs for some versions of ULTRIX (3.1C, 4.1, 4.2A).  If you have an
Ultrix source license, you might be able to make use of these.

And if you want IP multicast support in ULTRIX or OSF, you might consider
calling your DEC salesperson and saying so.

-Jeff

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 19:29:34 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

>The problem I see is that most nominal BSD 
>implementations do not externalize the "abort" option to the
>applications (NOTE - "don't linger" doesn't do the job in the few
>BSD systems I've tried). 

On the latest BSD systems (such as BSD/386) linger does (finally) work.
Set the SO_LINGER socket option with l_onoff to 1, and l_linger to 0.
When you call close() a reset is sent out.  (I just watched this with
tcpdump.)

These newer systems also let you set l_linger to a timer value.
Unfortunately, there are some gotchas.  First, the l_linger value
is not in seconds, but is in clock ticks.  Next, even though l_linger
is an "int" in the linger structure, it's stored into the signed short
so_linger in the socket structure, so you're limited to 32.767 seconds
if the system uses 100 ticks/second.

It would sure be nice if other vendors picked up support for the
linger feature ...

>NOTE - this only works if the peer system does something meaningful
>with the receipt of the RST, and of course, the application would
>have to be in-sync with the propagation of the RST event.

The receiver gets ECONNRESET, so it can distinguish between a normal
close by the other end, and this abort.

	Rich Stevens  (rstevens@noao.edu)

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 20:49:45 GMT
From:      add@is.rice.edu (Arthur Darren Dunham)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: Mac IP?

In article <6@kataan.apple.com> mdm@apple.com writes:
>Hi all,
>
>Here's a strange one.  I have a Mac IIsi connected via 50' of ethernet
>to a single UNIX box (a NeXT, as it happens).  I want to login to the
>NeXT from my Mac, but I don't have any kind of gateway around.  I
>presume, therefore, that I cannot use MacTCP.  I think I need some way
>to get the Mac to talk IP directly.

You presume incorrectly.  MacTCP can do either IPTalk (requiring a
gateway, but works over AppleTalk only lines), or full IP.  When MacTCP
is set to "EtherNet" not "EtherTalk", then it is talking IP.  A
copy of Telnet 2.5 or any other MacTCP based terminal emulator is all
that is required to get a login to the NeXT.

Just make sure that the IPaddresses you set for each machine are sane
and within the subnet mask.  Try pinging the mac from the NeXT at that
point.

>Michael D. McDaniel                                      mdm@apple.com
>Enterprise Systems Division      {amdahl,decwrl,sun,unisoft}!apple!mdm
>Apple Computer, Inc.
-- 
Darren Dunham                 		          add@is.rice.edu
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 21:01:09 GMT
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: Mac IP?

mdm@kataan.apple.com (Michael McDaniel) writes:

>Here's a strange one.  I have a Mac IIsi connected via 50' of ethernet
>to a single UNIX box (a NeXT, as it happens).  I want to login to the
>NeXT from my Mac, but I don't have any kind of gateway around.  I
>presume, therefore, that I cannot use MacTCP.  I think I need some way
>to get the Mac to talk IP directly.

If you have an Ethernet board in the Mac, then MacTCP can put IP on
the Ethernet directly and does not need a gateway. Just select
"Ethernet" (as opposed to "EtherTalk" or "LocalTalk") in the MacTCP
control panel. Then you should be fine.

pr
-- 
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 92 21:08:48 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <49194@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
> |> > Last I looked "sunrpc" was the port number for the portmapper (111).
> |> > There used to be some "questionable" code in the "ONC suite" which
> |> > would logically "ping" the portmapper by attempting to create a
> |> > connection to the portmapper daemon.  As I recall, the code actually
> |> > sits within the "yp" library code (you need to ask SUN why "pinging"
> |> > the portmapper from within "yp" is useful).  This has the wonderful
> |> > side-effect of leaving connections in a TIME_WAIT state.  The
> |> > frequency of "pings" is usually once per process.  Consequently,
> |> > when you use multi-process applications or write iterative
> |> > scripts (large iteration count and short duration processes)
> |> > you exacerbate the problem.
> |> > 
> |> > The best answer is to ask SUN for a software upgrade.
> |> 
> |> Hmmmph!
> |> What would you do if you wanted to discover if ypbind is running?
> 
> I would send a UDP RPC request to the portmapper to find out
> if ypbind was registered.  The problem is that there is code
> which creates a "dummy" TCP connection just to see if the
> portmapper is running (i.e. doesn't trust UDP time-outs as 
> sufficient evidence that the portmapper is not running).
> If the connection succeeds, it is immediately closed and then
> the UDP RPC request is made to the portmapper to get the 
> information about ypbind.

Perhaps my point was not clear.

By using TCP you avoid having to wait for a UDP time-out to expire when
things are not present.  Which would make you more unhappy?  Having an
anonymous TCP port number tied up for a little while or having to wait
a large part of a second (or more if you allow remote access over slow
links) to discover that the portmapper is not running?

Using TCP ensures that if the destination host is up and reachable,
you'll get an answer immediately.  Of course, if you always run with
ypbind and portmap running, you don't care about such a test.  You'll
probably be happier lumping the portmap-not-running case in with the
host-not-up case.


> |> The Sun idea is to use the standard stuff to see if ypbind is
> |> registered with the port mapper.  Using TCP does mean a socket is left
> |> in TIME_WAIT, but it also means that an answer is returned
> |> immediately.
> 
> Maybe a few scripts showing you what happens when several thousand
> TIME_WAIT connections per second are left on your system will
> convince you this is an issue.  What's great is that these are
> all "loopback" connections (i.e. no network latency when generating
> and no peer system re-use of existing ports)!
> 
> Of course, you may argue (and not be disagreed with) that this 
> a good reason not to use NIS.

What harm do the dead TCP ports do?  The modest sized university
servers which are Silicon Graphics boxes that I know of (i.e. many
thousands of users and hundreds of simultaneous active sessions) do not
suffer from any difficulties caused by the wasted TCP ports.

How do you get "several thousand TIME_WAIT connections per second ...
left on your system" in a realistic application?  What kind of
application and system does "several thousand" NIS lookups per second?
It seems to me that any application that does "several thousand" NIS
lookups per second is almost certainly very badly designed.

It is far more important to design a system to work well in real life
than to handle pathological test scripts.  For any non-trivial system,
there exists a sequence of requests which will be pathologically slow.
It is impossible to design anything to do everything well.  The use of
the TCP RST to detect an absent portmapper is elegant and economical.

The cost of the wasted TCP port numbers is several thousands of times
less than the cost of not having reasonable port number lookup
facilities available for programs like netstat.  


Vernon Schryver,  vjs@sgi.com

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 1992 22:58:16 GMT
From:      garrod@smaug.enet.dec.com (Dave Garrod)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: Connecting DEC Vax clusters with IBM SNA networks


In article <1992Nov1.215223.14114@discus.technion.ac.il>, dberry@csa.cs.technion.ac.il (dberry) writes...
>We are looking for a gateway that will allow a variety of applications
>including databases and file servers access to work accross a network
>consisting of a number of Vax clusters, IBM mainframes and Token-Ring LANs.
>The connection is accross X.25 WAN. It seems that having a gateway between
>the VAX world and the SNA world will be of help. What manufacturers are
>making such gateways?
> 
>Thanks, Orna

Digital Equipment Corporation offers a complete range of IBM Interconnect 
Products to interconnect IBM SNA networked systems to DECnet and TCP/IP
networks.

You can get information on the DECnet/SNA product set from your local Digital
sales office. The piece of literature you should ask for is the
"Network Buyers Guide"

Dave

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 92 07:43:34 GMT
From:      hauben@cunixf.cc.columbia.edu (Michael Hauben)
To:        comp.protocols.misc,comp.unix.questions,news.misc,comp.misc,comp.mail.uucp,comp.protocols.tcp-ip,de.comm.uucp,aus.auug
Subject:   How are Usenet Posts Transported?


  I am interested in the technical explanation and general theory
of how Usenet Posts are transported between the original location
and the rest of the Usenet. I am doing research for a paper about
the origins and explosion of Usenet and connectivity. My Profes-
sor has asked me to include some explanation how messages are
transported.

     Thank You,
     -Michael
     hauben@cunixf.cc.columbia.edu

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue,  3 Nov 1992 18:10:36 -0500
From:      Pat_Barron@transarc.com
To:        comp.protocols.tcp-ip
Subject:   TACACS protocol

OK, I give up.  Where is the TACACS protocol documented?  I can't find
it in any RFC or IEN.

--Pat.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 92 14:20:52 GMT
From:      maclean@ctt.bellcore.com (Andrew MacLean)
To:        comp.protocols.tcp-ip
Subject:   TCP Error Control Question

I have some questions on TCP error control.
For common TCP implementations (e.g. SUN):

 - Do we have a retransmission timer for each transmitted 
   segment or one timer for the whole window?

 - What happens when the retransmission timer expire? and
   how it is set and reset?

 - Does the receiver accept out-of-sequence segments as 
   long as they fit within the receive window? and what
   is the maximum (receive) window size?

Any references would help.

 
Thanks

-- 

Andy 
________________________
maclean@ctt.bellcore.com   

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 1992 15:02:54 GMT
From:      kschulz@ba-stuttgart.de (Kay Schulz)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip/nfs

Hi,
does anybody can tell me the difference and the sense of tcp-ip and nfs
i use both here, but why I need them or not and when they are for, I don't know.
and I would like to know about NIS(yellow pages). Or do you know a good book?
KAY
///**************************************************///
///*** kschulz@garfield.t-informatik.ba-stuttgart.de***///
///*** KAY					  ***///


-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Nov 1992 15:15:34 GMT
From:      cm@impmh.uucp (Colin Manning)
To:        comp.protocols.tcp-ip
Subject:   Online source of IEEE specifications wanted

Does anyone know where to obtain IEEE networking standards from on the
Internet ?  I'm principally after some of the 802 series.
-- 
Colin Manning     cm@impmh.uucp      Tel: +44 753 516599

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Nov 1992 19:11:22 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: CSU/DSU w/ RS-232 port connected to system

In article <0105015D.hgkk5a@phngnc.Phonogenic.COM> wjk@Phonogenic.COM (Bill Keenan) writes:
   Does anyone know if I can connect a 56K CSU/DSU with an RS-232
   connection to a serial port, which can sustain 56K, on my mail/news
   system instead of using a router?

Most 56K CSU/DSUs are synchronous beasties, and your mail/news
system's serial ports are probably asynchronous beasties.  The two
won't talk.

Some CSU/DSUs can talk to an async serial port and convert the data
stream into sync before putting the bits on the wire.  This would be
the sort you'd probably need with your current setup.

Alternatively, you could run synchronous PPP on your mail/news system,
which would turn it into a sync-PPP router that would talk to most 56K
CSU/DSUs.  You'd need (a) synchronous PPP software and (b) appropriate
synchronous hardware.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 92 19:14:07 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

gsa@easyaspi.udev.cdc.com (gary s anderson) writes:

>Of course, you may argue (and not be disagreed with) that this 
>a good reason not to use NIS.

I missed the beginning of this thread, so maybe what's being discussed
here isn't the same problem I've seen.  The only time I've seen lots of
TIME_WAIT connections is when NIS is NOT used, never when NIS is being used.

I never investigated the situation very far, but as best I can tell,
any getXbyY request which potentially uses an NIS map causes the NIS
library routines to see if ypbind is running.  If ypbind is running,
the library routines cache this result, and additional getXbyY calls
don't check again.  But, if ypbind is not running, each getXbyY
call causes the library to check again, which opens another socket
to the portmapper.  Because each connection netstat looks at requires
several getXbyY calls, you get an explosion of connections if you
repetitively run netstat when ypbind isn't running.

Is this the problem that's being discussed in this thread, or is this
something different?


Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Nov 1992 19:33:22 GMT
From:      ae56@rz.uni-karlsruhe.de ()
To:        comp.protocols.tcp-ip
Subject:   CFP: CSAM93 Computer Congress

************************************************************************
          PLEASE MAKE THIS ANNOUMCEMENT AVAILABLE TO YOUR COLLEAGUES
                           IN ANY APPROPRIATE  FORM !
************************************************************************

******* FIRST ANNOUNCEMENT AND CALL FOR SESSIONS AND PAPERS ************


      INTERNATIONAL CONGRESS ON COMPUTER SYSTEMS AND APPLIED MATHEMATICS

                           19-23 JULY 1993

                        ST. PETERSBURG, RUSSIA

Organized by Center of Modern Communications, University of St.
Petersburg

THE AIMS  of the  Congress are  to provide  a forum  to explore common
interests  and  interplay  across   disciplines,   and  to  bring   to
practicing  researchers  recent  advances   and the state  of the  art
in  all  areas  of  computer  science,  scientific computing, software
engineering,  applied  and  computational  mathematics.  The  official
language  of  the  Congress  is  English  and  only  papers  submitted
in English  will  be considered.

THE TOPICS  highlighted by  the Congress  include, but are not limited
to: Programming   Languages;      Numerical    Analysis;  Differential
Equations;   Inverse Problems; Fluid Dynamics; Quantum and Statistical
Mechanics; Applied  Probability and Statistics; Theory  of  Computing;
Scientific  Computation;      Parallel   Processing;   Supercomputing;
Optimization and  Operations   Research;  Software    Engineering  and
Compiler Construction;  Symbolic Computation;    CASE  Tools;    Fuzzy
Systems;  Databases;  Networks; Neural Nets;  Artificial Intelligence;
Expert  Systems;   Computer  Graphics;  Computer  Vision    and  Image
Processing; Data  Security; Simulation and Modelling; Electromagnetics
and Semiconductors;  Medicine  and  Biology;  Mathematical  Education;
Dynamical Systems;  Economics and   Management; Environmental Science;
Manufacturing Systems; Material Science;

MINISYMPOSIA PROPOSAL:
The Program Committee invites you, as a potential organizer, to submit
a proposal  for a  minisymposium. A  minisymposium is a session of 3-6
speakers focusing  on a  single topic.  The organizers   should submit
the title(s)  of the session(s) they propose to the  Program Committee
as soon as possible. Minisymposium organizers are responsible  for the
scientific quality   of  papers in  their sessions,  consequently  all
papers invited by  organizers are automatically accepted.

CONTRIBUTED PAPERS/POSTER PRESENTATIONS:
The   program   will  also include contributed paper  sessions   (20 -
minute presentation), posters,  and industrial  exhibits. Authors  are
invited   to submit  to  the CSAM'93  Program  Committee  a  one  page
abstract   and indicate  if they  prefer an  oral or  poster  session.
Authors may  suggest the  title(s)   of   appropriate  session(s)  for
their   paper. Manuscripts of  papers presented  at the  Congress will
be   published   as CSAM'93  Proceedings after  the Congress. A volume
containing all  abstract of the accepted papers and description of all
minisymposia including titles and speakers known  by May 1, 1993, will
be available  to the  participants at  the  Congress. Late  papers and
sessions, if  accepted, may  be presented  at the Congress and will be
listed in the Supplementum to the final program.

DEADLINES:
Minisymposium proposals:  As soon  as possible; Early submissions due:
February  1,   1993;  Normal   submissions  due:  May  1,  1993;  Late
submissions: After May 1, 1993.

EXHIBITOR INFORMATION:
Booths and  tables will  be available  to companies wishing to display
their products and/or services.

Send inquires  for further  information, proposals  for  minisymposia,
and two copies of the abstract to:
 Dr. Sergey S. Voitenko
 Director, Center of Modern Communications,
 University of St. Petersburg
 14th Line 29
 199178 St. Petersburg
 Russia
 e-mail: serge@spfac.lgu.spb.su

Outside of  Ex-USSR and  Eastern Europe proposals for minisymposia and
abstracts can be also send to Dimitri Shiriaev
 e-mail: dima@iamk4508.rz.uni-karlsruhe.de
-----------------------Cut Here------------------------------------------------

                         FORM OF INTENTION

Name:  

Affiliation:

Address:


Check as appropriate:

I plan to attend CSAM'93 and to :

 - organize a Session/Group of Sessions

 - contribute a 20 min lecture

 - present a poster

 - present a computer demonstration

Provisional title(s) of contributed session(s)/paper:

Although I have not yet decided to attend I wish to

 - stay on the mailing list

Date:                         Signature:

Please mail this form to Dimitri Shiriaev
 e-mail: dima@iamk4508.rz.uni-karlsruhe.de
 Subject: CSAM93

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 92 21:58:41 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <rsbtguk@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> In article <49194@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
|> > |> > Last I looked "sunrpc" was the port number for the portmapper (111).
|> > |> > There used to be some "questionable" code in the "ONC suite" which
|> > |> > would logically "ping" the portmapper by attempting to create a
|> > |> > connection to the portmapper daemon.  As I recall, the code actually
|> > |> > sits within the "yp" library code (you need to ask SUN why "pinging"
|> > |> > the portmapper from within "yp" is useful).  This has the wonderful
|> > |> > side-effect of leaving connections in a TIME_WAIT state.  The
|> > |> > frequency of "pings" is usually once per process.  Consequently,
|> > |> > when you use multi-process applications or write iterative
|> > |> > scripts (large iteration count and short duration processes)
|> > |> > you exacerbate the problem.
|> > |> > 
|> > |> > The best answer is to ask SUN for a software upgrade.
|> > |> 
|> > |> Hmmmph!
|> > |> What would you do if you wanted to discover if ypbind is running?
|> > 
|> > I would send a UDP RPC request to the portmapper to find out
|> > if ypbind was registered.  The problem is that there is code
|> > which creates a "dummy" TCP connection just to see if the
|> > portmapper is running (i.e. doesn't trust UDP time-outs as 
|> > sufficient evidence that the portmapper is not running).
|> > If the connection succeeds, it is immediately closed and then
|> > the UDP RPC request is made to the portmapper to get the 
|> > information about ypbind.
|> 
|> Perhaps my point was not clear.
|> 
|> By using TCP you avoid having to wait for a UDP time-out to expire when
|> things are not present.  Which would make you more unhappy?  Having an
|> anonymous TCP port number tied up for a little while or having to wait
|> a large part of a second (or more if you allow remote access over slow
|> links) to discover that the portmapper is not running?

Are you concerned that "port not available" is not returned for UDP?
Are you concerned that "port not available" cannot be linked to the
  calling end point (this is the most likely problem)?
Are you concerned that the local RPC entity will not see the "port
  not available" error when it arrives (i.e. "select" does not wake up
  the application when an error is present)?
Or is there some other subliminal concern which you have (i.e. do you
  use the presence of portmapper to determine the customer's selection
  of the yp service)?

|> 
|> Using TCP ensures that if the destination host is up and reachable,
|> you'll get an answer immediately.  Of course, if you always run with
|> ypbind and portmap running, you don't care about such a test.  You'll
|> probably be happier lumping the portmap-not-running case in with the
|> host-not-up case.

I never know how to satisfy everyone.  Everyone seems to have their
own vision.  If a customer asks for a "yp" service should we ignore
this if our "portmapper" is temporarily unavailable or should we
provide a window for re-instantiation of the portmapper?
If we stop using "yp" would that mean we might start querying
the domain name system with requests it can never resolve (i.e.
in cases where we used "yp" to resolve local domain host names
and used DNS as the secondary base for everything else)???  I'm sure I could 
come up with a few other issues if I thought for a while.  My point is
that the quick receipt of "peer-not-available" does not necessarily
yield a better result.

I guess if you are using the "presence" of portmapper to determine
whether or not "yp" services should be used then the use of TCP
may have some value.


There are actually several issues here, and maybe we are crossing
signals:

1)	Does it make sense to "ping" a UDP-based application with a TCP
	connection before issuing the UDP request to the application?

I don't see the value, unless you are using this as a vehicle to
determine the customer's desire to use the "application".  Even then,
only if you think the UDP services are inadequate.  For "yp"
you seem to feel strongly about this.  I'm not sure why?

2)	Are there issues with using TCP as a "ping service"?

I don't like the fact that "TIME_WAIT" connections are left behind.
You don't seem to think that any useful application could cause a
problem.  A compromise is probably to have support for a connection
abort function (see Steven's reply in a different thread about
connection terminations) and ultimately employ this service in
applications.  This however, is at least a few years from universal
deployment.

NOTE - we didn't even discuss the potnential waste of network resources.

3)	Is the UDP RPC mechanism an ineffective means for obtaining
	portmapper information?

I happen to think UDP is a good fit here.  I don't think you've
commented on this other than implicitly in your promotion of the
TCP ping operation.

|> 
|> 
|> > |> The Sun idea is to use the standard stuff to see if ypbind is
|> > |> registered with the port mapper.  Using TCP does mean a socket is left
|> > |> in TIME_WAIT, but it also means that an answer is returned
|> > |> immediately.
|> > 
|> > Maybe a few scripts showing you what happens when several thousand
|> > TIME_WAIT connections per second are left on your system will
|> > convince you this is an issue.  What's great is that these are
|> > all "loopback" connections (i.e. no network latency when generating
|> > and no peer system re-use of existing ports)!
|> > 
|> > Of course, you may argue (and not be disagreed with) that this 
|> > a good reason not to use NIS.
|> 
|> What harm do the dead TCP ports do?  The modest sized university
|> servers which are Silicon Graphics boxes that I know of (i.e. many
|> thousands of users and hundreds of simultaneous active sessions) do not
|> suffer from any difficulties caused by the wasted TCP ports.
|> 
|> How do you get "several thousand TIME_WAIT connections per second ...
|> left on your system" in a realistic application?  What kind of
|> application and system does "several thousand" NIS lookups per second?
|> It seems to me that any application that does "several thousand" NIS
|> lookups per second is almost certainly very badly designed.

I'm disappointed that you have chosen to doubt the potential to 
create this many connections in a second.  I would have thought
you would have told us that you can do 10,000 per second.....

The problem lies in the indefinite number of scripts and programs
that people have written for UNIX systems over the years.  Many
of these applications function well when limited to small-scaled
systems.  However, people attempt to run these simple little
applications in systems scaled 100 to 1000 times greater than the 
intent of the original application writer.  When this happens,
very interesting system features are encountered.

Here's one simple case study to wet your taste buds:

1)	Software development system
2)	100,000 files in the source library
3)	Shell script walks through the source tree one  "*.c" file at a time
4)	An "ls -l" is done on each file checking group id
5)	A list of all files owned by group "sys" is created 
6)	The sysadmin decides to switch one day from local files
	   to NIS for group names

This script was used for years and worked perfectly until someone
decided to make use of NIS.  Of course this script brought the
system to its knees in a couple of seconds because of the yp feature.
Better yet, the user running this script did so three or four times
before they correlated the system death and the application launch.

If this were the only possible case, I might agree that we simply
eradicate the bad applications.  Additionally, our customers tend to 
require vendor system fixes rather than re-writing their applications.
Consequently, recommending removal of the "ping" operation seemed like
a prudent choice.  

NOTE - the answer to the burning question is about 400-500 connections
per second were generated by this application.  However, vendors
that think they can really support multiple processors concurrently
will find that the potential is greater if concurrent users are invoking
similar applications.

|> 
|> It is far more important to design a system to work well in real life
|> than to handle pathological test scripts.  For any non-trivial system,
|> there exists a sequence of requests which will be pathologically slow.
|> It is impossible to design anything to do everything well.  The use of
|> the TCP RST to detect an absent portmapper is elegant and economical.
|> 
|> The cost of the wasted TCP port numbers is several thousands of times
|> less than the cost of not having reasonable port number lookup
|> facilities available for programs like netstat.  
|> 
|> 
|> Vernon Schryver,  vjs@sgi.com

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 92 01:20:30 GMT
From:      drew@feith1.UUCP (Andrew Sudell)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Netbios over TCP/IP on RS/6000

Does anyone know of a product which supports Netbios over TCP/IP
(RFC 1001/1002) on a RS/6000 running AIX 3.2?  I need to move a 
netbios client program to AIX and unfortunately it is running
over netbios and RFC 1001 implementations seem hard to come by.


--
  Andrew Sudell                            Phone: 215-646-8000 (main)   
  Feith Systems and Software, Inc.         Phone: 215-540-5490 (support)
  Systems Support                            Fax: 215-540-5495          
                                                                           
Smart Mailers: drew@feith1.UUCP Dumb Mailers: {attmail|cbmvax}!feith1!drew 

If you've done six impossible things this morning, why not round it off
with breakfast at Milliways, the Restaurant at the end of the Universe?

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 04 Nov 92 02:07:47 GMT
From:      ingham@hydra.unm.edu (Kenneth Ingham)
To:        comp.protocols.tcp-ip
Subject:   Address Gateway Software


(I am posting this for a friend without access to USENET, please reply
to him, not me---Kenneth)

I have two applications which I require information on.  The first
is an address translation gateway the second is a simple address
administrator/database type application.

Firstly the Address Translation Software....

The network under consideration requires a limited number of users to
have interactive access to the Internet as well as providing inbound
sessions to one or two hosts.  Accordingly the translation application
would supply a pool of Internet assigned addresses for outbound
traffic, and hard mapped addresses for inbound traffic.

One application we have knowledge of is NAT written by Paul Tsuchiya
of Bell-Core. We don't know if this is appropriate.

The sort of information we are after is the existance of such an
application, networks where it is used, sizing info, and how we can
get a hold of it.

Secondly the address admin software.....

The requirement here is for an application which administers the
assignement of IP addresses.  For example the net administrator would
configure the details of how the address is broken down and the
software would provide a front end which would simply assign an
operator the next address of the rank.
(Primitive stuff really)

Please reply via email.

Thanks for your help,

Regards,

Peter Stevenson
Network Consultant   JNA Telecommunications Limited
voice:  +61 2 417 6177
fax:    +61 2 417 5837
e-mail: peterst@jna.com.au
post:   16 Smith St, Chatswood, NSW 2067, Australia.



-- 
Kenneth Ingham WD5BBT
ingham@i-pi.com or ingham@ariel.unm.edu (NeXTMail OK)
Hummin' little Grumman N9646L

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 92 02:21:20 GMT
From:      raw@ushiva.wariat.org (Roland Wilcher)
To:        comp.protocols.tcp-ip
Subject:   TCP connect


Some time ago there was a question about checking for a TCP connect
to a possibly non functioning machine without the long wait.
An answer was posted using connect with nonblocking mode. I don't
have that article now but would appreciate any pointers . Target
system would be Esix SVR4 using the socket libraries and TCP/IP.

-- 
Lack of skill dictates economy of style.             raw@ushiva.ncoast.org
- Joey Ramone                                        raw@ushiva.wariat.org
Roland A. Wilcher                         6207 Luther Ave. Cleve Oh. 44103 
---------------------------------------------------------------------------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 92 06:17:19 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <1992Nov3.191407.2951@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
> 
> >Of course, you may argue (and not be disagreed with) that this 
> >a good reason not to use NIS.
> 
> I missed the beginning of this thread, so maybe what's being discussed
> here isn't the same problem I've seen.  The only time I've seen lots of
> TIME_WAIT connections is when NIS is NOT used, never when NIS is being used.
> 
> I never investigated the situation very far, but as best I can tell,
> any getXbyY request which potentially uses an NIS map causes the NIS
> library routines to see if ypbind is running.  If ypbind is running,
> the library routines cache this result, and additional getXbyY calls
> don't check again.  But, if ypbind is not running, each getXbyY
> call causes the library to check again, which opens another socket
> to the portmapper.  Because each connection netstat looks at requires
> several getXbyY calls, you get an explosion of connections if you
> repetitively run netstat when ypbind isn't running.
> 
> Is this the problem that's being discussed in this thread, or is this
> something different?


I think that's an aspect of the problem.

However, the abused ports with NIS turned off are not the worst part.
I think the worst comes from the fact that the getXbyY routines do not
generally cache the data itself.  They do cache the "yellowup" flag,
and so hide their really hideous behavior.  Watch how the port number
lookup code works.

Depending on timing, you can get netstat into an apparently infinite
loop.  Each time it looks up one port, it can create another one, which
in turn must be looked up.  What the the oddities of poking at kernel
virtual memory, the loop often does not happen.  This behaviour is why
for years Silicon Graphics shipped netstat linked with neither DNS nor
with NIS libraries.  It is only in recent months that some modest hacks
to the libraries have made it possible to turn on the network
databases.  There are still 4 instead of 1 TIME_WAIT port when that
version of netstat is run without NIS turned on.


Vernon Schryver,  vjs@sgi.com

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Nov 92 09:24:03 GMT
From:      jogl@merry.imsd.rwth-aachen.de (Joachim Glaubrecht  #Alwd#)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.tcp-ip.ibmpc
Subject:   I/O-Ram for WD-Card > 1 MB ??!!



hi,
 
sorry, if this is a FAQ, but we need help ...
 
we have some Western Digital EtherNet Cards for out PCs and
like to move the Buffer-Ram from the normale area of
(e.g.) D000 to a place outside the first megabyte.

the manual says that works (e.g. at 110000). and we can
boot the pc as normale (software QEMM (newest rel.) and
a Packet-Driver from the NCSA-Telnet V10.x).

but the first EtherNet-Packet that is received crashes the
PC and QEMM dumps out a screen full of information that
the packet driver has an invaled RAM i/o.

We know that the used RAM-Area is FREE and that there
should be NO problem with other TSR or highloaded stuff.

does anyone out there do such a job and can mail us
a copy of his AUTOEXEC.BAT and CONFIG.SYS ?
 
-- 
  ___             ____________________________________
 /  /  _____     !  jogl@tolkien.imsd.rwth-aachen.de  !
 __/__/_/ Gl     ! Inst. f. Med. Stat. & Doku. (IMSD) !
/_/              !___Aachen__Germany__Europe__Earth___!

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 92 12:03:58 GMT
From:      craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
To:        comp.protocols.tcp-ip
Subject:   RFC for proxy ARP?

Is there an RFC for proxy ARP? If not, is there any other source of info
about this subject. I'm interested in the context of using proxy ARP
for subnets as an interim measure until full subnetting can be implemented
in all hosts. Proxy ARP is not a protocol mentioned in rfc1000.

Thanks

-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K. 

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Nov 1992 14:06:07 GMT
From:      stewart@daffy.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: How large is the DNS?

In article <92309.135530HANK@BARILVM.BITNET> HANK@BARILVM.BITNET (Hank Nussbacher) writes:
>When discussing the DNS with someone who didn't know about the Internet
>I explained that the DNS is a distributed database scattered throughout
>the world.  The person then asked me, how large was all the data put
>together?  I had no idea.  Was it hundreds of megabytes or are we in the
>gigabytes with the DNS?  Is there any way to find out?

I have no idea the size of the DNS database in terms of bytes.
However, a number that I saw at INTEROP was that DNS currently
contains 992,000 hosts.  Note, however, that this number was
found by doing an "inventory" of the DNS; as a result, any
organization who has most of their DNS database hidden from
the outside world doesn't have their hosts included in that
number.

/jws

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Nov 1992 14:29:15 GMT
From:      scstech@solomon.technet.sg (Kenneth Soh)
To:        comp.protocols.tcp-ip
Subject:   Socket Programming Help

Hi ! I have a problem in TCP/IP programming. Hope someone
can help.

I am developing a client-server based application. I 
need to write a deamon program which resides on the 
server (SUN) and loops indefinitely to accept() client
requests. The deamon will then fork() a process
for every new incoming request from the client.

I keep having "Address already in use" (errno 48) problem
everytime I restart the deamon with the same port number -
the bind() function returns error. The same port number
seems to be "released" and re-usable after say, half an
hour.

I hence suspect that those child processes which I spawned
might have inherited duplicated socket descriptors. The deamon
program was then modified so that, upon connection, simply
close() all the sockets and exits - no forking at all.
I have the same problem even with this simpler version.

My observation is that, if I start the deamon program and
CTRL-C it while it is blocking at accept(), the above problem
ceases and I can restart the deamon. In summary, only after
a connection is made, the deamon will fail at bind() when
re-executed.

I guess the problem is in the use of accept() but I don't
understand want actually went wrong. Below is my "program":

------------------------------------------------------
universal_socket = socket( AF_INET, SOCK_STREAM, 0 );

sin.sin_family = AF_INET;
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_port = atoi(argv[1]); <-- just a port number
bind( universal_socket, &sin, sizeof( sin ) )

listen( universal_socket, 3 );

client_socket = accept( universal_socket, 0, 0 );

close( client_socket );
close( universal_socket );
------------------------------------------------------

Also... can someone tell me when should we use shutdown() ?
I've tried to use it but I don't really understand what it
is used for.

Regards,
Kenneth Soh
Singapore

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 92 16:40:30 GMT
From:      mc@math.math.mv.dupont.com (Matt Cunningham-Software Development)
To:        comp.protocols.tcp-ip
Subject:   Sun Generic Broadcasting

I am trying to find the proper broadcast IP address to send a packet (BOOTP 
packet to be specific - but the packet type is not important) to so that
everyone on the network will receive it.  At the point I am trying to send this
broadcast packet I do not know any portion of my IP address.  After consulting
some documentation (Internetworking with TCP/IP, and others) I thought I knew
where I should be sending the packet "255.255.255.255" which from what I
understood meant 'all' hosts on 'all' networks.  When the above was attempted
I received a 'No Such Network' error message, I then tried "0.0.0.255" which
from the documentation I believed meant 'all' hosts on 'this' network, however
this approach resulted in the same error message, 'No Such Network'.  Is there
anybody out there who knows the address I should be sending to?  The
documentation seems to say that it is possible, diskless SUNS must do something
similar (RARP) when booted from a power down state so this is encouraging.
Is there a bug in the SunOS 4.1.x?  Is there something besides setting the
IP (broadcast) address of the UDP packet I'm sending that needs to be done?

							Thanks in Advance.
							Matt Cunningham
							Software Engineer
							EOP Group

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 92 16:47:33 GMT
From:      bob@comlab.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: Netbios over TCP/IP on RS/6000

Andrew Sudell writes:
>Does anyone know of a product which supports Netbios over TCP/IP
>(RFC 1001/1002) on a RS/6000 running AIX 3.2?  I need to move a 
>netbios client program to AIX and unfortunately it is running
>over netbios and RFC 1001 implementations seem hard to come by.

Syntax in Washington state (USA) makes and markets a line of networking
products.  They sell a LAN Manager server (actually an SMB server) for
a number of Unix hosts.  Their LMserver product includes an RFC1001/1002
NetBIOS implementation that can talk to PC TCP/IP NetBIOS implementations.
Keep in mind, of course, that NetBIOS is a programming interface and
not a protocol per se.  And since by definition an application program
talks to a NetBIOS driver by invoking a software interrupt on an Intel
architecture processor, the API on your RISC box is going to be somewhat
different.  Still, this will allow your Unix box to talk to TCP/IP NetBIOS
stacks on your local PC's.  They also support OSI based NetBIOS and shortly
will support Microsoft NetBEUI.

Syntax
1501 West Valley Hwy North
Suite 104
Auburn, WA  USA  98001
206-838-2626

Ask for Bob Neary.

I am not connected with Syntax, blah, blah, blah....

Bob

--
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Nov 1992 13:55:30 IST
From:      Hank Nussbacher <HANK@BARILVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   How large is the DNS?

When discussing the DNS with someone who didn't know about the Internet
I explained that the DNS is a distributed database scattered throughout
the world.  The person then asked me, how large was all the data put
together?  I had no idea.  Was it hundreds of megabytes or are we in the
gigabytes with the DNS?  Is there any way to find out?

Thanks,
Hank

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Nov 1992 20:49:35 GMT
From:      wjw@pt.com (Wald Wojdak)
To:        comp.protocols.tcp-ip
Subject:   Lachman Associates TCP/IP for Motorola Unix V r3.2

Hello,

Is there anyone familiar with a TCP/IP package from LACHMAN ASSOCIATES
used by MOTOROLA in their D-Box UNIX V rev 3.2. I am working on Network
Interface Device Driver and found that the information in the SYSTEM
ADMINISTRATOR's QUIDE are not sufficient. There must be some Network Interface
Programmers Guide or some document that describes how to interface Network
Interface Device Driver to a LACHMAN ASSOCIATES TCP/IP used in Motorola 
D-Box UNIX V rev 3.2. 

Replies to: wjw@pt.com

Thank you,

Wald (wjw@pt.com)

Waldemar Wojdak
Performance Technologies Incorporated
315 Science Parkway
Rochester, NY 14620

Tel: (716) 256-0200 ext 272
Fax: (716) 256-0791
-- 
__
Wald Wojdak, Performance Technologies Incorporated	wjw@pt.com
315 Science Parkway, Rochester, New York 14620            uupsi!ptsys1!wjw

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Nov 1992 02:10:09 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP bandwidth problems - experiences sought

In article <chris.720420706@suite.sw.oz.au> chris@suite.sw.oz.au (Chris Maltby) writes:
>I am experiencing some surprising things with a system running
>SCO Unix 3.2.2 and SCO TCP 1.1.3f. We have recently upgraded
>the hardware from a 25MHz 486DX to 486DX2 (clock doubled) cpus,
>extra memory (16+16MB) and a 32bit 3com Ethernet card. The system
>is a microchannel box.
>So, here are my questions:
>
>Q1. Would upgrading to SCO TCP 1.2 improve the efficiency of this
>    system or should we just throw out SCO and try something else?

Yes.  1.2 is easily twice as fast as 1.1.3.  Also, many of the drivers on
the newest SCO LLI (3.1.0) disk are much faster as well. 
>
 
>Q2. Does SCO TCP 1.2 require an upgrade from SCO UNIX 3.2.2?

Yes.  You need to be running 3.2.4, but it's worth it.  3.2.4 is a much
better system (IMO).

>
>Q3. Is this sort of behaviour with installing a 486DX2 to be expected?

I don't know.  The DX2 doesn't change the external speed of the CPU.  TCP/IP
1.2 seems to be limited by I/O bandwith, since loopback speeds are much higher
than over-the-wire.  This may mean that doubling the internal chip processing
speed won't help your problems.

I hope this helps.
-- 
Steve Alexander, Software Technologies Group    | stevea@isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 03:17:24 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <rsbtguk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
}In article <49194@shamash.cdc.com>, gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
}> |> What would you do if you wanted to discover if ypbind is running?
}Perhaps my point was not clear.
}
}By using TCP you avoid having to wait for a UDP time-out to expire when
}things are not present.

An alternative would be to use UDP, but connect() to the port;
then when you do a send(), you can examine the error code
to see if you get an ECONNREFUSED.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 05:50:47 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Public Election Server Stats -- An Internet Application

World.std.com (The World) in conjunction with Adam Gaffin and the
Middlesex News ran a free, public election server. Starting about 8PM
on the night of the election major results were updated every twenty
minutes or so.

These results were accessible to anyone on the internet by simply
typing:

		finger election@world.std.com

which reflected back a screenful or two of info.

This kept our system (a Sun4/280 with 80MB, not a small system) very
busy. In fact, early in the day the system load jumped to over 200
(anything much over 20 would be considered quite overloaded.) In
response we made some drastic modifications to the finger daemon
software which made things only slightly miserable but we muddled
through.



Here are some stats from the experience:



* Total queries served over approximately 36 hours:

			49,419

* Domains served with counts per domain:

	Domain	Count		Type

	edu     28001		educational
	com     12000		commercial
	uk      2444		United Kingdom
	se      897		Sweden
	gov     848		Government
	ca      808		Canada
	org     770		Unspecified Organization (usually non-profit)
	au      769		Australia
	il      457		Israel
	net     434		Network Service Org
	nz      226		New Zealand
	mil     155		Military
	de      140		Germany
	fi      105		Finland
	no      75		Norway
	jp      73		Japan
	fr      69		France
	kr      64		Korea
	dk      59		Denmark
	sg      58		Singapore
	us      47		United States (other than many edu, com, etc)
	nl      47		Netherlands (Holland)
	ch      34		Switzerland
	pt      29		Portugal
	at      27		Austria
	mx      24		Mexico
	ee      17		Estonia
	in      16		India
	hk      10		Hong Kong
	cl      10		Chile
	pl      8		Poland
	it      8		Italy
	hu      5		Hungary
	is      2		Iceland
	za      1		Republic of South Africa
	ve      1		Venezuela
	be      1		Belgium

(counts don't add up because hosts who's numeric address could not be
resolved were elided from this report but not the total count.)

* Requests per hour, Nov 3, midnight thru Nov 4, noon:

	Hour	Count

	00       54
	01       47
	02       37
	03       56
	04       34
	05       36
	06       46
	07       82
	08       189
	09       470
	10       644
	11       202
	12       40
	13       85
	14       466
	15       1331
	16       1825
	17       2145
	18       2256
	19       4763
	20       6044
	21       6341
	22       5040
	23       3503
	00       2232
	01       1341
	02       795
	03       596
	04       503
	05       667
	06       730
	07       865
	08       1151
	09       1330
	10       1142
	11       1036
	12       220

(don't ask me why so many people queried for results before the
election even began, perhaps they have more faith in computers than is
reasonably healthy.)


* Sample (last) report:


MIDDLESEX NEWS ELECTION NETWORK
 
3:50 a.m. Final results of the night. Good night/morning,
all!
 
For complete results and in-depth news and analysis of
the results, pick up Wednesday's Middlesex News, on sale
throughout MetroWest.
 
``I accept tonight the responsibility you have given to me, 
to be the leader of this, the greatest country in human 
history,'' Clinton said. ``This is a remarkable coalition 
for change. I ask you to keep that commitment as we move 
>from the election to governing.''
 
Bush promised a smooth transition of power and wished 
Clinton well in the White House. ``It's over,'' he whispered 
to his wife Barbara.
 
With 88 percent of the nation's precincts reporting.
 
 Clinton 38,860,586 - 43 percent
 Has won 29 states and the District of Columbia with 349 ev.
 Leads in 3 states with 16 electoral votes
 
 Bush 34,349,041 - 38 percent
 Has won 15 states with 132 electoral votes
 Leads in 3 states with 41 electoral votes
 
 Perot 16,835,474 - 19 percent
 Has won 0 state with 0 electoral votes
 Leads in 0 state with 0 electoral votes   
 
MASSACHUSETTS
 
1,777 of 2,138 precincts - 83 percent
 
 George Bush, GOP (i) 663,212 - 29 percent
 x-Bill Clinton, Dem 1,084,350 - 48 percent
 H.Ross Perot, Ind 514,454 - 23 percent
 
 
Question 1 Tobacco Tax 
 
 747 of 2,138 precincts - 35 percent
 
 x-Yes, 589,725 - 55 percent
 No, 480,736 - 45 percent
 
Question 2 Corporate Taxes 
 
749 of 2,138 precincts - 35 percent
 
 x-Yes, 555,940 - 55 percent
 No, 455,437 - 45 percent
 
Question 3 Recycling 
 
748 of 2,138 precincts - 35 percent
 
 Yes, 432,381 - 40 percent
 x-No, 638,730 - 60 percent
 
Question 4 Oil & Hazards Tax 
 
751 of 2,138 precincts - 35 percent
 
 Yes, 419,733 - 40 percent
 x-No, 621,870 - 60 percent
 
U.S. House District 2 
 
192 of 212 precincts - 91 percent
 
 x-Richard E. Neal, Dem (i) 117,009 - 63 percent
 Anthony W. Ravosa Jr., GOP 68,250 - 37 percent
 
U.S. House District 3 
 
155 of 205 precincts - 76 percent
 
 Joseph D. Early, Dem (i) 87,925 - 45 percent
 x-Peter I. Blute, GOP 107,543 - 55 percent
 
U.S. House District 4 
 
142 of 200 precincts - 71 percent
 
 x-Barney Frank, Dem (i) 143,996 - 72 percent
 Edward J. McCormick III, GOP 54,810 - 28 percent
 
U.S. House District 5 
 
144 of 196 precincts - 73 percent
 
 Paul W. Cronin, GOP 77,649 - 45 percent
 x-Martin T. Meehan, Dem 93,404 - 55 percent
 
U.S. House District 7 
 
198 of 223 precincts - 89 percent
 
 x-Edward J. Markey, Dem (i) 160,251 - 71 percent
 Stephen A. Sohn, GOP 66,567 - 29 percent
 
U.S. House District 8 
 
141 of 233 precincts - 61 percent
 
 x-Joseph P. Kennedy, Dem (i) 76,948 - 83 percent
 Alice Harriett Nakash, Unr 15,823 - 17 percent
 
 
 
Midlsx,Norflk&Worcstr State Senate
 
 David P. Magnani, Dem 36,034
 Thomas P. Tierney, GOP 22,144 
 
1st Suffolk & Norfolk 
 
16 of 58 precincts - 28 percent
 
 Christopher M. Lane, GOP (i) 12,495 - 53 percent
 Marian Walsh, Dem 11,138 - 47 percent
 
Middlesex & Worcester state senate 
 
16 of 49 precincts - 33 percent
 
 Robert A. Durand, Dem (i) 14,560 - 54 percent
 William M. Monnie, GOP 12,633 - 46 percent
 
Norfolk,Bristol & Middlesex state senate
 
33 of 47 precincts - 70 percent
 
 David H. Locke, GOP (i) 20,625 - 40 percent
 Cheryl A. Jacques, Dem 31,234 - 60 percent
 
1st Worcester & Middlesex State Senate
 Hopkinton, Hopedale, Southboro, Upton reporting
 
 Matthew John Amorello, GOP (i) 9984
 Guy W. Glodis, Dem 6788 
 
11th Worcester
Northboro, Shrewsbury reporting
 
 Gauch, GOP 9,938
 Whitney, Dem 9,166
 
Middlesex & Worcester State Senate 
 
 Robert A. Durand, Dem (i) 4379
 William M. Monnie, GOP 250 
 
 
 4th Middlesex state rep
 all precincts reporting
 
 Valianti, Dem (i), 9,318
 Carlman, GOP 6179
 
 5th Middlesex 
 All precincts reporting
 Douglas W. Stoddart, GOP (i) 11,091
 Megan H. Christopher, Dem 7764
 
 
6th Middlesex 
All precincts reporting
 
 Gray, Dem (i) 10,729
 Havel, GOP 7,075
 
 7th Middlesex State Rep
 All precincts reporting
 
 Stefanini, Dem 9,981
 Stewart, GOP 5,778
 
8th Middlesex 
 
9 of 12 precincts - 75 percent
 
 Barbara Gardner, Dem (i) 10,982 - 67 percent
 David W. Henderson, GOP 5,459 - 33 percent
 
9th Middlesex 
 
1 of 11 precincts - 9 percent
 
 David F. Gately, Unr (i) 778 - 55 percent
 Kathleen B. McMenimen, Dem 632 - 45 percent
 
 13th Middlesex State Rep
 Sudbury, Wayland reporting
 
 Hasty Evans (i), GOP, 10,238
 Vicki Hammel, Dem 5,502
 
 9th Worcester State Rep.
 All precincts reporting
 
 Platt, Dem, 8,733
 Peterson, GOP 8,153
 Delle, I, 3,017
 
 10th Norfolk State Rep.
 All precincts reporting
 
 Ranieri, Dem, 15,496
 Sawyer, IVP, 5,009
 
 14th Norfolk State Rep.
 All precincts reporting
 
 Haas, Dem, 8515 
 Madden, GOP, 10,142 
 
-- 
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 11:44:04 GMT
From:      deraadt@newt.cuc.ab.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

I'm currently implimenting YP client functionality for 386bsd. So far,
it's been an enjoyable and frustrating time....

In article <49256@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>  |> > |> > sits within the "yp" library code (you need to ask SUN why "pinging"
>  |> > |> > the portmapper from within "yp" is useful).  This has the wonderful
>  |> > |> Hmmmph!
>  |> > |> What would you do if you wanted to discover if ypbind is running?

Well, on some systems (including my code at the moment) that's exactly
why TCP is used. It's faster than UDP.

My first code used UDP to find out if ypbind was running. Well, if you
don't get an answer, even in talking to 127.0.0.1, well, the kernel's
buffers could just be swamped at the moment. So you have to try a few
times. Not pretty.

So, I started using TCP. Immediate response yes/no whether YP is
running. I had no real concerns with whether the portmapper is
running.

I'm have a Sun too. A few minutes ago, I went and looked to see why
the file /etc/ypbind.lock exist... a bit of snooping and following a
hunch...

  4835 -rw-------  1 root            0 Nov  2 21:46 /etc/ypbind.lock
  ^^^^
 inode

pstat -i | grep 4835
 f23f9a8    R     7,  0  4835 100600   1    0         0   E     2   0   1 VREG
							  ^^^
That little 'E' is an exclusive lock.

Could someone explain exactly what is going on here? What I suspect
follows: ypbind maintains the exclusive lock on /etc/ypbind.lock
Processes that are interested can find out if ypbind is running by
doing a lockf(fd, F_TEST).  Sun's ypbind also puts an exclusive lock
on /var/yp/binding/domainname.2 and /var/yp/binding/domainname.1.  I
suspect the 2 is YPBINDVERS.

Just trying to get a flock() on that file seems to work. This is so much
easier than what it appears the entire argument here is about.

Here's what happens if I trace a program that needs to check YP.

    open ("/var/yp/binding/cuc.ab.ca.2", 0, 036736173730) = 4
    flock (4, 06) = -1 EWOULDBLOCK (Operation would block)
    mmap (0x8ab8, 14, 0x1, 0x80000001, 4, 0) = 0xf7710000
    close (4) = 0

Aha. The fact that the flock() failed tells us that ypbind is running.
Sun places into the binding file the actual (struct sockaddr_in) at
which the current ypserver can be found (It could be ypbind's address,
but it makes more sense to be ypserv's address). So they mmap() the
(struct sockaddr_in) and continue.

>  |> > 
>  |> > I would send a UDP RPC request to the portmapper to find out
>  |> > if ypbind was registered.  The problem is that there is code
>  |> > which creates a "dummy" TCP connection just to see if the
>  |> > portmapper is running (i.e. doesn't trust UDP time-outs as 
>  |> > sufficient evidence that the portmapper is not running).

I would not trust a UDP timeout on "localhost" as meaning that the
portmapper is dead. It might take 5 seconds for a busy portmapper to
answer. Someone in Timbuktu, at the end of a very slow link, may have
been spraying the portmapper. Packets may have convoyed, and the
portmapper may be swamped! How long are you going to wait around?

>  |> > If the connection succeeds, it is immediately closed and then
>  |> > the UDP RPC request is made to the portmapper to get the 
>  |> > information about ypbind.
>  |> 
>  |> Perhaps my point was not clear.
>  |> 
>  |> By using TCP you avoid having to wait for a UDP time-out to expire when
>  |> things are not present.  Which would make you more unhappy?  Having an
>  |> anonymous TCP port number tied up for a little while or having to wait
>  |> a large part of a second (or more if you allow remote access over slow
>  |> links) to discover that the portmapper is not running?

With TCP, your connection will succeed immediately, well, as long as
the listen queue has room for you....


Really, I prefer Sun's method of checking for yellow. A flock() on a
locked file means you are talking to an inode that is already in the
buffer cache. That's got to be faster and more reliable than talking
to portmap & ypbind.

Anyways, I'm going to impliment my routines much like Sun's did!

Only one thing bothers me with the RPC programming I am doing. Sun's
ypbind is not multithreaded; rather, it forks when it gets a request
for a currently unbound domain. I decided to make my ypbind much more
multithreaded. What I have come to discover to my disgust is that if
you wish to write a properly multithreaded RPC application you have to
give up all the juicy RPC and SVC routines and dig right into the XDR
level. What a pain. And, boy, I could scream because I have found no
way to access msg->msg_xid from the SVC/RPC level! For a proper
multi-threaded application, you are going to need to save a copy of
that for the later reply!
 <tdr.
--

This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 12:28:44 GMT
From:      sweeney@Ingres.COM (Tony Sweeney)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connect

In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes:
>
>Some time ago there was a question about checking for a TCP connect
>to a possibly non functioning machine without the long wait.
>An answer was posted using connect with nonblocking mode. I don't
>have that article now but would appreciate any pointers . Target
>system would be Esix SVR4 using the socket libraries and TCP/IP.
>
>-- 
>Lack of skill dictates economy of style.             raw@ushiva.ncoast.org
>- Joey Ramone                                        raw@ushiva.wariat.org
>Roland A. Wilcher                         6207 Luther Ave. Cleve Oh. 44103 
>---------------------------------------------------------------------------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 13:02:41 GMT
From:      mick@horga.ruhr.de (Michael Reichelt)
To:        comp.protocols.tcp-ip
Subject:   Tecnical question

Hi,

does anybody know if there exists a possibility to log all activities
caused by ip-requests that build up an IP connection to other networks
than our own ?

We have to get a list of all our costs that get up because of outgoing 
ip packets and because of this I am looking for a program that logs all
type of ip activity to a special file or better a software package that
tells me about the costs of the connections directly.

Thanks,

Michael.

ps. please send me an answer to mick@macrotk.uucp

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 15:20:57 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: How large is the DNS? (around 150 Mbytes)

>>When discussing the DNS with someone who didn't know about the Internet
>>I explained that the DNS is a distributed database scattered throughout
>>the world.  The person then asked me, how large was all the data put
>>together?  I had no idea.  Was it hundreds of megabytes or are we in the
>>gigabytes with the DNS?  Is there any way to find out?
>
>I have no idea the size of the DNS database in terms of bytes.
>However, a number that I saw at INTEROP was that DNS currently
>contains 992,000 hosts.  Note, however, that this number was
>found by doing an "inventory" of the DNS; as a result, any
>organization who has most of their DNS database hidden from
>the outside world doesn't have their hosts included in that
>number.

We do a monthly hostcount for Europe. For that purpose I pull *every* zone
file from all properly registered DNSes in Europe (Europe in our sense
includes Israel and Tunesia, and the Baltic States and other Ex-Soviet
States). The total zone output for this comes down to around 32 Mbytes of
DNS info. Considering the fact that there are 250,000 hosts in Europe
according to our last count, and 1,1 Million hosts worldwide, according to
the last global hostcount done at SRI, the total amount of information
available in the DNS on that part of the Internet that we can all reach, must
be something in the order of 150 Mbytes.

As said above, organisations with their DNS hidden from the "normal" Internet
are not counted, and therefore their DNS size unknown.

Cheers,

-Marten
RIPE Network Coordination Centre

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 15:41:16 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connect

In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes:
>
>Some time ago there was a question about checking for a TCP connect
>to a possibly non functioning machine without the long wait.
>An answer was posted using connect with nonblocking mode. I don't
>have that article now but would appreciate any pointers . Target
>system would be Esix SVR4 using the socket libraries and TCP/IP.
>
>-- 
>Lack of skill dictates economy of style.             raw@ushiva.ncoast.org
>- Joey Ramone                                        raw@ushiva.wariat.org
>Roland A. Wilcher                         6207 Luther Ave. Cleve Oh. 44103 
>---------------------------------------------------------------------------

If the TCP socket is non-blocking the file descriptor will be ready for writing
when the connection is complete.  There are several ways to check to see if the
socket is ready for writing, select() is one of them.  Don't forget to check the
errno after connect().  You are expecting EINPROGRESS, but you need to be
prepared to handle other errors.

-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 16:53:49 GMT
From:      alech@hpindda.cup.hp.com (Alec Henderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Netbios over TCP/IP on RS/6000

>Does anyone know of a product which supports Netbios over TCP/IP
>(RFC 1001/1002) on a RS/6000 running AIX 3.2?  I need to move a 
>netbios client program to AIX and unfortunately it is running
>over netbios and RFC 1001 implementations seem hard to come by.

Try contacting:

     Micro Computer Systems (MCS)
     2300 Valley View Lane, Suite 800
     Irving, Texas  75062
     214-659-1514

MCS sells a variety of NetBIOS/NetBEUI implementations for various
network transports on both DOS and UNIX.

Note that this is not an official recommendation by Hewlett-Packard;
HP does not sell or support MCS's products.          

Regards,
Alec Henderson

Telephone: T/408-447-3965		Hewlett-Packard
FAX:       408-447-3660			Information Networks Division
E-mail:    alech@cup.hp.com	       	19420 Homestead Road MS 43L9
HPDesk:    Alec Henderson/HP6600/1B	Cupertino, CA  95014  (USA)

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 17:07:59 GMT
From:      jkors@media03.UUCP (Jacques Kors)
To:        comp.unix.misc,comp.protocols.tcp-ip,comp.lang.postscript
Subject:   problems tfping to a rip



Can anyone give me some advice on the following problem:

One of our customers  has a configuration with an Intel 520 MBII server 
running unix SYSV r3.2 and three Linotype Postscript RIPs (rip30) connected 
via ethernet.
File are sent from the server to the rips using TFTP. These files are 
somewhere between 1Mb and 4Mb in size.
several times a day this communication fails. When this happens the two 
machines (server and rip) keep talking to each other but they don't seem
to make any progress. Usually the operator terminates such a print job,
after about 20 minutes, bij resetting the rip and then retransmits the file.
Since this compagny is in the newspaper business they can't really afford
this loss of time.

Every time this happens it turns out that a given packet is not accepted
by the rip. The server keeps retransmitting this packet and the rip keeps
rejecting it. It then takes them about half an hour to decide that there is 
no use in going on.
The reason seems to be that the UDP checksum is wrong. normally this 
checksum is correct, but the troublesome packets always have 0xFFFF for 
checksum. if my calculations are correct it should be 0x0 instead.

Some testing at our site has shown that Interactive SYSV R3.2 v2.0.2
has the same effects. Our sun servers don't even bother to generate a 
checksum. All unix boxes we tried don't seem to check this UDP checksum
at the receiving end.

now for the questions:
- am i right on the checksum bit
- Does anybody use a simular setup
  what are your experiences 
- Has anybody encountered this problem
- What is your solution
- Is there some workaround possible
  it would be a great improvement if the problem could be detected
  earlier without having to wait for nothing ( and 20 minutes ).
- Hav you got any suggestions

Thanks in advance for any suggestions/help/information etc.....,

Jacques
----
below you'll find an ascii/hex dump of an erroneous packet:

*Packet 5623 (558 bytes) at T + 665.9710 secs, Delta t 0.0209 secs
 Destination = RIP03       , Source = GBD02       , Type = 0800
 VER/IHL = 45, TOS = 00, Len = 0220, ID = 4108, FLG/FRG = 0000, TTL = 1E,  
 Prtcl = 11, IP Chksum = C6F9, IP Srce = C05C8907, IP Dest = C05C890B, 
 Srce Port = 0D38, Dest Port = 065C, Len = 020C, UDP Chksum = FFFF
 0000: 00 03 0C 95 41 31 46 31 45 31 44 32 32 32 31 32     ....A1F1E1D22212
 0010: 30 32 30 32 30 32 30 32 30 31 42 32 32 31 44 31     0202020201B221D1
 0020: 45 31 44 31 43 32 32 31 44 31 44 32 32 32 32 31     E1D1C221D1D22221
 0030: 44 31 43 32 36 31 41 31 43 32 31 32 32 31 43 31     D1C261A1C21221C1
 0040: 44 31 43 32 31 32 30 31 46 0D 0A 32 35 32 30 32     D1C21201F..25202
 0050: 30 32 30 32 30 32 30 32 30 32 33 32 36 32 35 32     0202020202326252
 0060: 31 31 44 32 32 32 32 31 44 32 34 31 44 32 34 31     11D22221D241D241
 0070: 45 32 30 31 46 32 34 32 31 32 36 32 30 32 32 31     E201F24212620221
 0080: 45 31 45 32 33 32 32 32 32 32 32 32 32 32 34 31     E1E2322222222241
 0090: 42 31 31 35 43 39 30 36 30 33 34 0D 0A 33 35 31     B115C906034..351
 00A0: 46 31 45 31 43 31 44 31 44 31 45 31 45 31 45 31     F1E1C1D1D1E1E1E1
 00B0: 45 31 44 32 33 31 44 31 43 32 31 31 43 31 43 32     E1D231D1C211C1C2
 00C0: 31 31 46 32 34 32 32 32 31 32 36 31 42 31 37 32     11F242221261B172
 00D0: 31 45 39 44 34 43 38 43 37 43 38 43 38 43 32 43     1E9D4C8C7C8C8C2C
 00E0: 34 43 36 43 30 43 34 43 34 42 30 42 41 0D 0A 41     4C6C0C4C4B0BA..A
 00F0: 44 36 32 31 32 32 31 32 34 32 33 32 41 32 42 31     D62122124232A2B1
 0100: 46 32 32 32 32 32 32 32 37 32 32 32 32 32 33 32     F222222272222232
 0110: 32 32 31 32 45 32 37 31 45 32 32 31 39 31 41 31     2212E271E22191A1
 0120: 43 31 43 31 43 31 42 32 30 31 41 31 35 31 42 31     C1C1C1B201A151B1
 0130: 41 31 46 31 46 31 39 31 46 31 46 31 41 31 42 0D     A1F1F191F1F1A1B.
 0140: 0A 31 41 32 30 31 41 31 42 32 30 32 30 31 42 31     .1A201A1B20201B1
 0150: 43 31 38 31 38 31 43 31 42 31 42 32 30 31 43 31     C18181C1B1B201C1
 0160: 43 31 43 31 41 31 45 32 32 31 42 31 46 32 33 32     C1C1A1E221B1F232
 0170: 32 32 30 32 33 32 39 32 39 32 34 32 33 31 43 31     22023292924231C1
 0180: 41 31 43 31 43 31 44 31 44 31 38 31 38 31 39 31     A1C1C1D1D1818191
 0190: 38 0D 0A 31 44 31 43 31 43 31 44 31 38 31 44 31     8..1D1C1C1D181D1
 01A0: 44 31 38 31 44 31 43 31 43 31 43 31 42 32 31 31     D181D1C1C1C1B211
 01B0: 43 31 44 31 38 31 38 31 45 31 38 31 39 31 39 31     C1D18181E1819191
 01C0: 38 31 45 31 37 31 44 31 38 31 38 31 44 31 44 31     81E171D18181D1D1
 01D0: 39 31 41 31 38 31 45 31 37 31 44 31 44 31 37 31     91A181E171D1D171
 01E0: 45 31 38 0D 0A 31 39 31 44 31 43 31 36 31 42 32     E18..191D1C161B2
 01F0: 30 31 42 31 44 31 37 31 42 32 34 31 45 31 45 31     01B1D171B241E1E1
 0200: 45 31 45 31                                         E1E1

----

+-----------------+---------------------------------+-------------------+
 \ Jacques Kors    \  email: jkors@media01.UUCP      \  Disclaimer:      \
  \ Mediasystemen   \        ...!sun4nl!media01!jkors \  you would look   \
   \ P.O.Box 4932    \                                 \ funny too, if you \
    \ 2003 EX Haarlem \  voice: + 31-23-319075          \  were RIPped      \
     \ The Netherlands \  fax  : + 31-23-315210          \                   \
      +-----------------+---------------------------------+-------------------+
-- 
+-----------------+---------------------------------+-------------------+
 \ Jacques Kors    \  email: jkors@media01.UUCP      \  Disclaimer:      \
  \ Mediasystemen   \        ...!sun4nl!media01!jkors \  you would look   \
   \ P.O.Box 4932    \                                 \ funny too, if you \
    \ 2003 EX Haarlem \  voice: + 31-23-319075          \  were JPEGged     \
     \ The Netherlands \  fax  : + 31-23-315210          \                   \
      +-----------------+---------------------------------+-------------------+

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 18:57:00 GMT
From:      M20923@MBVM.Mitre.Org (Daniel Sorensen)
To:        bit.listserv.ibmtcp-l,comp.protocols.tcpip
Subject:   Re: Remote printing from JES2 spool

In article <IBMTCP-L%92110411450390@PUCC.PRINCETON.EDU>
David Condrey 656-2733 <DAVIDC@CLEMSON.BITNET> writes:
 
>
>At the last SHARE, I brought up the fact that our TSO users are used to
>printing by releasing sysout off of spool (in addition to using a TSO
>"print" command) and that I wanted to allow these users to be able to
>use printers remote to MVS.
>
>The specific problem that we are having is that we have a plotter on
>the network that our MVS users want to plot to via SAS/GRAPH. SAS users
>run batch jobs and release the output from spool (in our case using IOF).
>
>The foremost answer seems to be defining a remote printer to LPD.
>However there is currently no way for LPD to get output from spool
>and do the right things with it (retry on failure).
>
>When I mentioned this, someone in the back stood up and said that he was
>solving this using a product called VPS (sic). Since then, we have
>bought VPS. I have not personally looked at it, but our network manager
>says that the VPS people indicated there is no solution to our problem.
>
>My question is: if you have solved this problem (or have any thoughts
>on it), I'd really like to hear them. If the person that mentioned VPS
>at the TCP/IP FFA is listening, I'd like to ask a few questions.
>
>Thanks everyone.
>-David
>-------------------------------------------------------------------------------
>|David S. Condrey           ___  ______ _____    Bitnet: DAVIDC@CLEMSON       |
>|MVS Systems Programmer     |  \ \_____ |        Internet: DAVIDC@CLEMSON.EDU |
>|Clemson University         |__/ _____/ |____    Phone: (803) 656-2733        |
>-------------------------------------------------------------------------------
 
  It seems from the responses so far that VM shops have resolved the batch
network printing problem by using service machines.  In fact, MITRE is
currently the same technique.  Our MVS machine sends the file to a VM
service machine, which in turn sends the files out using LPR.  The problem
is that we will soon be phasing out the VM machine.
 
  Has anyone found a MVS only solution to batch network printing?  Even
if VPS can use LPR in batch, it is too expensive.  If there is no TCP/IP
solution to network printing, our next solution would be to look into
NJE-type links to an RS/6000 and letting it deal with the actual printing.
Any ideas?
 
Daniel Sorensen
IBM Systems Group
The MITRE Corporation
(617) 271-2726
 
What, me speak for MITRE?  Ha!

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 92 19:23:45 GMT
From:      M20923@MBVM.Mitre.Org (Daniel Sorensen)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote printing from JES2 spool


 
In article <IBMTCP-L%92110411450390@PUCC.PRINCETON.EDU>
David Condrey 656-2733 <DAVIDC@CLEMSON.BITNET> writes:
 
>
>At the last SHARE, I brought up the fact that our TSO users are used to
>printing by releasing sysout off of spool (in addition to using a TSO
>"print" command) and that I wanted to allow these users to be able to
>use printers remote to MVS.
>
>The specific problem that we are having is that we have a plotter on
>the network that our MVS users want to plot to via SAS/GRAPH. SAS users
>run batch jobs and release the output from spool (in our case using IOF).
>
>The foremost answer seems to be defining a remote printer to LPD.
>However there is currently no way for LPD to get output from spool
>and do the right things with it (retry on failure).
>
>When I mentioned this, someone in the back stood up and said that he was
>solving this using a product called VPS (sic). Since then, we have
>bought VPS. I have not personally looked at it, but our network manager
>says that the VPS people indicated there is no solution to our problem.
>
>My question is: if you have solved this problem (or have any thoughts
>on it), I'd really like to hear them. If the person that mentioned VPS
>at the TCP/IP FFA is listening, I'd like to ask a few questions.
>
>Thanks everyone.
>-David
>-------------------------------------------------------------------------------
>|David S. Condrey           ___  ______ _____    Bitnet: DAVIDC@CLEMSON       |
>|MVS Systems Programmer     |  \ \_____ |        Internet: DAVIDC@CLEMSON.EDU |
>|Clemson University         |__/ _____/ |____    Phone: (803) 656-2733        |
>-------------------------------------------------------------------------------
 
  It seems from the responses so far that VM shops have resolved the batch
network printing problem by using service machines.  In fact, MITRE is
currently the same technique.  Our MVS machine sends the file to a VM
service machine, which in turn sends the files out using LPR.  The problem
is that we will soon be phasing out the VM machine.
 
  Has anyone found a MVS only solution to batch network printing?  Even
if VPS can use LPR in batch, it is too expensive.  If there is no TCP/IP
solution to network printing, our next solution would be to look into
NJE-type links to an RS/6000 and letting it deal with the actual printing.
Any ideas?
 
Daniel Sorensen
IBM Systems Group
The MITRE Corporation
(617) 271-2726
 
What, me speak for MITRE?  Ha!

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 19:35:18 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>I don't disagree with your statements, however, I was curious about
>the systems you execute on.  Specifically, when a process is
>terminated, what happens to the open file descriptors?

So your claim is that if i use such an operating system, then i must
agree this behavior is correct.  Sorry.  Operating systems that aren't
brain dead (most, unfortunately, no longer in production) understand
that the file system's state shouldn't be changed unless the file
manipulation is completed, which the application typically indicates
by explicitly closing the file.  On such operating systems,
terminating a process (or crashing the machine, for that matter)
leaves the *original* file unchanged, or leaves no file at all if
there was no original file.  In almost all cases, leaving a partially
written file is absolutely the least desirable end result.  But, as
most everyone else, i'm forced to use both UNIX and DOS even though
they both have this fault.

>Aren't they typically "closed"?  Doesn't TCP typically map this into
>a "normal connection close"?

And your claim here is that since UNIX believes that it understands
how to gracefully close file descriptors, then it's OK for it to close
TCP connections gracefully as well.  Hard to argue with that if you
truely believe UNIX defines TCP/IP.  Even so, it's a shame to lose the
useful meaning of a graceful close just because one common operating
system thought it knew everything there was to know about any possible
TCP application.

>I assume that you would inject an RST in cases
>where you could prove "abnormal termination".  Can you cite an RFC
>which gives guidelines as to when TCP should inject an RST on behalf
>of the application?  I'm sure we would benefit from clean, consistent
>implementations.  

To my knowledge, no RFC deals with what TCP should do if its
application disappears.  Personally, i think that's because no one
ever conceived of the UNIX behavior as a possibility, anymore than
they thought an operating system might tend to send "Th-Th-That's all
folks!" spontaneously down the TCP pipe.

But if we take RFC-793 as gospel (and why not?), since it doesn't
mention process termination at all, my conclusion then is that the TCP
implementation should do nothing: the connection simply disappears.
No FIN, no RST, no nothing.  Then any subsequent packets from the
other end of the connection would be for a non-existent connection, so
TCP would respond with a RST.  In practice, in order to expedite the
remote node's awareness of the situation, TCP sends a RST immediately.
This isn't significantly different than doing nothing, since it's just
what would happen if an old packet arrived or something like that.

						don provan
						donp@novell.com

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 20:19:41 GMT
From:      dank@blacks.jpl.nasa.gov (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Should connect() block after setting NDELAY?


Hi all,
I'm writing an application that opens sockets to many servers in parallel
before sending out a query to each server (also in parallel).  It sets
the sockets into nonblocking mode before the connect() as follows:
	int flags;
    #ifdef USE_FIONBIO
	flags=1;
	netioctl(qp->fds, FIONBIO, (char *)&flags);
    #else
	flags = fcntl(qp->fds, F_GETFL, 0);
    #ifdef USE_O_NDELAY
	flags |= O_NDELAY;
    #else
	flags |= FNDELAY;
    #endif
	fcntl(qp->fds, F_SETFL, &flags);
    #endif
The problem is, under SunOS 4.1.1, connect() then blocks until a 
accept, reject, or defer response comes back from the server.
This can take several seconds if the Internet is being slow.
The local Sun guy was able to see this in the source code, but does not
consider it a bug.  What do you all think- is it reasonable for connect()
to block for several seconds when the socket is supposedly in nonblocking
mode?
- Dan Kegel (dank@blacks.jpl.nasa.gov)

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 21:07:59 GMT
From:      bryan@sphinx.phys.Virginia.EDU (bryan wright)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Problems with PC-NFS and pktd.sys

Hi folks,
	I've just installed PC-NFS version 4.0.  Everything works fine
if I use the WD8003E.SYS driver, but when I try to substitute PKTD.SYS
and the WD8003E.COM packet driver, NFS refuses to start.   I get the
message:

  NFS000F : PC-NFS is disabled. (Can't start network. Check configuration.)    

I think WD8003E.COM is OK, since NCSA telnet has no problems talking to
the outside world.

	I've created a minimal CONFIG.SYS and AUTOEXEC.BAT for test purposes.
These files are appended below.  Am I doing something stupid?

				Thanks in advance,
				Bryan

CONFIG.SYS =================================================================

BREAK=ON
BUFFERS=30,8
FCBS=30,10
FILES=40
STACKS=0,0
DEVICE=C:\DOS50\ANSI.SYS /X
DEVICE=C:\UTIL\MOUSE\MOUSE.SYS
INSTALL=C:\NET\DRIVERS\WD8003E.COM -W 0X60 5 0X280 0XD000
DEVICE=C:\NFS\PCNFS.SYS
DEVICE=C:\NFS\SOCKDRV.SYS
rem DEVICE=C:\NFS\WD8003E.SYS /I5
DEVICE=C:\NFS\PKTD.SYS 
SHELL=C:\COMMAND.COM /P /E:1024
LASTDRIVE=V

AUTOEXEC.BAT ================================================================

@ECHO OFF
PATH C:\;C:\DOS50;C:\BATCH
DOSKEY/INSERT
PROMPT $P$G
SET TEMP=C:\DOS50\TEMP

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


 

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 21:17:58 GMT
From:      rjberke@berke.itg.ti.com (Richard Berke)
To:        comp.protocols.tcp-ip
Subject:   Transfer of 100's of MBytes files

What are some customers' experiences with transfering large files
between sites using FTP?  

How often (1 out of 20?) do you run into aborted transfers that 
have to be restarted from scratch?  Have you been able to distinguish
what portion of those failures are due to disk issues, circuit failures,
or protocol implementations?

I am frequently asked about the reliability of using FTP to move
files and/or sets of files that are 200-400 Mbytes, and there's interest
in some means of recovering from a disruption in the middle of a transfer.

I'm sensitive to disruptions, but wary of exotic schemes to recover.
Since our world-wide links are as small as 56 Kbits/sec, transmission times
are significant.  Good throughput for FTP (not best case) is about 5 Kbytes
per second.  200-400 Mbytes takes 1-3 hours or more.  Detection of failed 
transfers may be delayed, further adding to wall clock time taken to 
accomplish the overall transfers.

I've heard that protocols exist for transfers that use checkpoints and 
can restart.  I've never heard of mainstream suppliers for them.
Are they available?  How necessary are they, compared to FTP?

Thanks,

Richard Berke   RBRK   Richard.Berke@lobby.ti.com  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 21:24:24 GMT
From:      fsgreen@dredd.lerc.nasa.gov (Doug Greenwald)
To:        comp.protocols.tcp-ip
Subject:   Need Ethernet types/IP Frame and Header Formats

Howdy,

I'm writing a small network analyzer to gather statistics.  I have most of the
IP protocols in Comer's book done but am having problems finding information
regarding a bunch of the ethernet types.  I'm seeing a LOT of ethernet types
that fall into the "experimental" range of RFC 1060 and am wondering if there
are any more complete lists of assigned numbers.  I need the type field of the
ethernet frame for general statistics gathering and would like the higher layer
protocol packet formats for completeness.

Any pointers to references or information you could shed would be appreciated.

For those interested in the program, I'm writing it for Sun workstations.  If
responses warrant (and the program doesn't turn into a load of crap), I'll 
make it available.


-- 
Doug Greenwald                       fsgreen@icomp01.lerc.nasa.gov
Sun System Administrator             (216) 433 5965
ICOMP, NASA Lewis Research Center

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 92 21:30:39 GMT
From:      braun@dri.com (Karl T. Braun (kral))
To:        ca.unix,comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards,comp.dcom.lans.ethernet
Subject:   IP Remap Experiences wanted



I am looking for any information on large scale institutional IP addresses
remapping - papers, anecdotes, sage advise, whatever.  Please email anything
you care to contribute to 

		braun@novell.com

I am preparing to undertake this "exciting" adventure myself, and hope to gain
from other's experiences.  I will, in turn, document my own experiences and
include what useful info I gather from the net with appropriate references.

Thanx,

-- 
kral   408/645-2031                                                braun@dri.com
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

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 21:47:40 GMT
From:      deraadt@newt.cuc.ab.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun Generic Broadcasting

[Distribution changed from "usa" to "world". Unix is the same in Europe, isn't it??]

In article <1004@math.math.mv.dupont.com> mc@math.math.mv.dupont.com (Matt Cunningham-Software Development) writes:
> I am trying to find the proper broadcast IP address to send a packet (BOOTP 
> packet to be specific - but the packet type is not important) to so that
> everyone on the network will receive it.
[deleted descriptions of numerous attempts to make it work...]

The bind() call will take INADDR_ANY to indicate that it will take a
connect from any address. It's more difficult when you send packets
out -- you must indicate _exactly_ where you want to send to. A
unix machine may have multiple interfaces, with multiple addresses.
You need to specify the broadcast address for the particular network
you are interested in. If you wish to send on all the attached networks,
you need to do multiple send()'s.

The program below will list the broadcast addresses for all of the
networks that your machine is directly connected to. It will skip
LOOPBACK and POINTTOPOINT links, simply because those do not have a
broadcast address. For your problem, just sendto() each address that
is discovered by this routine below..

Note that on some machines you'll need to enable broadcasting before
packets will actually make it onto the wire. You don't need this on
Suns, but it does now hurt. Other machines (ie. SGI) DO need it.

        if( (sock=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
                perror("socket");
                return -1;
        }
	i = 1;
        setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &i, sizeof(i));

On some operating system (Ultrix?) only root processes can broadcast,
what a crock.

Hope this helps you.
 <tdr.

----------------------------------------------------------------------
#include <sys/param.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/signal.h>
#include <sys/file.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <net/if.h>
#include <netinet/in.h>
#include <dirent.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>

main()
{
	struct ifconf ifc;
	struct ifreq ifreq, *ifr;
	struct sockaddr_in *sin;
	struct in_addr in;
	struct net *n;
	int i, sock;
	char inbuf[1024];

	if( (sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
		perror("socket");
		return -1;
	}

	ifc.ifc_len = sizeof inbuf;
	ifc.ifc_buf = inbuf;
	if( ioctl(sock, SIOCGIFCONF, (char *)&ifc) < 0) {
		close(sock);
		perror("ioctl");
		return -1;
	}
	ifr = ifc.ifc_req;
	for(i=ifc.ifc_len/sizeof(struct ifreq); i>0; i--, ifr++) {
		ifreq = *ifr;
		if( ioctl(sock, SIOCGIFFLAGS, (char *)&ifreq) < 0) {
			perror("ioctl");
			continue;
		}
		if( (ifreq.ifr_flags & IFF_BROADCAST) &&
		    (ifreq.ifr_flags & IFF_UP) &&
		    ifr->ifr_addr.sa_family == AF_INET) {
			sin = (struct sockaddr_in *)&ifr->ifr_addr;
			if( ioctl(sock, SIOCGIFBRDADDR, (char *)&ifreq) < 0 ) {
				in = inet_makeaddr(inet_netof(sin->sin_addr.s_addr),
					(int)INADDR_ANY);
			} else { 
 in = ((struct sockaddr_in*)&ifreq.ifr_addr)->sin_addr;
			}
 printf("address %s\n", inet_ntoa(in));
		}
	}
 close(sock);
}
----------------------------------------------------------------------
--

This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 21:51:43 GMT
From:      mr@ogre.cica.indiana.edu (Michael Regoli)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   ODIPKT Freezes with my Accton EtherCombo-32


I'm having difficulty with ODIPKT on a 486/50 EISA machine, and was
wondering if anyone else is in this boat with me as well.  ;)

I've got a nice little net.bat file that loads lsl, ec32mlid,
ipxodi, and bnetx (burst).  That all works fine.  And I can connect to
LAN servers like crazy.  However, the TCP/IP side is a bit more
sticky.   

Has anyone a packet driver for this card???  

Thanks for the help!

--
michael regoli
mr@cica.indiana.edu
regoli@indiana.BITNET
..{ames, rutgers}!iuvax!cica!mr

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 22:16:17 GMT
From:      stewart@ra.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Need Ethernet types/IP Frame and Header Formats

In article <1992Nov5.212424.15228@eagle.lerc.nasa.gov> fsgreen@dredd.lerc.nasa.gov (Doug Greenwald) writes:
>I'm writing a small network analyzer to gather statistics.  I have most of the
>IP protocols in Comer's book done but am having problems finding information
>regarding a bunch of the ethernet types.  I'm seeing a LOT of ethernet types
>that fall into the "experimental" range of RFC 1060 and am wondering if there
>are any more complete lists of assigned numbers.  I need the type field of the
>ethernet frame for general statistics gathering and would like the higher layer
>protocol packet formats for completeness.

See RFC 1340 which obsoletes RFC 1060.

/jws

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 23:00:01 GMT
From:      jamesd@techbook.com (James Deibele)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Limited telnet program?

I would like to set up a limited telnet program for people to use.
Specifically, I'd like to provide local librarians a way of telneting to
selected online library catalogs via a menu.  If the telnet to that site
fails, I would want the telnet program to exit with an error level,
which I could then catch with a shell or program.  I don't want people
who use this account to be able to exit to a shell from within telnet,
and I don't want them to be able to telnet elsewhere.

If someone has seen a program like this, or has a reason why this is a
bad idea*, I'd like to hear about it.  It seems like it should be
reasonably secure for both us and the rest of our Internet neighbors.

Thanks.

*Please no criticism about how we should give free shell accounts to
anyone who asks for one unless you're prepared to contribute hardware.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 1992 23:35:23 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: Should connect() block after setting NDELAY?

In article <dank.720994781@blacks> dank@blacks.jpl.nasa.gov (Daniel R. Kegel) writes:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel).  It sets
>the sockets into nonblocking mode before the connect() as follows:
>	int flags;
>    #ifdef USE_FIONBIO
>	flags=1;
>	netioctl(qp->fds, FIONBIO, (char *)&flags);
>    #else
>	flags = fcntl(qp->fds, F_GETFL, 0);
>    #ifdef USE_O_NDELAY
>	flags |= O_NDELAY;
>    #else
>	flags |= FNDELAY;
>    #endif
>	fcntl(qp->fds, F_SETFL, &flags);
>    #endif
>The problem is, under SunOS 4.1.1, connect() then blocks until a 
>accept, reject, or defer response comes back from the server.
>This can take several seconds if the Internet is being slow.
>The local Sun guy was able to see this in the source code, but does not
>consider it a bug.  What do you all think- is it reasonable for connect()
>to block for several seconds when the socket is supposedly in nonblocking
>mode?
>- Dan Kegel (dank@blacks.jpl.nasa.gov)

I use this chunk of code (SunOs 4.1) and have no problem blocking

    if ((d_ptr->fid = socket(AF_INET,SOCK_STREAM,0)) < 0)   /* make socket */
    {
      err_log(WARNING, ERRNO, "Making dbs socket");
      continue;
    }   
 
 
    if (fcntl( d_ptr->fid, F_SETFL, FNDELAY) == -1)
    {
      err_log(WARNING, ERRNO, "can't set socket to non blocking");
      close(d_ptr->fid);
      continue;
    }   
 
    if (fcntl( d_ptr->fid, F_SETFD, 1) == -1)
    {
      err_log(WARNING, ERRNO, "can't set socket to close on exec");
      close(d_ptr->fid);
      continue;
    }   
 
    if(connect(d_ptr->fid,(struct sockaddr *)&sock,sizeof(sock)) == 0)
    {
			/* connected */
      FD_SET(d_ptr->fid, write_fds);
      d_ptr->status = CONNECTED;
      break;
    }   
 
 
    if ( errno == EINPROGRESS )
    {
      FD_SET(d_ptr->fid, connect_fds);
      d_ptr->status = CONNECT_PENDING;
      break;
    }   

		.
		.
		.


-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Nov 1992 01:40:19 GMT
From:      nigel@cnw01.storesys.coles.oz.au (Nigel Harwood)
To:        comp.protocols.tcp-ip
Subject:   TCP over X.25 TELNET performance

I have recently started using TCP over X.25 with the WIN-TCP product.
When using TELNET to log into a remote system using a 2400BPS line
performance is very bad, especially for what I enter locally at the
keyboard.  This is obviously because a whole packet is being constructed
for each character I type.

So, before I enter into a long and drawn out experimentation session has
anyone dealt with this problem already?  Perhaps, combinations of local
echo, buffering, line mode etc would acheive better through put?

Any help appreciated.

Regards
-- 
<<<<<<<<<<<<<<<<<<<<<<<<<  Nigel Harwood  >>>>>>>>>>>>>>>>>>>>>>>>>>>
<< Post:  Coles Supermarkets, PO Box 480 Glen Iris 3146, Australia >>
<< Phone: +61 3 829 6090  E-mail: nigel@cnw01.storesys.coles.oz.au >>
<<   FAX: +61 3 829 6886                                           >>

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 01:58:54 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Bootleggers


We have the occasional problem of people, for whatever reason, choosing an
IP number and getting on our network.  Since IP numbers are as free as the
air and about as easy to get, there is no good reason for somebody to do 
this.  Does anybody know of anything that one can do to, essentially, make
life miserable for these bootleggers?  Needless to say, I don't want to
do anything that would disrupt the network for decent folks who are going
about their business, but I truly want to discourage people from this practice
since it has the potential for causing some systems to crash if somebody
picks a duplicate number.  Since the same things that could be used to
torment a bootlegger could be misused to disrupt anybody, maybe you should
just E-mail me.  Thank you.

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

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 03:51:54 GMT
From:      bill@solaria (Bill Neisius)
To:        comp.protocols.tcp-ip
Subject:   SLIP connection to XYPLEX on modem


OK, I give up. 

I'm trying to connect a modem to a XYPLEX 1500 server....
and run SLIP.  It works fine when I connect the local ISBN phone 
network to the server; but when I connect a modem, all I get on the
remote machine is 'bad IP checksum' or 'can't open connection, timeout'.

I'm using SLIP8250 and TELBIN on the remote PC; modem on the server is
a MultiTech v.32, on the PC it's a DigiCom Scout+.  Connection is at
9600 baud/V42.

I can see 'ping' packets arrive at the PC, but something is missing
'cause they generate 'bad IP checksum' in TELBIN.  If I try to open
a connection, I get a 'timeout' almost immediately... 

So what's the deal?  Flow control?  The XYPLEX has only 8 wires in its
serial connection, so you get DCD/DTR or CTS/RTS, but not both. Does
SLIP work with XON/XOFF?  well...I guess so, cause it works with the
ISBN 'modem'....

Any suggestions?

Bill Neisius
bill@solaria.hac.com



-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 NOV 92 13:01:34 EST
From:      murphy@hal.hahnemann.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Limited telnet program?

In a previous article, jamesd@techbook.com (James Deibele) wrote:
>I would like to set up a limited telnet program for people to use.
>Specifically, I'd like to provide local librarians a way of telneting to
>selected online library catalogs via a menu.  If the telnet to that site
>fails, I would want the telnet program to exit with an error level,
>which I could then catch with a shell or program.  I don't want people
>who use this account to be able to exit to a shell from within telnet,
>and I don't want them to be able to telnet elsewhere.
> 

Mark Resmer at Sonoma State University has written both a VMS 
DCL command procedure and some sort of shell script for accessing 
libraries and databases on the Internet.  Both are available via 
anonymous ftp in the /pub directory on sonoma.edu.  You might want 
to take a look these before you roll your own...

Regards,

John


 -----------------------------------------------------------------------------
              |John Murphy  (JM66)     |Internet: murphy@hal.hahnemann.edu
   /   / /   /|Library System Manager  |VMS Mail: HAL::MURPHY
  /---/ /   / |Hahnemann University    |Beeper #: 1864
 /   / /___/  |245 N. 15th St., MS 449 |Voice:    (215) 762-1042
              |Phila., PA 19102-1192   |Fax:      (215) 762-8180
 -----------------------------------------------------------------------------
 "It's a small world, but I wouldn't want to have to paint it" - Steve Wright

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Nov 1992 09:13:07 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.unix.admin,comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: inetd configuration questions

lucien@watson.ibm.com (Lucien Van Elsen) writes:

>>I have noticed in the "Diskless Workstation Management Guide", when
>>referring to changing inetd.conf, that the command "inetimp" is omitted from
>>the instructions. Does 3.2 now not use the ODM for inetd?
 
>"refresh -s inetd" causes an "inetimp" to occur, and I believe this was true
>under 3.1 as well.  However, this doesn't seem to be a documented feature
>anywhere, so I wouldn't rely on it in the future.

You're right, it does. I'll have to pull my tongue back out of my cheek :)

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Nov 1992 14:46:45 +0000
From:      dblack@ccla.demon.co.uk (David Black)
To:        comp.protocols.tcp-ip
Subject:   No subject

Re: Remote Printing from JES2 Spool

I'm not too sure if this is relevant:

We managed to get remote printing via JES 328X onto remote printers
using OS/2 machines running ES this will give you 5 LU's. These were
then addressed as remote printers from within JES.

We also got unix devices to share the same printers by setting up
the TCP/IP for OS/2 running as a TFTP server and TFTP'ing the spool
file to the LPTX port on the PC.

/DB

=
David Black             49 Woodgrange Drive     dblack@ccla.demon.co.uk
Crucible Computers      Southend On Sea         dblack@cix.compulink.co.uk    
Networking Consultant   Essex UK SS1 2SD        Flies AA5B G-NGBI
                                

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 14:49:40 GMT
From:      tas@concert.net (Tim Seaver)
To:        comp.protocols.tcp-ip
Subject:   TCP source for binary Ultrix and SunOS


I've been working with TCP on binary SunOS 4.1.1/4.1.2 and
Ultrix 4.1 RISC hosts for several months, and I'm making the
source code I use available in case other folks would like to do
the same. The TCP implementation is based on the 4.3 BSD Reno
release, with the RFC1323 High Performance extensions added.
The RFC1323 implementation is based on code from Thomas Skibo,
done at the University of Illinois at Urbana-Champaign.

The TCP source code, adapted to fit into a binary kernel
distribution, is available for anonymous ftp from ftp.concert.net
as dist/tcp.sunos4.1+.tar and dist/tcp.ultrix4.1.tar. This
code is experimental, but has been running on my DECstation
5000 workstation and a production Sparc-2 server for several
weeks without problems.

If you use this code, please let me know of any problems you
run into and any changes you find necessary to bring it up
on other hardware or OS versions.

Thanks,

	Tim Seaver
	CONCERT Network
	MCNC Center for Communications
	tas@concert.net

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 17:39:36 GMT
From:      tm8t+@andrew.cmu.edu (Tod McQuillin)
To:        comp.protocols.tcp-ip
Subject:   Re: Transfer of 100's of MBytes files

rjberke@berke.itg.ti.com (Richard Berke) writes:
> How often (1 out of 20?) do you run into aborted transfers that 
> have to be restarted from scratch?

Pretty often.  Especially with large files transferred over a SLIP
link.  I'd say 1 out of 50 times over SLIP, and 1 out of 200 on more
permanent connections.

>				      Have you been able to distinguish
> what portion of those failures are due to disk issues, circuit failures,
> or protocol implementations?

In my experience, TCP is an extremely reliable protocol.  Aborted
transfers are almost always caused by network hardware problems, or
routing difficulties.

> I am frequently asked about the reliability of using FTP to move
> files and/or sets of files that are 200-400 Mbytes, and there's interest
> in some means of recovering from a disruption in the middle of a transfer.

You can always check that the transfer was successful by taking the
checksum of the data on both ends.  The more recent implementations of
the FTP protocol I've seen all support the "reget" command (I believe
the FTP spec calls this "RETR") which allows you to resume an
interrupted transfer.  I use it all the time and have never had a
problem with it.

> I'm sensitive to disruptions, but wary of exotic schemes to recover.

I'd hardly call the reget command exotic.

> Since our world-wide links are as small as 56 Kbits/sec, transmission times
> are significant.  Good throughput for FTP (not best case) is about 5 Kbytes
> per second.  200-400 Mbytes takes 1-3 hours or more.  Detection of failed 
> transfers may be delayed, further adding to wall clock time taken to 
> accomplish the overall transfers.

You have a point there.  The reget command does not automatically work
-- you have to type it yourself.

> I've heard that protocols exist for transfers that use checkpoints and 
> can restart.  I've never heard of mainstream suppliers for them.
> Are they available?  How necessary are they, compared to FTP?

I've never had a need for something like this, but then, it sounds
like your data-moving requirements are more demanding than mine.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 17:46:54 GMT
From:      tm8t+@andrew.cmu.edu (Tod McQuillin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP connection to XYPLEX on modem

bill@solaria (Bill Neisius) writes:
> OK, I give up. 
> 
>			... but when I connect a modem, all I get on the
> remote machine is 'bad IP checksum' or 'can't open connection, timeout'.
>
> [...]
> 
> I can see 'ping' packets arrive at the PC, but something is missing
> 'cause they generate 'bad IP checksum' in TELBIN.  If I try to open
> a connection, I get a 'timeout' almost immediately... 
> 
> So what's the deal?  Flow control?  The XYPLEX has only 8 wires in its
> serial connection, so you get DCD/DTR or CTS/RTS, but not both. Does
> SLIP work with XON/XOFF?  well...I guess so, cause it works with the
> ISBN 'modem'....

SLIP *does not* work with XON/XOFF flow control.  IP is a binary
protocol, and if I want to send you a packet full of XOFF's, you had
better be prepared to accept it.  If your modems are set up to respond
to XON/XOFF flow control, then SLIP will not work for you -- that's
all there is to it.

Since you said you were using error-correcting modems (and presumably
data-compression as well), this implies your throughput is not the
same as the DTE data rate.  So you will need some form of flow
control, unless you're prepared to suffer from severe data lossage
which will cause all kinds of TCP retransmits and make most udp
applications unhappy as well.  From the description of your equipment,
you need to use RTS/CTS flow control.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 06 Nov 92 19:10:36 GMT
From:      regina@netronix.com (Regina Clarke)
To:        comp.protocols.tcp-ip
Subject:   Subnet Masks

Internet : regina@netronix.com
USENET   : uunet!netronix!regina
fax      : (707) 763-6291
phone    : (707) 769-3300
U.S.Mail :  Regina Clarke
            Netronix, Inc.
            1372 N. McDowell Blvd.
            Petaluma CA 94954

Would like information on subnet masks--function, any glitches from end-user p.o.v. and why fixed, contiguous addressing necessary or advisable?


-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 21:16:29 GMT
From:      pstevens@Metaphor.COM (Paul Stevens)
To:        comp.protocols.tcp-ip
Subject:   Determining the hop count to a net or sub-net

I've read how traceroute works: UDP packets retransmitted with greater
Time-To-Live values which result in ICMP packets back from each
router along the way.  I'm wondering if there is any lighter-weight
techinque for determining some kind of distance metric for a destination.
I am also interested to know if there is anything around that is done
as a function that can be called rather than a program that display
information on stdout.
+------------------------------------------------------------------------+

   Paul Stevens                        {apple|decwrl}!metaphor!pstevens
   Metaphor Computer Systems           pstevens@metaphor.com
   Mountain View, CA

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Nov 1992 21:17:02 GMT
From:      mac@unison.com (Michael A. Casteel)
To:        comp.protocols.tcp-ip
Subject:   Looking for PC network trace software

On the odd occasion when I'm really puzzled over a network
application problem, tcpdump or etherfind would be nice. But,
I don't have either of those on my HP-UX; seems more like a
good PC application anyway. Is there a PC version of Ethernet
trace software available for ftp?

Thanks.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Casteel                      Unison Tymlabs
mac@unison.com    		  675 Almanor Ave., Sunnyvale, CA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 92 22:08:11 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc process chewing up resources

In article <DERAADT.92Nov5044404@newt.newt.cuc.ab.ca>, deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
|> I'm currently implimenting YP client functionality for 386bsd. So far,
|> it's been an enjoyable and frustrating time....
|> 
|> In article <49256@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
|> >  |> > |> > sits within the "yp" library code (you need to ask SUN why "pinging"
|> >  |> > |> > the portmapper from within "yp" is useful).  This has the wonderful
|> >  |> > |> Hmmmph!
|> >  |> > |> What would you do if you wanted to discover if ypbind is running?
|> 
|> Well, on some systems (including my code at the moment) that's exactly
|> why TCP is used. It's faster than UDP.

Please explain how TCP is "faster" than UDP.  You are sending one request
and getting one reply.  This is an unfragmented request/reply sequence,
in the case discussed in this thread.  TCP adds an end-to-end
connect sequence besides sending the request and receiving the response.
I'd like to know which systems you use which can create a connection
and send a message faster than you can just send the message.

There are many reasons to use TCP but your comment on "faster"
is obviously missing some relevant context information.

|> 
|> My first code used UDP to find out if ypbind was running. Well, if you
|> don't get an answer, even in talking to 127.0.0.1, well, the kernel's
|> buffers could just be swamped at the moment. So you have to try a few
|> times. Not pretty.

If there are no kernel buffers you can't create a TCP connection
either.  The case where UDP suffers is when concurrent request
information overflows the receive socket.  In the case we are
talking about this isn't a major concern (i.e. small packets and
short think time in server.  Additionally, vendors selling useful
multi-user systems provide reasonable buffer sizes).  Consequently,
overflowing the TCP connect limit would be roughly 
equivalent to the UDP receive buffer limit.

NOTE - In case you missed, the TCP connection in question is directed 
to the portmapper not to ypbind.

|> 
|> So, I started using TCP. Immediate response yes/no whether YP is
|> running. I had no real concerns with whether the portmapper is
|> running.
|> 
|> I'm have a Sun too. A few minutes ago, I went and looked to see why
|> the file /etc/ypbind.lock exist... a bit of snooping and following a
|> hunch...
|> 
|>   4835 -rw-------  1 root            0 Nov  2 21:46 /etc/ypbind.lock
|>   ^^^^
|>  inode
|> 
|> pstat -i | grep 4835
|>  f23f9a8    R     7,  0  4835 100600   1    0         0   E     2   0   1 VREG
|> 							  ^^^
|> That little 'E' is an exclusive lock.
|> 
|> Could someone explain exactly what is going on here? What I suspect
|> follows: ypbind maintains the exclusive lock on /etc/ypbind.lock
|> Processes that are interested can find out if ypbind is running by
|> doing a lockf(fd, F_TEST).  Sun's ypbind also puts an exclusive lock
|> on /var/yp/binding/domainname.2 and /var/yp/binding/domainname.1.  I
|> suspect the 2 is YPBINDVERS.
|> 
|> Just trying to get a flock() on that file seems to work. This is so much
|> easier than what it appears the entire argument here is about.
|> 
|> Here's what happens if I trace a program that needs to check YP.
|> 
|>     open ("/var/yp/binding/cuc.ab.ca.2", 0, 036736173730) = 4
|>     flock (4, 06) = -1 EWOULDBLOCK (Operation would block)
|>     mmap (0x8ab8, 14, 0x1, 0x80000001, 4, 0) = 0xf7710000
|>     close (4) = 0
|> 
|> Aha. The fact that the flock() failed tells us that ypbind is running.
|> Sun places into the binding file the actual (struct sockaddr_in) at
|> which the current ypserver can be found (It could be ypbind's address,
|> but it makes more sense to be ypserv's address). So they mmap() the
|> (struct sockaddr_in) and continue.
|> 
|> >  |> > 
|> >  |> > I would send a UDP RPC request to the portmapper to find out
|> >  |> > if ypbind was registered.  The problem is that there is code
|> >  |> > which creates a "dummy" TCP connection just to see if the
|> >  |> > portmapper is running (i.e. doesn't trust UDP time-outs as 
|> >  |> > sufficient evidence that the portmapper is not running).
|> 
|> I would not trust a UDP timeout on "localhost" as meaning that the
|> portmapper is dead. It might take 5 seconds for a busy portmapper to
|> answer. Someone in Timbuktu, at the end of a very slow link, may have
|> been spraying the portmapper. Packets may have convoyed, and the
|> portmapper may be swamped! How long are you going to wait around?

Why do you assume that this same phantom you fear cannot spray the
portmapper with bogus TCP connections?  You will find that the same
quantity of bogus TCP connections are generally worse than bogus UDP 
packets.  People with this level of paranoia typically deploy firewalls.

Also, you seem to be disillusioned about what happens when a TCP
packet gets dumped on the ground.  You will note that it has a
regressive back-off timer with the lowest retry level at
approximately one second.  What TCP gives you is a well-respected
retry algorithm which may not always be present in various UDP
applications.

The advantage that was hypothesized for TCP (in this particular
thread) is that the UDP/ICMP "port not available" (i.e. no server currently
bound to the specified port) may not be as well supported as the
equivalent TCP RST functionality.  If your application has some
semantical benefit gain from this feature then TCP might be
a better choice. 

|> 
|> >  |> > If the connection succeeds, it is immediately closed and then
|> >  |> > the UDP RPC request is made to the portmapper to get the 
|> >  |> > information about ypbind.
|> >  |> 
|> >  |> Perhaps my point was not clear.
|> >  |> 
|> >  |> By using TCP you avoid having to wait for a UDP time-out to expire when
|> >  |> things are not present.  Which would make you more unhappy?  Having an
|> >  |> anonymous TCP port number tied up for a little while or having to wait
|> >  |> a large part of a second (or more if you allow remote access over slow
|> >  |> links) to discover that the portmapper is not running?
|> 
|> With TCP, your connection will succeed immediately, well, as long as
|> the listen queue has room for you....
|> 
|> 
|> Really, I prefer Sun's method of checking for yellow. A flock() on a
|> locked file means you are talking to an inode that is already in the
|> buffer cache. That's got to be faster and more reliable than talking
|> to portmap & ypbind.

As long as everything is local you can reliably use files for
interlocking, however, I would not be overly enthused to see rpc.lockd
as the cornerstone for provision of these services (e.g. you ever needed
to solve a remote concurrency issue).

|> 
|> Anyways, I'm going to impliment my routines much like Sun's did!
|> 
|> Only one thing bothers me with the RPC programming I am doing. Sun's
|> ypbind is not multithreaded; rather, it forks when it gets a request
|> for a currently unbound domain. I decided to make my ypbind much more
|> multithreaded. What I have come to discover to my disgust is that if
|> you wish to write a properly multithreaded RPC application you have to
|> give up all the juicy RPC and SVC routines and dig right into the XDR
|> level. What a pain. And, boy, I could scream because I have found no
|> way to access msg->msg_xid from the SVC/RPC level! For a proper
|> multi-threaded application, you are going to need to save a copy of
|> that for the later reply!
|>  <tdr.
|> --

  
One technique is to use request-only primitives (e.g. use timeout==0) to satisfy
multi-threading needs.  However, since you probably want to interoperate
with existing ypbind entities this probably won't help much.


|> 
|> This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Nov 92 00:58:55 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   Re: Who supports multicast? (summary of responses)

In article <1992Nov2.190805.23351@PA.dec.com> I wrote:
>And if you want IP multicast support in ULTRIX or OSF, you might consider
>calling your DEC salesperson and saying so.

Some people have expressed little faith in the utility of this approach.
Try this instead: send email to Gail Grant (grant@pa.dec.com), who
might have some effect (and who knows more than a little about the
Internet).

Please send Gail concise, friendly messages explaining why you think DEC
should support IP multicast (or why not, I guess).  In particular,
you might want to describe specific applications that require multicast,
rather than just "it's a good thing."

No promises, of course.

-Jeff



-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Nov 1992 03:44:06 GMT
From:      eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
To:        comp.protocols.tcp-ip
Subject:   Proper Method of Closing IP Sockets

	What is the proper method of closing a socket in order to release
the socket/port binding?  Under SunOS 4.1, my application closes its
descriptors and exists.  If I immediately execute it again, the bind fails
with errno EADDRINUSE.  Eventually, operating system figures out that
the old process is defunct, but I would like to do this properly.

	The server process just does the standard socket/bind/listen/accept
song-and-dance:

		sin.sin_family = AF_INET;
		sin.sin_port = htons(PORTNUM);
		sin.sin_addr.S_un.S_adder = INADDR_ANY;

		s = socket(AF_INET, SOCK_STREAM, 0);
		bind (s, &sin, sizeof(sin));
		listen(s,5);
		con = accept(s, &fsin, &conlen);

		/*  Fool around with the socket. */

		close(con);
		close(s);

		exit();

	What am I missing here?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jack Eifrig (eifrig@cs.jhu.edu)       The Johns Hopkins University, C.S. Dept.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Nov 1992 04:14:30 GMT
From:      ae2@cunixb.cc.columbia.edu (Amiran Eliashvili)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client source


Hi all:

I have a rather specific question that have been intriguing me for
few days now. I am trying to implement a fault tolerant system based
on the Client/Server model. The nature of the system is to detect if
either ends has been terminated. If it has been terminated abnormally
the system will react accordingly.

I am using BSD sockets in order to establish a link between the server
and the client, using SOCK_STREAM (TCP) as my protocol. I am able to
detect when the other side has been terminated by a SIGKILL, SIGQUIT,
as writing to the socket on the other side sends a SIGPIPE. Yet, when
the machine has been turned off manually I don't get anything even
though I have tried setting setsockopt(SO_KEEPALIVE)

[Man page exerb ]

     SO_KEEPALIVE enables the periodic transmission of messages on a
     connected socket.  Should the connected party fail to respond to
     these messages, the con- nection is considered broken.  A process
     attempting to write to the socket receives a SIGPIPE signal and
     the write opera- tion returns an error.  By default, a process
     exits when it receives SIGPIPE.  A read operation on the socket
     returns an error but does not generate SIGPIPE.


to setsockopt(SO_LINGER) but none has worked for me. I was wondering
if anyone else has encountered in the problem. If so how did you
overcome it?

Any ideas or suggestions would be much appreciated.

Please mail to :  ae2@cunixa.cc.columbia.edu
Thanks

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 92 17:19:03 GMT
From:      paul@tivoli.UUCP (Paul Greenspan)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   TLI and non-blocking I/O

Below is a description of a problem that we are having with some of
our network code.  I would appreciate any help that I could get.  

Background:
-----------
We have taken a rather complicated server that was developed with BSD 
sockets and converted it to use TLI.  The server has to handle many 
things at once (with threads) so it is important that we use non-blocking 
endpoints.  So to avoid blocking on a t_listen() call waiting 
for a connection request, we wait for poll() to tell us that 
there is a connection request and then try to call t_listen().

Here is a description of the behavior of some of our TLI code, as
executed under SVR4.0.3:

[SERVER]
1. The server calls t_open(DEV_TCP, O_RDWR, 0).
2. The server calls ioctl(tfd, FIONBIO, &non_blocking) 
   to set the TLI endpoint into non-blocking mode.
3. The server calls t_bind(tfd, &req, &ret) to offer 
   a channel to clients. The bound address is selected 
   by the transport provider (req.addr.len is 0) and 
   gets recorded so clients can be told on what address 
   to t_connect.
4. The server calls poll() to wait for connection requests.

			[CLIENT]
			5. A client initiates a connection request by first 
			   calling t_open(DEV_TCP, O_RDWR, 0).
			6. The client then calls t_bind(tfd, 0, 0)
			7. The client calls t_connect(tfd, connreq, 0), where
			   connreq has been t_alloc'd, then set up with the 
			   correct address, no options, and no user data.

			   NOTE: The client's t_connect will later appear to 
			   succeed. (Weird.)

[SERVER]
8. The server is notified of the connection request
   by poll(). t_look(tfd) returns T_LISTEN (1).
9. The server calls t_listen(tfd, callptr), where 
   callptr has been t_alloc'd but otherwise left alone. 
   This call fails, returning -1. t_errno is 
   TNOTSUPPORT (18).

			[CLIENT]
			5.  A client initiates a connection request by first 
			    calling t_open(DEV_TCP, O_RDWR, 0).
			10. Here's the weird part. The client's t_connect 
			    call now returns and indicates all is well. 
			    So the client code keeps going.
			11. The client calls ioctl(tfd, I_POP, 0)
			12. The client calls ioctl(tfd, I_PUSH, "tirdwr")
			13. The client calls write(tfd, buf, sizeof(u_long)).
			    This succeeds!
			14. The client calls read(tfd, buf, sizeof(u_long)). 
			    This is where the client finally sees something 
			    is wrong, as the read call returns 0.

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

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 92 19:31:51 GMT
From:      arena@goethe.credtech.com (Mike Arena)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,comp.unix.aix
Subject:   Hardware/Software solutions for TCP/IP <-> LU6.2 APPC communications


We are in the process of investigating products which convert between
TCP/IP and LU6.2 (and optionally DECnet) protocols for APPC.  We will be
using an IBM RS/6000 machine.  Our company currently has no IBM machines
(AS/400, S/36, S/38, 3090) nor do we (me) have any desire to own and
operate one.  The current three solutions we are analyzing are:

Vendor:		Forest Computer
Product:	Connection System

	They sell a RiscStation with their own software preloaded which
	accepts TCP/IP, DECnet, and SNA connections and transparently
	converts between any and all of them.

	Features:      Too good to be true.  Requires no knowledge of
		       LU6.2 or the nightmare of profiles to establish a
		       connection.  A simple open of a socket and
		       read() and write() calls are all that is necessary.
		       Also has TELNET, FTP, SET HOST, etc.

	Price:	       Expensive

	
Vendor:		 Harris Adacom
Product:	 SuperNet Super Channel

	They sell LU6.2 software which runs on your own RS/6000.
	You must learn LU6.2 verb set programming, etc.

	Price:	       Moderate

Vendor:		 System Strategies
Product:	 Express+

	They sell LU6.2 software which runs on your own RS/6000.
	You must learn LU6.2 verb set programming, etc.

	Price:	       Inexpensive


If anyone has used any of these products or has other suggestions, we would
appreciate any information.
-- 
Michael James Arena			Credit Technologies Inc.
arena@credtech.com			281 Winter Street, Suite #100
(617) 890-2000 x237			Waltham, MA  02154

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 92 22:33:50
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip,comp.sys.sgi
Subject:   NNStat for SGI Irix 4.0.5F anyone?

Hello,

The latest version of the NNStat programme (a programme to gather statistics
about Internet usage) I could find is dated March 15, 1991.  And it doesn't
support SGI Irix.  Did anyone port it to the Irix?

Just asking before I waste my time on this...

Thanks for any answers,
--
--Amos Shapira (Jumper Extraordinaire)
C.S. System Group, Hebrew University, Jerusalem, Israel
amoss@cs.huji.ac.il

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sun, 08 Nov 1992 18:29:22 GMT
From:      vances@xenitec.on.ca (Vance Shipley)
To:        comp.protocols.tcp-ip
Subject:   LocalTalk -> KA9Q ?

I have a couple subnets of a 10BaseT network connected with a KA9Q router.
I also have a small LocalTalk network, a couple TOPS cards and some MAC TCP
software.  I have found LocalTalk packet drivers and a version of KA9Q NOS
which is supposed to support them.

So, can I put the TOPS card in the KA9Q and have MAC users Telnet into hosts
attached to the 10BaseT subnets on the other side?  The packet driver software
for the TOPS cards suggests that I need a "gator box" to act as a gateway.
Can the KA9Q do this?

Thanks in advance for your help.

-- 
Vance Shipley 
vances@xenitec.on.ca         vances@switchview.com         vances@ltg.uucp

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8 Nov 1992 18:45:29 GMT
From:      mdw@theory.TC.Cornell.EDU (Matt Welsh)
To:        news.admin,news.future,news.misc,comp.protocols.tcp-ip
Subject:   NREN information wanted

Where can I get information on the NREN project (on-line or otherwise)? Any
pointers to documents, papers, books, etc. would be greatly appreciated.

Thanks,
mdw

-- 
Matt Welsh    mdw@tc.cornell.edu        +1 607 253 2737
Systems Programmer, Cornell Theory Center
  "She's like jelly roll, like sculpture!"

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8 Nov 1992 18:51:38 GMT
From:      scoggin@opus.ee.udel.edu (John K Scoggin)
To:        news.admin,news.future,news.misc,comp.protocols.tcp-ip
Subject:   Re: NREN information wanted

In article <1992Nov8.184529.11229@tc.cornell.edu> mdw@theory.TC.Cornell.EDU (Matt Welsh) writes:
>Where can I get information on the NREN project (on-line or otherwise)? Any
>pointers to documents, papers, books, etc. would be greatly appreciated.
>
>Thanks,
>mdw

There are some papers on host nnsc.nsf.net in the nsfnet directory.

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8 Nov 1992 20:07:31 GMT
From:      panos@burton.cs.colorado.edu (Panos Tsirigotis)
To:        comp.protocols.tcp-ip
Subject:   Re: Should connect() block after setting NDELAY?

In article <dank.720994781@blacks> dank@blacks.jpl.nasa.gov (Daniel R. Kegel) writes:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel).  It sets
>the sockets into nonblocking mode before the connect() as follows:
>	int flags;
>    #ifdef USE_FIONBIO
>	flags=1;
>	netioctl(qp->fds, FIONBIO, (char *)&flags);
>    #else
>	flags = fcntl(qp->fds, F_GETFL, 0);
>    #ifdef USE_O_NDELAY
>	flags |= O_NDELAY;
>    #else
>	flags |= FNDELAY;
>    #endif
>	fcntl(qp->fds, F_SETFL, &flags);
                        ^^^^^^
>    #endif

This is wrong; all arguments of fcntl are 'int's. 

Panos

-- 
Panos Tsirigotis, CS grad                        
Pmail: Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309-0430
Email: panos@cs.colorado.edu

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1992 03:34:07 GMT
From:      dank@cco.caltech.edu (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   SOLVED: Should connect() block after setting NDELAY?

panos@burton.cs.colorado.edu (Panos Tsirigotis) writes:
>>	flags = fcntl(qp->fds, F_GETFL, 0);
>>	flags |= FNDELAY;
>>	fcntl(qp->fds, F_SETFL, &flags);
>                           ^^^^^^
>This is wrong; all arguments of fcntl are 'int's. 

The prize goes to Panos- he solved the problem where the local Sun
rep couldn't.  Thanks much; may all your connects be speedy...
- Dan Kegel (dank@blacks.jpl.nasa.gov)

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 92 10:51:13 GMT
From:      zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Limited telnet program?

In article <Bx9MK3.4nL@techbook.com>, jamesd@techbook.com (James Deibele)
writes:
|> I would like to set up a limited telnet program for people to use.
|> Specifically, I'd like to provide local librarians a way of telneting to
|> selected online library catalogs via a menu.  If the telnet to that site
|> fails, I would want the telnet program to exit with an error level,
|> which I could then catch with a shell or program.  I don't want people
|> who use this account to be able to exit to a shell from within telnet,
|> and I don't want them to be able to telnet elsewhere.
|> 
|> If someone has seen a program like this, or has a reason why this is a
|> bad idea*, I'd like to hear about it.  It seems like it should be
|> reasonably secure for both us and the rest of our Internet neighbors.

The source of the BSD telnet seems to be available on a number of
anonymous ftp sites so if you're running on a Sun then this may help.
Use archie to look for telnet.c.
Meanwhile, I'm looking for something similar for HP-UX, i.e. a telnet
which disallows shell escapes (I'm not bothered about trapping errors).
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 92 10:57:41 GMT
From:      rol@grasp1.univ-lyon1.fr (Paul Rolland)
To:        comp.protocols.tcp-ip
Subject:   /etc/protocols file

Hello,

I'm using a Sun system with a /etc/protocols file that contains only 5 or
10 lines, with nothing refering to port 25 (snmp) or 33... I know this
file is used when you call getprotobyname and so on, but is it used for
something else ? Is it a problem to have it containing only a few lines, 
and should I update it ? If yes, could s.o. send me a more complete one ?

Here is my full /etc/protocols file :(
#
# @(#)protocols 1.9 90/01/03 SMI
#
# Internet (IP) protocols
# This file is never consulted when the NIS are running
#
ip      0       IP      # internet protocol, pseudo protocol number
icmp    1       ICMP    # internet control message protocol
igmp    2       IGMP    # internet group multicast protocol
ggp     3       GGP     # gateway-gateway protocol
tcp     6       TCP     # transmission control protocol
pup     12      PUP     # PARC universal packet protocol
udp     17      UDP     # user datagram protocol


Paul Rolland, rol@grasp1.univ-lyon1.fr

---
--------------------- DISCLAIMER -------------------

All the opinions I express in this posting are mine, but I'm
ready to share them with anybody interested :-)

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 92 11:06:25 GMT
From:      rol@grasp1.univ-lyon1.fr (Paul Rolland)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with write to a socket

In article <40016@unix.SRI.COM>, ric@updike.sri.com (Richard Steinberger)
wrote:
> 
> 
> 	I have been porting a TCP/IP client from C to C++ on a Sun
> running SunOS 4.1.2.  The server ported fine but there is an annoying
> bug with the client:  When I write to a socket using code I lifted
 
> In other words, it's as if the program exit process forces a flush of the
> socket that had been taking place with each write when it was running under
> C.  This is hard for me to understand.  Does anyone have any ideas?  Thanks
> in advance.
> 
Well, this is just an idea, but are you sure the bug is not located in the
read in the server code ? This read may be a blocking one, waiting for
a given number of bytes, and as long as it has not received what is
requested,
it waits. But, when you stop the client (and then closed the connection),
the
server returns from the read and then you have the impression that it is
OK..

In fact, you should have give us more precisely the reference of the
program
you are using from the book, so that it is possible to have a look at it
and help you a bit more. But i hope this helps !

Paul Rolland, rol@grasp1.univ-lyon1.fr
---

--------------------- DISCLAIMER -------------------

All the opinions I express in this posting are mine, but I'm
ready to share them with anybody interested :-)

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 92 14:47:22 GMT
From:      sweeney@Ingres.COM (Tony Sweeney)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connect

I wrote:
>In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes:
>>
>>Some time ago there was a question about checking for a TCP connect
>>to a possibly non functioning machine without the long wait.
>>An answer was posted using connect with nonblocking mode. I don't
>>have that article now but would appreciate any pointers . Target
>>system would be Esix SVR4 using the socket libraries and TCP/IP.
>>
>>-- 
>>Lack of skill dictates economy of style.             raw@ushiva.ncoast.org
>>- Joey Ramone                                        raw@ushiva.wariat.org
>>Roland A. Wilcher                         6207 Luther Ave. Cleve Oh. 44103 
>>---------------------------------------------------------------------------
>
>
What I meant to say was - here is some code I wrote to tickle a bug
in Apollo DomainOS 10.4 tcp. Should fail at the connect() on any
working system.

--------------------------cut here--------------------------------
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <fcntl.h>

main()
{
struct sockaddr_in s, peer;

int sock, namelen;

int maxfd=FD_SETSIZE;
fd_set inbits, outbits, errors;

struct timeval tims;

/* code starts here... */

FD_ZERO(&inbits);
FD_ZERO(&outbits);
FD_ZERO(&errors);

bzero((char *)&s, sizeof(s));

s.sin_family = AF_INET;
s.sin_addr.s_addr = inet_addr("127.0.0.1"); /* loopback */
s.sin_port = htons(12345);	/* any bogus value will do */

sock = socket(s.sin_family, SOCK_STREAM, 0);

if( sock < 0 )
        {
                perror( "socket" );
                exit(1);
        }

        /* set for non-blocking */

if (fcntl( sock, F_SETFL, O_NDELAY ) < 0)
	{
                perror( "fcntl" );
                exit(1);
        } ;

if (connect(sock, (struct sockaddr *)&s, sizeof(s)) < 0)
	{
	if (errno != EINPROGRESS)
		{
		perror("connect");
		exit(1);
		}
	}

tims.tv_sec=4;	/* select times out after 4 seconds */
 
if (select(maxfd, &inbits, &outbits, &errors, &tims) < 0)
                {
                perror("select");
		exit(1);
                }

namelen=sizeof(peer);

if (getpeername(sock, (struct sockaddr *)&peer, &namelen) < 0)
	{
	printf("Correct: no peer\n");
	}
else
	{
	printf("getpeername thinks it is connected to %s:%d\n",
		inet_ntoa(peer.sin_addr.s_addr), peer.sin_port);
	exit(1);
	}


exit(0);
}



-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 92 16:27:47 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Wanted: Advice on calculating timing gaps between packets.


I am analyzing the timing between packets during several large file
transfers (it's a medical network). We are going to check the accuracy
of our network simulation with real data. (Novel concept, huh?)

Does anyone have advice on calculating the time between each packet?
(Assuming we are looking at packets during a file transfer going from
A to B only).  We are using tcpdump and a SPARC (typically a SPARC 2).
I am not sure I am using the best formula.

I know the SPARC 2 has a 1 ms clock. The timestamp that tcpdump
provides is actually the time the SPARC making the measurement
received the packet, right? If Ethernet transmits at 10Mb/second, or
10,000,000/8 MB/sec, then each byte should take 1/(10000000/8)
seconds. Therefore the time the packet was first received on the
measurement system would be:

	$start_time = $receive_time-(1/(10,000,000/8))*$size_of_packet;

I am trying to measure the time between the end of one packet and the
start of the next packet.

If the system started to send a packet, and there was a collision, so
it had to back off and retransmit, typically how much difference would
the measurement machine see?

I realize that there is a propagation delay down the wire. Is there
some other factors I should be taking into consideration?


--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Nov 1992 16:33:22 GMT
From:      xsong@marcus.cs.umn.edu (Carol Xiaohui Song)
To:        comp.protocols.tcp-ip
Subject:   Need info on Chameleon TCP/IP software


Hello there,

I have some questions about the Chameleon network software by NetManage Inc.
If you have experiences with any of the Chameleon software (e.g., 
TCP/Inconsistency Percentage appl. package, NFS, Chameleon32, NEWT-SDK,
RPC-SDK), I'd like to hear your opinions on the following:

- Chameleon TCP/IP application package (for Windows 3.x).
How do you like the applications it provides such as Telnet, FTP,
SMTP/Mail, etc?  For example, can you open multiple telnet sessions? when
you open an application like telnet, do you simply click on the icon?
Any features that you like/dislike in particular?

- Chameleon32 for Windows NT is the developer's release. Has anyone used it
already?  Is it good (adequate and efficient) for developing software that
makes use of TCP/IP?

- Is Chameleon TCP/IP software reliable? If you're using one, are you
satisfied with their tech support? (competence, efficiency of the technical
personnel)

- Anything I should know besides these?
The price tag on Chameleon is a little high. I'd like to hear from its users
before I decide to purchase the software.

I appreciate your help and am looking forward to hear your opinions!

Carol Song
--
Carol (Xiaohui) Song (xsong@cs.umn.edu)

"You know you've been spending too much time on the computer when your
friend misdates a check, and you suggest adding a "++" to fix it."

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 1992 18:00:22 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/protocols file

In article <rol-091192115942@90.222.1.80> rol@grasp1.univ-lyon1.fr (Paul Rolland) writes:
>I'm using a Sun system with a /etc/protocols file that contains only 5 or
>10 lines, with nothing refering to port 25 (snmp) or 33...

Port number assignments go in /etc/services.

Port 25 is SMTP.  SNMP is 161.  Port 33 is Display Support Protocol, which
I've never heard of.

The complete list of port numbers is in the Assigned Numbers RFC, the
latest revision of which is RFC 1340.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Nov 1992 22:31:51 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connect

In article <1992Nov9.144723.6561@pony.Ingres.COM> sweeney@Ingres.COM (Tony Sweeney) writes:
>
>What I meant to say was - here is some code I wrote to tickle a bug
>in Apollo DomainOS 10.4 tcp. Should fail at the connect() on any
>working system.
>
[ code deleted ]

There is another bug in DomainOS 10.4 tcp that is more serious, but as far as
I can determine, it only is shown through the interaction with AIX 3.x (which
is also probably buggy)  But the bug is bad enough that it can bring down any
Apollo running 10.4 in about 5 seconds, corrupting it badly enough it often
requires the reset button to unwedge it.  I won't post it here for obvious
reasons, especially because so far as I know there is no fix available for
this problem.

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@isca.uiowa.edu       |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 00:28:40 GMT
From:      gsu0033@uxa.ecn.bgu.edu (Eric Molas)
To:        comp.protocols.tcp-ip
Subject:   FAQ LIST

Is there a FAQ and could someone post it for this group? 


		thanks,  


				Eric Bruno Molas\

...grate .sig  ...

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 92 01:31:05 GMT
From:      ljs@netcom.com (Linda Siegel)
To:        ba.jobs.offered,comp.sys.sgi,comp.protocols.tcp-ip
Subject:   Senior UNIX Network/System Administrator @LucasArts-ILM


Industrial Light & Magic is the leader in creating visual effects 
for motion pictures, television and theme-park attractions.  
ILM has contributed its creative and technical expertise to more
than 70 films and has won 11 academy awards (most recently for
"TERMINATOR 2").  

ILM is also the industry leader in utilizing new, state-of-the-art 
digital and computer graphics technology.  We are seeking a senior
systems/network administrator to manage and grow our networks for
our increasing high-volume data requirements.  As part of the ILM team,
you'll have the opportunity to work with very creative and imaginative
people in a fast-paced production environment.  You'll be a member of a
small Computer Services staff with broad support responsibilities.  

Responsibilities:
=================
As the lead systems/network administrator you will provide
direction and leadership for network planning and optimization.

Your day-to-day activities will include:

o Research, evaluate and recommend emerging network technology.

o Analyze troubleshoot and optimize production networks.  
  
o Plan, analyze and tune system performance of our SGI and Sun workstations.

o Communicate with project and department managers to ensure network 
  and computing systems are performing adequately.

o Develop procedures and programs to manage installation of all
  workstation software (OS, graphics-specific, and other software).

o Define, improve, develop and monitor data backup of our 
  high-volume data.

o Troubleshoot software problems.

o Assist with new workstation installation and configuration.


Qualifications:
===============
o BS in Computer Science (or 4 years related experience in place 
  of educational requirement).

o Minimum 3 years experience in system and network administration, 
  preferably in a large workstation environment including SGI and 
  Sun systems.

o Demonstrated understanding of networking fundamentals and 
  state-of-the-art technology including: TCP/IP, network analysis,
  routers, NFS, FDDI and broadband networks.

o Working knowledge of UNIX (c-shell, awk) and C.

o Ability to work in fast-paced production environment.

o Strong verbal and written communication skills.


Who to Contact
==============
We are accepting resumes by US mail only. If you are interested
in this position, please send a cover letter, resume and 
salary history to:

	Human Resources  
	Mail-Stop JG
	LucasArts Entertainment Company
	P.O. Box 2009
	San Rafael, CA  94912

Please do not respond to this account.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 92 02:23:15 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   ODITRPKT almost working but need help!

Description of my testing methods.   

When trying to open a telnet connection with CUTCP I sent out 11 perfectly 
formed ARP packets.  With our general datacomm Sniffer I can see these packets
go out and also see responces to them.  Therefore send works for ARP.

Now I load up the Netcure software on my driver and retransmit those packets 
that were captured from before.  The ones to my mechine show up in netcapt so 
conclusion receive works for ARP.

Now I load up ibmtoken on a mechine and do a telnet session to get data loaded
into the sniffer quit and load up oditrpkt and netcapt.  Transmit data from 
sniffer back threw my driver into netcapt.  Go into netview and IP/TCP packets
look OK.  Conclusion Driver receives IP/TCP packets ok.

Summary 
ARP 	transmit and receive work
TCP/IP	only receive works

My guess is that TCP/IP traffic is getting stopped at the lsl or mlid since I 
never see a packet go out on the wire.  There have been two times when I
actually got a TCP packet out on the wire.

The only difference in the way I treat ARP and TCP/IP in my sending routine is	I change the hardware type in the ARP packet on transmit and receive and I 
reduce size to eliminate excess on incomming arp_packets.  I also round all
incomming packets up to 60.  I am doing raw receives, but I am giving a  
specific StackID on sends although I have only bound a prescan stack.
I have tried raw sends, default and prescan stacks.  I have also tried 
binding a perticular stack but I had less success there.  

Question:  Are the stack ID's the same as the ProtocolID's? 
	Is it necessary to bind a stack to send things?  
	Why would ARP work and TCP/IP not work.    
	Does anyone have any suggestions on things to try?  
	Seen something simular before?

I am also in need of Tools and ideas for debuging.  Anyone know of any shims
that I can fit into here to gain more knowledge on where the packets are getting
lost?

All speculations, ideas, and any other help greatly appreciated.

Ben James
ben@datacomm.ucc.okstate.edu

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 11:05:17 GMT
From:      loneshay@csie.nctu.edu.tw (Lone Shay)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP implemented in Streams ?

 Hi all:

   Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1 
 is implemented in Streams mechanism ?

   Any information will be extremely appreciated !

        Thanks...

                                          Lone Shay     1992/Nov/10
 
                                          Email: loneshay@csie.nctu.edu.tw



-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 12:07:40 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        bit.listserv.ibmtcp-l,comp.protocols.tcp-ip
Subject:   TCP/IP for AS/400

We know that IBM themselves offer a TCP/IP product for the AS400 range.
Are there any third-party vendors in this market, and have you any
experience of their products?

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
	print unpack( u,q,9:G5S="!A;F]T:&5R('!E<FP@:&%C:V5R"@``,.'');

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 12:25:32 GMT
From:      g91m1969@alpha.ru.ac.za (Thabo Mosala)
To:        comp.protocols.tcp-ip
Subject:   Hippi

I would like to get hold of the new developed standards for High Performance
Parallel Interface (Hippi) or where can I get information on the subject ?


___________________________________________________________________________

Thabo Mosala - g91m1969@alpha.ru.ac.za

The views expressed above are my own

___________________________________________________________________________

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 12:41:35 GMT
From:      gwe@cbnews.cb.att.com (george.w.erhart)
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on Chameleon TCP/IP software

In article <xsong.721326802@marcus> xsong@marcus.cs.umn.edu (Carol Xiaohui Song) writes:
>- Chameleon TCP/IP application package (for Windows 3.x).
>How do you like the applications it provides such as Telnet, FTP,
>SMTP/Mail, etc?  

In general their applications are okay. IMHO, the next windows telnet interface
remains QVTNET. The Chameleon telnet is definitely second. The QVT has the best
cut/paste mouse interface. I have had some trouble with Chameleon, where I
can cut an item, it appears on the clipboard, but it fails to paste. Chameleon
seems to like to put a CR/NL after all pasted selections. (This is stupid!)
Finally, if you have more than 24 lines of scroll buffer defined, when the
display fills, a scroll bar appears on the bottom of the display. This scroll
bar uses 1 line of the display. Thus, when you go into VI, the cursor disappears
under the menubar at the top of the window. You have to select Settings->Reset
Size to get rid of the scrollbar and get the window back to 24 lines. (This is
also stupid, I have programmed a "Recorder" macro to automate this process and
assigned it to F12.)

>For example, can you open multiple telnet sessions? when
>you open an application like telnet, do you simply click on the icon?

Yes, you click on the icon, then use the connect menu to select the destination.
Or, you can set up and icon with the destination passed as an argument
(see the "properties" menu item). (I use the latter in conjunction with 
a freeware program called Dropper that gives me a Norton Desktop ability to
put program icons on the base window.

>Any features that you like/dislike in particular?

In addition to the above ... the newest version of ChameleonNFS integrates
NFS into the filemanager. This is great and it seems to work okay. There are
a few problems.

	1. I could not get it to work with the pcnfsd that came with the 
	   WIN/TCP 386 TCP/IP package that we run on our UNIX 5.3.2.3 boxes.
	   A work around was to self-authorize. (Chameleon allows others to
	   mount your PCs drives. It has a built-in pcnfsd.) The problem
	   with this is the giant security hole that makes. (I can change
	   my own system and authorize myself to mount anything I want!)

	2. The mapping from UNIX long names to DOS 8.3 names has some problems.
	   I have a directory on the UNIX box that contains a several days
	   worth of weather map GIFs. I have found that the NFS mapping repeats
	   some of the names. This means that there are files that I can not
	   select some of the files. 

	3. They do have a function for finding out what the real name of the
	   file was. However, the function is part of the "network" widget on
	   the control panel. This makes it a pain to use. The really should
	    make it a filemanager extension.

>
>- Chameleon32 for Windows NT is the developer's release. Has anyone used it
>already?  Is it good (adequate and efficient) for developing software that
>makes use of TCP/IP?

I have order two copies of this ... if any one is interested, I will post
a noet about this once I get it running.

>- Is Chameleon TCP/IP software reliable? If you're using one, are you
>satisfied with their tech support? (competence, efficiency of the technical
>personnel)

I have purchased and reviewed 6 DOS/Windows TCP/IP packages. I have found
that Chameleon is very reliable "on my hardware, with my drives". Please note
that with different hardware and different NDIS drivers, you may have a 
different experience. I have had on-going problems with the PCNFSD mentioned
above and with sendmail. I believe that most (if not all) of the problems are
with the UNIX side of things. The folks at NetManage have been very helpful.

>- Anything I should know besides these?
>The price tag on Chameleon is a little high. I'd like to hear from its users
>before I decide to purchase the software.

The price is definitely  high when compared to QVTNET, but QVTNTE does not
have:
	NFS client & server
	SMTP mail server
	telnet 3270
	SNMP client
	TFTP client & server
	BIND (domain name server)
	built-in SLIP support

A word on the last item, I have tested various configurations for SLIP with
most of the TCP/IP packages I tested. The Chameleon implementation is both
the easiest to setup and the best performing. 

Finally, I run the Exceed/W X Window package on top of Chameleon. It seems
to out perform the same package running on top of FTP's PC/TCP 2.1.
-- 
George Erhart
AT&T Bell Laboratories
Columbus, Ohio
att!archie!gwe or gwe@archie.att.com

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 92 15:55:19
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP implemented in Streams ?

>    Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1 
>  is implemented in Streams mechanism ?

No, the SunOS 4.1.1 TCP/IP is basically a Berkeley (i.e. socket) based
implementation, with streams layered on top of sockets.

Solaris 2.0 is a native streams implementation, with (as far as I know)
sockets layered on top of streams.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 14:40:55 GMT
From:      silvert@cs.dal.ca (Bill Silvert)
To:        comp.protocols.tcp-ip
Subject:   Re: Limited telnet program?

In <6693@m1.cs.man.ac.uk> zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby) writes:

>The source of the BSD telnet seems to be available on a number of
>anonymous ftp sites so if you're running on a Sun then this may help.

There is a secure version of telnet on boombox.micro.umn.edu for use by
gopher clients.  However, it also is BSD-specific.  If anyone knows a
secure telnet for SysVR4 (specificially IRIX 4.0.5) I would like to know
about it.
-- 
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. (902)426-1577
InterNet Address: silvert@biome.bio.ns.ca

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 15:30:00 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootleggers


I want to really thank everybody who answered my question about what to do
with or to those people who won't get with the program and register their
network interfaces.  Since certain actions had the potential for disrupting
honest network users, I asked that the responses be E-mailed to me.  I received
10 responses.  Fortunately, most of the measures which can be taken to stop
people from just picking an IP number and going full steam ahead are things
that only network managers can do, assuming the network is configured properly.
The best actions appear to be to tell all bridges or routers in your network
not to handle any packets from X interface.  If you can get everybody to
go along, run versions of tcp-ip applications that do a nslookup on every
connect request to see if they are in the name server data base.  Between
those two measures, the network should become a pretty boring place for
bootleggers.  Again, my thanks to all and also thanks for the recommendations
for management software which I received from a couple of posters.

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

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 15:42:28 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   FAST!!! TCP-IP Machines

Has anybody in netland done research on how fast different platforms process
communication protocols?  I am currently working on an application that relies
heavily (very heavily) on TCP-IP.  I am currently using Sun SparC II's but I 
would really like to know if there are machines that are better suited to my
application.

Any info would be greatly appreciated!!!!

Thanks,


-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 17:37:30 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP implemented in Streams ?

In article <STEINAR.HAUG.92Nov10155519@delab.sintef.no>, Steinar.Haug@delab.sintef.no (Steinar Haug) writes:
> >    Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1 
> >  is implemented in Streams mechanism ?
> 
> No, the SunOS 4.1.1 TCP/IP is basically a Berkeley (i.e. socket) based
> implementation, with streams layered on top of sockets.
> 
> Solaris 2.0 is a native streams implementation, with (as far as I know)
> sockets layered on top of streams.


I don't know about Solaris 2.0.   However, the TCP in SVR4.1 and beyond
seems to be a combination of versions of 4.3BSD around the net-1 release
that have been "stream-ized."   This observation is based on side-by-side
comparisons of the source.


Vernon Schryver,  vjs@sgi.com

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 18:16:34 GMT
From:      ihsan@ferranti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun Generic Broadcasting

In article <DERAADT.92Nov5144740@newt.newt.cuc.ab.ca>, deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
> [Distribution changed from "usa" to "world". Unix is the same in Europe, isn't it??]
> 
> In article <1004@math.math.mv.dupont.com> mc@math.math.mv.dupont.com (Matt Cunningham-Software Development) writes:
> > I am trying to find the proper broadcast IP address to send a packet (BOOTP 
> > packet to be specific - but the packet type is not important) to so that
> > everyone on the network will receive it.
> [deleted descriptions of numerous attempts to make it work...]
> 
> The bind() call will take INADDR_ANY to indicate that it will take a
> connect from any address. It's more difficult when you send packets
> out -- you must indicate _exactly_ where you want to send to. A
> unix machine may have multiple interfaces, with multiple addresses.
> You need to specify the broadcast address for the particular network
> you are interested in. If you wish to send on all the attached networks,
> you need to do multiple send()'s.
                 ^^^^^^^^^^^^^^^^^^

What is the status of TCP broadcasts and mutlicasts ?


-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 20:05:42 GMT
From:      tga@oar.net (Germann Associates)
To:        comp.sys.novell,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Request for info 5250 emulator over tcpip for novell

I'm looking for a 5250 emualtor for PC's running over TCP/IP.  Either
packet drivers or LWP for Dos versions are acceptable.  In lieu of that
ANY 5250 emulator suggestions that will co-exist with NW would be appreciated.

Something like tn3270 from Clarkson University.


Thanks in advance.

Please reply to eric@tga.com
-- 
============================================================================
Eric Germann                               Quote for the campaign:
The Germann Associates                     "Lead, follow, or get out of the 
eric@tga.com                                way"   - Lee Iacocca 

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 20:28:11 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: FAST!!! TCP-IP Machines

In article <1992Nov10.154228.29047@panther.mot.com>, ronf@panther3.panther.mot.com (Ron Feigen) writes:
> Has anybody in netland done research on how fast different platforms process
> communication protocols?  I am currently working on an application that relies
> heavily (very heavily) on TCP-IP.  I am currently using Sun SparC II's but I 
> would really like to know if there are machines that are better suited to my
> application.
> 
> Any info would be greatly appreciated!!!!


It might help to be more specific.

All reasonable machines are now about the same speed--over a 56Kbit/sec
link.  All good machines are now about the same speed over ethernet--a little
more than 1MByte/sec.

On the other hand, Cray makes machines that do about 1Gbit/sec.
(I have a mental block about the exact numbers, which were over the
loopback interface and two flavors of HIPPI.)

In between, DEC was showing machines without labels at Interop that
were running at about 95Mbit/sec over FDDI.  (They said details about
the machines would be announced Nov. 10.  No doubt everyone has seen
the numbers in comp.arch.)  Another vendor in a nearby booth (blush)
was running somewhat faster, also over FDDI.


Vernon Schryver,  vjs@sgi.com

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 1992 21:38:05 GMT
From:      dank@cco.caltech.edu (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Re: Hippi

g91m1969@alpha.ru.ac.za (Thabo Mosala) writes:
>I would like to get hold of the new developed standards for High Performance
>Parallel Interface (Hippi) or where can I get information on the subject ?

A search with Archie reveals:
Host bruno.cs.colorado.edu
    Location: /pub/cs/doc/hippi
           FILE -rw-r--r--     748905  Apr 18 00:00  hippi-ph_8.1.ps
	   etc.
These are the full protocol definition documents, it seems.

- Dan Kegel

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 21:40:05 GMT
From:      root@darkside.osrhe.uoknor.edu (Operator)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Limited telnet program?

James Deibele (jamesd@techbook.com) wrote:
: I would like to set up a limited telnet program for people to use.
: Specifically, I'd like to provide local librarians a way of telneting to
: selected online library catalogs via a menu.  If the telnet to that site
: fails, I would want the telnet program to exit with an error level,
: which I could then catch with a shell or program.  I don't want people
: who use this account to be able to exit to a shell from within telnet,
: and I don't want them to be able to telnet elsewhere.
: 
: If someone has seen a program like this, or has a reason why this is a
: bad idea*, I'd like to hear about it.  It seems like it should be
: reasonably secure for both us and the rest of our Internet neighbors.
: 
: Thanks.
: 
: *Please no criticism about how we should give free shell accounts to
: anyone who asks for one unless you're prepared to contribute hardware.

You can get source code for telnet on 
ftp.uu.net:/networking/applic/telnet.91.03.25.tar.Z
-- 
-------------------------------------------------------------------------------
Huy Nguyen                        | "It's not nearly enough to survive,
wee@darkside.uoknor.edu           |  But to live." - M.M.
-

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 92 22:21:53 GMT
From:      robinson@mdivax1.uucp (Jim Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Should connect() block after setting NDELAY?

Daniel R. Kegel (dank@blacks.jpl.nasa.gov) wrote:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel).  It sets
>the sockets into nonblocking mode before the connect() as follows:
>	int flags;
>    #ifdef USE_FIONBIO
>	flags=1;
>	netioctl(qp->fds, FIONBIO, (char *)&flags);
>    #else
>	flags = fcntl(qp->fds, F_GETFL, 0);
>    #ifdef USE_O_NDELAY
>	flags |= O_NDELAY;
>    #else
>	flags |= FNDELAY;
>    #endif
>	fcntl(qp->fds, F_SETFL, &flags);
>    #endif
>The problem is, under SunOS 4.1.1, connect() then blocks until a 
>accept, reject, or defer response comes back from the server.
>This can take several seconds if the Internet is being slow.
>The local Sun guy was able to see this in the source code, but does not
>consider it a bug.  What do you all think- is it reasonable for connect()
>to block for several seconds when the socket is supposedly in nonblocking
>mode?

On a semi-related topic I can say that if, on SunOS 4.1.2, you set the
socket to nonblocking with POSIX O_NONBLOCK, a subsequent connect() will
indeed *block*; i.e., O_NONBLOCK has no effect on the connect().

-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 1992 23:21:43 GMT
From:      sjs@netcom.com (Stephen Schow)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP C Libraries for Macintosh?

Anyone know where I can get information about TCP/IP programming in C on 
the Mac and especially any libraries that exist.

Thanks in advance
-- 
------------------------------------------------------------------
Steve Schow    | But you don't have to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
               | Have I given you a clue......?
               |                       - Baloo the Bear
------------------------------------------------------------------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 1992 03:31:43 GMT
From:      tbooth@netcom.com (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   RFD: comp.dcom.sys.wellfleet

This is a formal Request for Discussion on the creation of a new newsgroup
called "comp.dcom.sys.wellfleet" (not moderated).

I forgot to include comp.protocols.tcp-ip in my initial broadcast so now I
will.  The original groups were:

Newsgroups: news.announce.newgroups,news.groups,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.dcom.lans,comp.dcom.cell-relay,comp.dcom.lans.novell

This announcement is cross-posted to newsgroups whose readers may have 
interest in the discussion about the new group; follow-up discussion will
take place in "news.groups". Suggestions, comments or problems may also
be emailed to me at <tbooth@netcom.com or tbooth@wellfleet.com>.

REQUEST FOR DISCUSSION
----------------------

NEWSGROUP
  comp.dcom.sys.wellfleet (not moderated)

PURPOSE
  The newsgroup 'comp.dcom.sys.wellfleet' would be a forum for discussing 
  issues related to Wellfleet bridge and router systems hardware & software,
  interoperability with other products, and system configuration.

  It will NOT be a forum for forwarding sensitive information
  as e-mail and individual contact are for this purpose.

  It could be the best, and quickest way to exchange questions and
  answers, hints and tips on optimization, have contacts between users
  having common problems and maybe some common solutions.


RATIONALE

  Very often Wellfleet users receiving news and having questions don't know
  really where to post their questions in such a way that it could be
  answered by some other Wellfleet users.

  In the same way, people who could be able to answer the question are not
  necessarily inspecting all articles where Wellfleet is mentioned, such a 
  newsgroup will usually permit better follow-ups for Wellfleet issues.
  Users could discover lot of indirect Wellfleet matter accidentally in 
  comp.dcom.lans.{ethernet, fddi, misc...}.

  Wellfleet User Groups exist in the U.S. and Europe.
  Mailing lists have been going in the U.S and Europe for several years; 
  but this way of communicating is not particularly adequate for users
  of multi-recipient systems, i.e., each message is sent to each registered
  user, even on the same systems, moreover each user must ask to be
  explicitely registered.

  A newsgroup would permit all users of Wellfleet systems receiving the News
  to receive only one copy of each message and to share it potentially
  with all the users of the systems.

  This newsgroup could be a prolongation of each annual Wellfleet User Groups
  meetings, permitting not only to those (s)elected people having the chance
  to take part to these interesting reunions but also to more common users,
  students, researchers, etc... to share their experiences.

  In the era of communication, newsgroups are the easiest way to build 
  bridges across oceans and permitting of people with common interests
  to be part of an electronic community wherever they are located 
  in the world.


CONTENT

  Miscellaneaous
  - Wellfleet FAQ
  - jobs available
  - other events that concern Wellfleet systems and/or users


  Hardware
  - Wellfleet Nodes series
  - Wellfleet Backbone Node series
  - interfacing 3rd party products to Wellfleet systems

  Software
  - Public domain SNMP software for management of Wellfleet systems
  - Software releases discussion and announcements
  - Customization of network configurations for optimal performance

  System
  - Network integration
  - Multi-vendor compatibility
  - System tuning
  - Benchmarking and performance measurement


  System administration
  - Security
  - How to upgrade between releases
  - Remote upgrades

  This newsgroup will be in conjunction with the existing mailing lists
  to allow users who do not receive News to submit and receive newsgroup
  traffic and take part in the discussions.

NAME
  comp.dcom.sys.wellfleet seems to be the name fitting the most adequately 
  the purpose.

NOT MODERATED
  In order to have questions answered as fast as possible, this 
  newsgroup would not need to be moderated and indeed would most 
  probably be self-moderated.

NEWSGROUP CREATION
  The discussion period will be from November 10th, 1992 to December 2nd, 1992.
  Please post all discussion in news.group.
  If a consensus is reached by the end of the discussion period,
  a CFV (Call for Votes) will be posted at that time. The voting period
  will last for 21 days.

Thanks for your interest !

Todd Booth | Systems Engineer | Wellfleet Communications, Inc | 310 445-8840

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 92 04:12:09 GMT
From:      dank@blacks.jpl.nasa.gov (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP C Libraries for Macintosh?

sjs@netcom.com (Stephen Schow) writes:
>Anyone know where I can get information about TCP/IP programming in C on 
>the Mac and especially any libraries that exist.

There are several socket libraries available for the Mac.
1. a package at ftp.ncsa.uiuc.edu in /misc/unsupported, originally written 
   by Tom Milligan of Toronto, rewritten by creiman@apple.com (Charlie Reiman).
   For MPW C?
2. Matthias Neeracher <neeri@iis.ethz.ch> has written a Grand Unified Sockets
   library that tries to make EVERY kind of communication on
   the Mac available via the socket paradigm.
   Also for MPW C?
3. hardin@mcc.com (John Hardin) ported one to Think C 5.0, but can't release
   it yet.

And then there's raw MacTCP... but that's another story.
- Dan K.

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 1992 16:44:06 GMT
From:      cole@etonic.gsg.dec.com (Larry Cole)
To:        comp.protocols.tcp-ip
Subject:   Programmatic Interface to FTP


I have a request from a customer for a programmatic interface to
ftp.  While not difficult to implement, I have not heard of
any UNIX vendors with this capability.  Is anyone aware of
such an implementation that might be used as a guideline
for calling syntax, etc.

thanks.

larry cole

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 1992 18:34:36 GMT
From:      add@philabs.philips.com (Aninda V. Dasgupta)
To:        comp.protocols.tcp-ip
Subject:   TCP Buffer sizes in Routers and packets per second

I have a question for tcp-ip gurus, especially if you are
familiar with SunOS.

I have the following setup.

			Sparc II w/ 2 E-net cards
			 _______
			|	|
   	|-------|Gateway|-------|
		|	|	|	|
 Sparc II	|	|_______|	|
  ______	|			|	Sparc II
 | 	|	|			|	 ________
 |Sender|-------|			|-------|	 |	
 |      |	|			|	|Receiver|
 |______|					|  	 |
						|________|

The gateway is an or'nery Sparc II, with two Ethernet cards on it.
I need to send 10 MByte Image files from the sender to the receiver.
I set my TCP Transmit and Receive buffer sizes to 50K Bytes.  However,
the gateway is beyond my control. Do my TCP packets get reassembled at
the Gateway?  In other words, does the buffer size in the gateway matter
in the speed of transfer?  I would expect all the routing to be done at the
IP layer.  Therefore, my TCP buffer sizes should not matter at all, right ?

I don't know how this piece of information matters, but I monitored the
number of Ethernet Packets on the Sender, the gateway and the Receiver.
While Perfmeter showed between 256 and 512 packets per sec. on the
sending machine, it showed between 1024 and 2048 pps on the gateway and
a constant 1024 pps on the receiver.  All three machines were
loaded only by my sending and receiving programs.  Any insights into
this discrepency between the number of pps on the three machines?

Thanks for any ideas/answers you can give me.  

Aninda DasGupta


-- 
Aninda DasGupta (add@philabs.philips.com) Ph:(914)945-6071 Fax:(914)945-6552
Philips Labs\n 345 Scarborough Rd\n  Briarcliff Manor\n NY 10510
"Err.., Phillips Petroleum gives you gas; fortunately Pillips Chemical
 makes antacid. Philips is with one "el", we make lightbulbs. And other shtuff"

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 92 19:13:16 GMT
From:      vlei@acp.amdahl.com (Veng Lei)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip network performance

Could someone points to me where I can find infomation or
discussion related to IP network (for both dialup and leased
line cases) performance.

Thank you.

Veng Lei
Amdahl Corporation

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 1992 19:20:03 GMT
From:      hofer@rchland.vnet.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip
Subject:   Re: Proper Method of Closing IP Sockets

In article <1992Nov7.034406.19500@blaze.cs.jhu.edu>, eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) writes:
|> 	What is the proper method of closing a socket in order to release
|> the socket/port binding?  Under SunOS 4.1, my application closes its
|> descriptors and exists.  If I immediately execute it again, the bind fails
|> with errno EADDRINUSE.  

This isn't related to how you close the socket descriptor:
TCP doesn't allow you to re-use a port until (2 * Maximum segment life) time 
has passed.  The work around is to use the SO_REUSEADDR socket option.  Add that
to your sample program and you should be able to restart the server immediately
after killing it.  It tells the TCP stack to allow a bind during this "close 
 wait" state.
- 
Kent Hofer             hofer@rchland.vnet.ibm.com
(my opinions are my own and have nothing to do with my employer)


-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 92 08:26:46 -0600
From:      mndot@msus1.msus.edu
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   SNA <-> IP Encapsulation


I am new to this particular news feed so this may have been asked in the past.
I am not very familiar with IBM host equipment either.

I am trying to provide mainframe connectivity to a number of remote sites. 
Most of the sites have IBM 3174 (or compatible) remote controllers for SNA
communications.  This comm. takes place over multidrop 9600 bps lines.  We are
in the process of installing T1 circuits to all of those same locations.  The
T1's are primarily IP.  Does software exist for the 3174 to allow SNA
encapsulation in IP packets?  I have seen hints of this scenario on some of the
news feeds but I am not sure which ones.  Any help with this would be greatly
appreciated.

 -- Al

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 92 23:22:59 GMT
From:      jhonan@kralizec.zeta.org.au (Jamie Honan)
To:        comp.protocols.tcp-ip
Subject:   Looking for UDP/IP for embedded systems

I am looking for a UDP/IP stack (commercial or freely available) suitable
for an embedded system.

If you know of any, or have experience with porting such a stack, please
email at jhonan@kralizec.zeta.org.au

Regards, Jamie Honan

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 1992 23:25:35 GMT
From:      dan@dribble.c-mols.siu.edu (Dan Ellison)
To:        comp.protocols.tcp-ip,comp.protocols.ibm,comp.os.msdos.apps
Subject:   print redirector for DOS to remote lpr?

Greetings all.  I am interested in getting ahold of a print redirector
that will capture the standard LPTn interrupt and redirect the output
to a remote lpr server.  Does anyone know of such a critter?  Any
help greatly appreciated and thanks.


PS:  public domain is preferred but commercial may also be
acceptable.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Spec 	  -    	Computing Affairs, SIU-C 	| 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-6149 	|     

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 92 02:19:05 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: Hippi

The current HIPPI specs are available via annonymous FTP from
network.com (I forget the directory, but it's pretty self-evident).

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 301 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 04:38:05 GMT
From:      peterd@tscc2.macarthur.uws.edu.au ()
To:        comp.protocols.tcp-ip,comp.os.os2.apps
Subject:   IBM TCP/IP 1.2, SLIP fails to dial modem

Hi there all.
We have various machines run os/2 2.0 (With service pack) and IBM's
TCP/IP 1.2 (With the latest CSD's)

The problem :-
Using a 9600 baud modem (or any speed modem), the SLIPDIAL -d command
doesn't dial the modem. Data is sent to the modem (ie the RD light flashes)
but it don't dial :-( (And YES my SLIP.CMD file exists, and is correct.)

Anyone out there had similar problems ?
--
Peter Degotardi        (__)   *  University of Western Sydney, Macarthur
PC Support Programmer  /00\   *  Computing Centre.
Fax    +61 46 26-6937   oo    *  Campbelltown, New South Wales, Australia !
Email  p.degotardi@uws.edu.au *  Just in case - 'My opinions are all mine !'

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 92 05:56:49 GMT
From:      claborne@npg-sd.SanDiegoCA.NCR.COM (Chris Claborne)
To:        comp.protocols.tcp-ip
Subject:   SLIP from PC to Netblazer

Has anyone use the Wollongong SLIP driver to connect to a Netblazer?  I am 
close but can't get it to wrok.  One possible problem is that I have to 
dial in to the Neblazer first something like Procomm and then exit without
hanging up the line then start the protocal up.  Can't get a ping.


                                    ...  __o
                                   ..   -\<,
chris.claborne@sandiegoca.ncr.com  ...(_)/(_).                 CI$: 76340.2422

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 16:56:55
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:

    I don't disagree with your statements, however, I was curious about
    the systems you execute on.  Specifically, when a process is
    terminated, what happens to the open file descriptors?  Aren't they
    typically "closed"?  Doesn't TCP typically map this into a "normal
    connection close"?

This is one of the places where attempts to "make network connections look
just like files" start to get rocky.  The "close on termination" happens
because 1) close is an operation that already exists, thus it's easy,
2) close is most likely to preserve data and abet debugging, and 3)
close is necessary for overall filesystem consistency.  There are many
times I've wished I could find out "file closed during program abort"
from a directory listing, but OS designers haven't gotten that far.  TCP
can (and in my opinion, should) be more informative.

    ... Can you cite an RFC which gives guidelines as to when TCP should
    inject an RST on behalf of the application?  

As far as I know, none of the relevant RFCs attempt to say anything about
the API to TCP (for fear of getting embroiled in OS Wars).  This has
always seemed to be a "goes without saying" issue to me, but maybe it
will be mentioned in a future Host Requirements document.

    NOTE - this only works if the peer system does something meaningful
    with the receipt of the RST, and of course, the application would
    have to be in-sync with the propagation of the RST event.

All "reasonable" TCPs let applications know they've been RST, since that's
the only way to notice when the other system's crashed and rebooted.
    
    This option seems clean and straight-forward.  The problem is
    I am not aware of implementations "providing and using" a 
    similar capability.

PC/TCP for DOS provides a "normal close" service to applications which
exit without cleaning up all their connections.  If we can detect that
the application was aborted or ^C'ed, we generate RST segments.  If
the PC is powered off, we can't do anything.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488


-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 15:39:29 GMT
From:      kro@kvamdata.no (Knut Rogde)
To:        comp.protocols.tcp-ip,comp.os.os2.networking,comp.os.os2.programmer
Subject:   TCP_NODELAY after accept()

Hi,

In the process of developing a client server concept based on TCP/IP,
I've come across a problem:

I need to set the TCP_NODELAY option (like the X window system does) in
order to get fast query-response.

I've managed to set this option on the caller side just after making the
socket() call, but I can't make this work on the callee side.

Whent I try to do 

{
   s = accept(...);
   mi=1;
   e = setsockopt(s,IPPROTO_TCP,TCP_NODELAY,&mi,sizeof(int));
}

setsockopt returns -1.

I've seen that they do this in X, so it should be possible...

I would appreciate any ideas you might have.

Knut Rogde


-- 
------------------------------------------------------------------------
Knut Rogde                      Phone : +47 4 623766
Software engineer               Fax   : +47 4 623985
Kvam data as                    Email : kro@kvamdata.no

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 15:43:36 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: flow control, TCP, and ATM

In article <BxLs14.Gu@usenet.ucs.indiana.edu> robelr@mythos.ucs.indiana.edu writes:

>I just want to clarify that my intent was not to dismiss
>end-to-end congestion control.  Rather, it was to point
>out one weakness with CURRENT implementations of TCP (and 
>by that I mean mainstream commercially available implementations,
>not experimental ones).  If TCP can be modified so that this
>and other weaknesses are fixed, great.

Allen,

  The good vendors already ship a Van Jacobson TCP with their standard
product.  I believe that SGI is one example of such a vendor.  There
are other commercial vendors with this.  The Van Jacobson TCP is not
nearly as experimental these days as your note implies.  In fact it is
out as a standards track RFC already and is mostly past experimentation.

  As Rob Warnock pointed out, Jon Crowcroft had an article last
January or so (probably in CCR, maybe in IEEE Networks) proposing a
way to smooth the TCP oscillation.  That proposal is still
experimental though the article sounded very well thought out and
solidly worked to me.  Oscillation of TCP is not a big factor over ATM
as near as I can tell at the moment.

Ran
atkinson@itd.nrl.navy.mil

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 92 17:34:07 GMT
From:      dove+@pitt.edu (Daniel L Dove)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   HELP with a Directed Research in TCP/IP,WinTCP


	Help, I'm doing a directed research next semester on TCP/IP. If

there is anyone out there that can give me any info, FTP sites, etc....

Please let me know. We are run WinTCP.

	Please send Email

		dove@unix.csi.pitt.edu
		dove@vms.cis.pitt.edu


		Thanks in Advance


			Dan Dare


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 17:49:02 GMT
From:      wbrand@krishna.shearson.com (Willy Brandsdorfer)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: SNA <-> IP Encapsulation

In article <1992Nov12.082646.1647@msus1.msus.edu> mndot@msus1.msus.edu writes:


>   I am new to this particular news feed so this may have been asked in the past.
>   I am not very familiar with IBM host equipment either.
>
>   I am trying to provide mainframe connectivity to a number of remote sites. 
>   Most of the sites have IBM 3174 (or compatible) remote controllers for SNA
>   communications.  This comm. takes place over multidrop 9600 bps lines.  We are
>   in the process of installing T1 circuits to all of those same locations.  The
>   T1's are primarily IP.  Does software exist for the 3174 to allow SNA
>   encapsulation in IP packets?  I have seen hints of this scenario on some of the
>   news feeds but I am not sure which ones.  Any help with this would be greatly
>   appreciated.

	
	Cisco routers support SNA encapsulation. 

----------------------------------------------------------------------
William Brandsdorfer            | UUCP:    !uunet!shearson.com!wbrand
Lehman Brothers                 | INET:    wbrand@shearson.com
388 Greenwich St.               | Voice:   (212) 464-3835
New York, N.Y. 10013            | 
----------------------------------------------------------------------
 

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1992 17:50:53 GMT
From:      aj639@cleveland.Freenet.Edu (Michael Cox)
To:        comp.protocols.tcp-ip
Subject:   Scott Bradner's Bridge/Router Results


Does anyone know Scott or know where I can get ahold of the results of his
testing?  I think he did it in Jan/Feb of 92.  Please email me with any
leads.  Thanks in advance!!

Mike
-- 
Okay, look for AmoNER #5 on: ux1.cso.uiuc.edu (128.174.5.59) in /amiga/amoner
nic.funet.fi (128.214.6.100) in /pub/amiga/programming/amos
Je suis venu ici pour macher du chewing-gum et pour botter des fesses.
Et maintenant, je n'ai plus de chewing-gum . . .

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 18:34:38 GMT
From:      rks@chiasmus.engin.umich.edu (Raul Shum)
To:        comp.protocols.tcp-ip,comp.os.os2.apps
Subject:   Re: IBM TCP/IP 1.2, SLIP fails to dial modem


Well, I have somewhat the same problem... My computer has a direct connection 
to a SCP, (yes they do still exist).  Howver, I have to engage the SCP from 
a vt100 to a SLIP protocal. To do that, I have to type SLIP when I dial in.
However, IBM's TCP/IP doesn't let you do that.  Furthermore, I've been trying
to call using a modem and setting up the connection, and then hook up TCP/IP.
	However, the COM port resets itself after the prog closes, so the SCP
resets itself.  Does anyone know of a way to get a prog or a REXX script that
keeps the COM port (ie COM1) open???  I talked to the head-honcho at IBM, and
all he said was that I had to rewire my COM port... However, I was not your 
typical re-wiring...  Anyway, thanx in advance...

Raul Shum
Go Maize and Blue!

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 92 19:13:00 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Is telnet protocol documented?

Well, it wasn't as easy as I thought it might be, so I thought I'd ask
the experts...

Does  anyone  know  (or  know of documentation on) how a program might
talk to telnetd and make a connection?

What the project involves is:  I have a chunk of code that was written
to  call out via a serial port, modem, and whatever, to make a link to
another computer, login, start up a remote daemon, and so  on.   Sorta
like your usual uucp or slip daemons, y'know.  Someone was asking "How
hard would it be to make this software talk across TCP?" I  opined  as
how  it  shouldn't  be too hard; I'd just find all the code that dealt
with a serial port, and write some parallel code to  do  TCP  instead.
Rather than open("/dev/%s",...), I'd have it call gethostbyname("%s"),
and similar stuff.

It wasn't too hard to do this (maybe a day's work), and it all  worked
fine,  except that when the connect() returned success and the program
wrote something down the line, instead of a "login:" that I get when I
type  "telnet  %s",  it  gets  utter  garbage.   The  garbage is quite
consistent:  It consists of the 3 bytes FF FD 18,  and  then  it  gets
nothing  else.  Eventually the connection goes away, as if telnetd had
given up in disgust or something.

When I put my own tcpserver on  the  other  end  (which  just  accepts
connections  and  echoes  back  whatever  it receives), then my client
program gets just what I expect.  (If I tell the client to send "Hello
there!\r",  tcpserver  gets  back  exactly those bytes, it's log shows
that it got them and echoed  them,  and  the  client  reports  getting
them.)  This  is proof that it is making the connection correctly, and
is able to exchange messages sanely with whatever is at the other end.

But if it's telnetd at the other end, my client just gets  the  FF  FD
18, and the link goes nowhere.  It seems obvious that telnetd is doing
some sort of binary handshake on startup.  But  I  haven't  found  any
description of what it might be in TFM, or in the few RFCs that I have
copies of.

Now I suppose I could just write my own verion of  telnetd  that  does
things  in  a  way that I understand.  But telnetd is already there as
off-the-shelf (or is it off-the-wall?  ;-)  software  on  zillions  of
machines, so why reinvent the wheel, as they say?

Any idea how I might get documentation of telnetd's protocol? Is there
an RFC on it that someone can email me?  Is there some  PD  code  that
does the protocol?  Or is it some proprietary stuff that isn't for the
likes of me?

[Meanwhile, maybe I'll just barge ahead with making my own daemon, for
cases where telnetd isn't there or can't be made sane or ... ;-]

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

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 1992 20:07:23 GMT
From:      klf@fssun09.dev.oclc.org (Kim Fortney)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Requesting info on DNS

I'm currently looking into modifying DNS for adding a load balancing capability.
This would allow Internet users to access our systems using a single IP address.  

I'm looking for a reference to a version of public domain source code.  
Any pointers you can give would be greatly appreciated.

Thanks.

Kim Fortney	(klf@oclc.org)					
OCLC
6565 Frantz Road
Dublin, Ohio 43017

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 92 23:22:03 GMT
From:      jallard@microsoft.com (James 'J' Allard)
To:        comp.protocols.tcp-ip
Subject:   Re: Programmatic Interface to FTP

In article <1992Nov11.164406.22599@decuac.dec.com> cole@gsg.dec.com writes:
>
>I have a request from a customer for a programmatic interface to
>ftp.  While not difficult to implement, I have not heard of
>any UNIX vendors with this capability.  Is anyone aware of
>such an implementation that might be used as a guideline
>for calling syntax, etc.

A number of PC vendors provide programmatic APIs for FTP. Off the top
my head, I'd recommend you try Net Manage and Distict for examples.. 

J. Allard
Microsoft Corp.
(jallard@microsoft.com)
 

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 1992 00:22:09 GMT
From:      hank@ducvax.auburn.edu
To:        comp.protocols.tcp-ip,comp.os.os2.apps
Subject:   Re: IBM TCP/IP 1.2, SLIP fails to dial modem

In article <1992Nov12.183438.26104@zip.eecs.umich.edu>, rks@chiasmus.engin.umich.edu (Raul Shum) writes:
> However, IBM's TCP/IP doesn't let you do that.  Furthermore, I've been trying
> to call using a modem and setting up the connection, and then hook up TCP/IP.
> 	However, the COM port resets itself after the prog closes, so the SCP
> resets itself.  Does anyone know of a way to get a prog or a REXX script that
> keeps the COM port (ie COM1) open???  I talked to the head-honcho at IBM, and
> all he said was that I had to rewire my COM port... However, I was not your 

I'm not certain that I understand the more subtle points here, but...
Look, for example, at C-Kermit and M2Zmodem. C-Kermit can shell to M2Zmodem,
and M2Zmodem gets the com port. This won't work for just any programs, but
if your app can be passed the handle for the com port, you could login with
C-Kermit, then shell to your program. 

-- 
--Darrel Hankerson hank@ducvax.auburn.edu

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 1992 03:08:11 GMT
From:      ss@panix.com (Steve Steinberg)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.ultrix
Subject:   Need PCNFSD for DEC Ultrix

Can someone point me to PCNFSD for ultrix?  Preferebly one that would
work under miscd.  This would be for PC/TCP's Idrive.

Thanks!
-- 
=====================================================================
=== Steve Steinberg   ==  ss@panix.com  == {cmcl2,apple}!panix!ss ===

              (The space below intentionally left blank)           

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 92 03:37:19 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: Detecting Dropped Sockets (Why is this hard on PC's?)

In article <921112165655@cream.ftp.com>, jbvb@vax.ftp.com  (James B. VanBokkelen) writes:
| In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
| 
|     I don't disagree with your statements, however, I was curious about
|     the systems you execute on.  Specifically, when a process is
|     terminated, what happens to the open file descriptors?  Aren't they
|     typically "closed"?  Doesn't TCP typically map this into a "normal
|     connection close"?
| 
| This is one of the places where attempts to "make network connections look
| just like files" start to get rocky.  The "close on termination" happens
| because 1) close is an operation that already exists, thus it's easy,
| 2) close is most likely to preserve data and abet debugging, and 3)
| close is necessary for overall filesystem consistency.  There are many
| times I've wished I could find out "file closed during program abort"
| from a directory listing, but OS designers haven't gotten that far.  TCP
| can (and in my opinion, should) be more informative.

	Curiously enough, the old 2.9BSD (aka 4.1c) networking code
went to some lengths to get an indication of whether a socket was
closed explicitly by the process.  As I recall, this involved a
new argument to the internal kernel closef() function and, of course,
changes to every call to said function.  The argument was passed
as true when the process actually called close() and false when
closef() was invoked as part of exit handling.  (It may not have been
completely obvious which way things went on an implicit close caused
by, e.g., dup2(). :)
	After all this bother, the tcp/ip code did very little with
the information.  I don't remember whether this was because of a
real bug or because of a ``fix'' to correct problems caused by
doing something extreme like sending RST.  The original intent
was almost certainly to prevent processes from getting hung in
an exiting state, rather than to inform the peer that something
funny had happened.  In any case, the code disappeared long before
4.3BSD but at least it has been tried...

				Dan Lanciani
				ddl@harvard.*

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 1992 14:40:07 -0600
From:      CIR_TLW@VAX1.UTULSA.EDU (Tristia Watson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Print Drivers?

  
  We have an problem to which we are sure there has to be a solution...but
  have no idea what that solution might be...
  
  We have a Zenith 486, with a Cabletron Card (network connection) and we
  would like to print from Windows 3.1 to a DEC LPS400 using TCP/IP
  connections.  We would like to be able to do this without Pathworks or
  Novell or any kind of other "formal" network...besides TCP/IP.  The problem
  that we are seeing is that Windows doesn't have the necessary print
  drivers.  Are there any TCP/IP-only drivers that might help, either public
  domain or otherwise?  Any other ideas that might be useful?
  
      +---------------------------------------------------------------------+
      | Tristia Watson                              CIR_TLW@VAX1.UTULSA.EDU |
      | Client Support Coordinator                     HELP@VAX1.UTULSA.EDU |
      | Computing & Information Resources Help Desk        Phone:  631-3500 |
      +---------------------------------------------------------------------+


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 92 12:21:41 GMT
From:      petter@fdmetd.uucp (Petter Henrik Hansen)
To:        comp.protocols.tcp-ip
Subject:   Information wanted

Does anyone have any information, or know where to get some info about
a product calles xcon 62?
xcon 62  (TCP/IP -> LU6.2)

Thanks

Petter Henrik Hansen,  Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY
Phone : +47 2 52 84 02                            Fax   : +47 2 52 85 10
E-mail : ...!mcsun!nuug!fdmetd!petter   or       petter@fdmetd.uucp
	or petter%fdata.uucp@nac.no
<The opinions expressed, if any, do not represent Fellesdata a.s>

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 1992 17:24:00 GMT
From:      modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   NFS


Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM 
mainframe via TCP/IP? If so, how?

I have tried backing up my PC to the IBM mainframe with NFS. The IBM
mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and 
Interlink's SNS/NFS. First, I created an NFS connection from my PC to
the IBM mainframe and tried to XCOPY my PC's hard disk to the designated 
NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e.  It would 
only copy my current directory and nothing more.

Then I tried to FTP my PC's whole hard disk. Is there   way to FTP the whole
hard disk of a PC to the  mainframe? I could only again find a way to FTP  one
directory at a time. I am using FTP's PC/TCP software.           

I would really appreciate anyone's ideas or if anyone is doing this, how. 

Please send all responsess to modic@gumby.dsd.trw.com 

Thanks, Jeanine


Jeanine Modic
TRW
Communication Services
modic@gumby.dsd.trw.com
Redondo Beach, California

Newsgroups: comp.protocols.ibm comp.protocols.tcp-ip
Subject: NFS
Distribution: trw


Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM 
mainframe via TCP/IP? If so, how?

I have tried backing up my PC to the IBM mainframe with NFS. The IBM
mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and 
Interlink's SNS/NFS. First, I created an NFS connection from my PC to
the IBM mainframe and tried to XCOPY my PC's hard disk to the designated 
NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e.  It would 
only copy my current directory and nothing more.

Then I tried to FTP my PC's whole hard disk. Is there   way to FTP the whole
hard disk of a PC to the  mainframe? I could only again find a way to FTP  one
directory at a time. I am using FTP's PC/TCP software.           

I would really appreciate anyone's ideas or if anyone is doing this, how. 

Please send all responsess to modic@gumby.dsd.trw.com 

Thanks, Jeanine


Jeanine Modic
TRW
Communication Services
modic@gumby.dsd.trw.com
Redondo Beach, California

Newsgroups: comp.protocols.ibm, comp.protocols.tcp-ip
Subject: NFS
Distribution: trw

Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM 
mainframe via TCP/IP? If so, how?

I have tried backing up my PC to the IBM mainframe with NFS. The IBM
mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and 
Interlink's SNS/NFS. First, I created an NFS connection from my PC to
the IBM mainframe and tried to XCOPY my PC's hard disk to the designated 
NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e.  It would 
only copy my current directory and nothing more.

Then I tried to FTP my PC's whole hard disk. Is there   way to FTP the whole
hard disk of a PC to the  mainframe? I could only again find a way to FTP  one
directory at a time. I am using FTP's PC/TCP software.           

I would really appreciate anyone's ideas or if anyone is doing this, how. 

Please send all responsess to modic@gumby.dsd.trw.com 

Thanks, Jeanine


Jeanine Modic
TRW
Communication Services
modic@gumby.dsd.trw.com
Redondo Beach, California

Newsgroups: comp.protocols.ibm comp.protocols.tcp-ip
Subject: NFS
Distribution: trw


Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM 
mainframe via TCP/IP? If so, how?

I have tried backing up my PC to the IBM mainframe with NFS. The IBM
mainframe involved has Interlink's SNS/TCPaccess TCP/IP software and 
Interlink's SNS/NFS. First, I created an NFS connection from my PC to
the IBM mainframe and tried to XCOPY my PC's hard disk to the designated 
NFS drive (allocated as the mainframe) i.e. XCOPY c: g: /s /e.  It would 
only copy my current directory and nothing more.

Then I tried to FTP my PC's whole hard disk. Is there   way to FTP the whole
hard disk of a PC to the  mainframe? I could only again find a way to FTP  one
directory at a time. I am using FTP's PC/TCP software.           

I would really appreciate anyone's ideas or if anyone is doing this, how. 

Please send all responsess to modic@gumby.dsd.trw.com 

Thanks, Jeanine


Jeanine Modic
TRW
Communication Services
modic@gumby.dsd.trw.com
Redondo Beach, California


-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 92 18:31:28 GMT
From:      sgriffee@nynexst.com (Steve Griffee)
To:        comp.protocols.tcp-ip
Subject:   remote tcp/ip LAN access ideas

thanks
Steve

The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue
914-644-2531  fax: 914-644-2301      White Plains, NY 10604

This is your email.  This is your brain on email.  Any questions?
-- 
The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 1992 19:18:05 GMT
From:      davecb@nexus.yorku.ca (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Can anyone point me to info about ``Fibre Channel''

  I confess I'm terribly ignorant of almost everything about fibre
channel save its speed.  Can anyone point me toward information
on it? I know that there ia an ANSI comittee, X3T9.3, and that 9.5
is FDDI, but I don't know hat 9.3 is...  
  If it's a common question, I'll post the answers (:-))

--dave (and can you run ip over it!!) c-b

-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional email consultant.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 1992 20:33:09 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Is telnet protocol documented?

In article <1391@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>...except that when the connect() returned success and the program
>wrote something down the line, instead of a "login:" that I get when I
>type  "telnet  %s",  it  gets  utter  garbage.   The  garbage is quite
>consistent:  It consists of the 3 bytes FF FD 18...

Uh, telnet is a *protocol*; it is not an uninterpreted data path.  You're
looking at a telnet option-negotiation sequence.

>Any idea how I might get documentation of telnetd's protocol? Is there
>an RFC on it that someone can email me? ...

You get documentation on telnet the same way you get documentation on
any of the Internet protocols:  read the relevant RFCs.  For telnet, it
starts with RFC 854.  Actually, you probably want to look at the telnet
section of RFC 1123 first, as there are a whole bunch of telnet-related
RFCs and you need to know which ones matter.
-- 
MS-DOS is the OS/360 of the 1980s.      | Henry Spencer @ U of Toronto Zoology
              -Hal W. Hardenbergh (1985)|  henry@zoo.toronto.edu  utzoo!henry

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Nov 1992 21:33:08 GMT
From:      mlikier@novell.com (Marty Likier)
To:        comp.protocols.tcp-ip
Subject:   Re: Scott Bradner's Bridge/Router Results

In article <1du5huINNu6@usenet.INS.CWRU.Edu> aj639@cleveland.Freenet.Edu (Michael Cox) writes:
>
>Does anyone know Scott or know where I can get ahold of the results of his
>testing?  I think he did it in Jan/Feb of 92.  Please email me with any
>leads.  Thanks in advance!!
>
>Mike

Scott just finished the fall 92 results. They can be anonymous FTPd
from hsdndev.harvard.edu (128.103.202.40). They are in the directory
pub/ndtl.

Marty Likier


-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 92 01:22:42 GMT
From:      andrew@frip.WV.TEK.COM (Andrew Klossner)
To:        comp.unix.misc,comp.protocols.tcp-ip,comp.lang.postscript
Subject:   Re: problems tfping to a rip

[]

	"The reason seems to be that the UDP checksum is wrong.
	normally this checksum is correct, but the troublesome packets
	always have 0xFFFF for checksum. if my calculations are correct
	it should be 0x0 instead."

No, a UDP checksum is never 0.  If the calculation yields 0, then
0xFFFF is stored instead.  Perhaps the code in the RIP is flawed and
does not include this provision.  A 0 in the UDP checksum field means
"no checksum was computed."

From RFC768, the defining document for UDP:

> If the computed  checksum  is zero,  it is transmitted  as all ones (the
> equivalent  in one's complement  arithmetic).   An all zero  transmitted
> checksum  value means that the transmitter  generated  no checksum  (for
> debugging or for higher level protocols that don't care).

	"What is your solution"

Convince the Intel machine not to generate UDP checksums.  On the Suns,
whether or not to UDP checksum is controlled by a variable in the
kernel; you use adb or equivalent to patch it.  Check with your Intel
rep to see if they have something equivalent.

In the long term, you should ask Linotype to fix their broken UDP
implementation.

  -=- Andrew Klossner  (andrew@frip.wv.tek.com)
                       (uunet!tektronix!frip.WV.TEK!andrew)

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 92 01:29:46 GMT
From:      kdlin@advtech.uswest.com (David Lin)
To:        comp.protocols.tcp-ip
Subject:   Flow Control

I understand that many end-to-end sliding window flow control schemes 
( eq. in TCP/IP and in XTP ) use byte as the unit for calculation. For 
example, if the window size is 6K bytes and you have transmitted 2K bytes
without receiving ACKs from the receiver, then you are allowed to transmit
4K more bytes.

Now, if I change the unit for flow control calculation to packet ( or 
frame ), what is the impact to the whole system? What's the implication?

Since most networks have an upper limit for the frame size ( <= MTU ), 
I cannot transmit unlimited-size packets. Consequently, I will be treating
any packets of size in between 1 and MTU equally, as far as flow control
is concerned.

I understand that interactive traffic will be affected first. However,
packet video and packet voice may not be affected at all, especially
when they have real time delivery requirement.

So why am I doing this? I think it will simplify the computation 
needed for the flow control mechanism. Three more questions follow:

1. Are there any circumstances that this scheme ( using packet as
   the computation unit ) is desirable?

2. When it is NOT desirable?

3. Do I really achieve anything by doing that?

Many thanks.

David
-- 
 K. David Lin, Ph.D.              | E-mail: kdlin@advtech.uswest.com  
 Communication Services Research  | Defend your life with style! -- Beretta
 U S WEST Advanced Technologies   | Disclaimer: Only personal opinions

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 1992 18:05:59 GMT
From:      tomb@studsys.mscs.mu.edu (Tom Baas)
To:        comp.protocols.tcp-ip
Subject:   can't do a dir when ftp login as anonymous(HELP)


hi,
When I do an ftp to my system and login as anonymous, I get logged in fine,
but when I try to do a dir, I get:
425 Can't create data socket(0.0.0.0,20): no such file or directory
Can anyone tell me what I am doing wrong?
I am running under ISC Unix and whether I do an ftp to localhost or
if I telnet to another machine and then ftp back, I still get the same results.

Thanks to anyone in advance.  :) 

tom@tbaas.mil.wi.us     or   tbaas!tom       or   tom@tbaas
-- 
I can accept e-mail and Voice-mail at:
tbaas!tom   or   tom@tbaas.mil.wi.us    or ...spool!tbaas!tom  
or Voice at: 1-414-377-4038

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 92 22:49:21 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: can't do a dir when ftp login as anonymous(HELP)

tomb@studsys.mscs.mu.edu (Tom Baas) writes:

}When I do an ftp to my system and login as anonymous, I get logged in fine,
}but when I try to do a dir, I get:
}425 Can't create data socket(0.0.0.0,20): no such file or directory
}Can anyone tell me what I am doing wrong?
}I am running under ISC Unix and whether I do an ftp to localhost or
}if I telnet to another machine and then ftp back, I still get the same results.

Is ~ftp/bin/ls present and correctly permissioned?

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

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 92 23:15:32 GMT
From:      sl870@europa.ee.usu.edu (ullas gargi)
To:        comp.protocols.tcp-ip
Subject:   Name Server Lookup: No. to Name?

Hi,

How does one convert an internet no. (address) to an internet (canonical) name?
NSLOOKUP doesnt seem to have an option for it, only for the other way round of
direct name lookup, not the reverse lookup.
(I couldn't find the FAQ in case this is in there)

Thanks

Ullas Gargi
sl870@europa.ee.usu.edu

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 92 04:29:01 EST
From:      seths@schroedinger.engin.umich.edu (seth raynard silverman)
To:        comp.protocols.tcp-ip
Subject:   PPP Packet Driver for PC/TCP?

[ Article crossposted from comp.protocols.tcp-ip.ibmpc ]
[ Author was seth raynard silverman ]
[ Posted on Mon, 16 Nov 92 04:25:51 EST ]

I was wondering if anyone knows of a Packet Driver for the PPP protocol.  I
need it to work the ETHDRV kernel of PC/TCP for DOS v2.01.  I was told that
FTP software has released PPP support in version 2.1, but I was hoping that
something was available that will work with my version.

Also, I am looking for a way to automatically configure the IP address of
my PC when using a SLFP (Serial Line Framing Protocol) packet driver.  I
have been told about RARP, but I am not aware of any RARP packages that
work with PC/TCP.

Any help would be greatly appreciated.

Seth Silverman

e-mail:  seths@eecs.umich.edu

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 92 03:28:41 GMT
From:      act@softserver.canberra.edu.au (Andrew Turner)
To:        comp.protocols.tcp-ip
Subject:   Getting the ethernet address off (SMC)WD8003E Lan Cards

Would someone please e-mail(I'll on-forward if you too want same - e-mail
requests) a code fragment assembler/pascal/C that will return the ethernet
address from an WD8003E card.

Technical specs  and/or info on where I could get the info would also be
welcome.

I need this info to produce a PC management program which will use the
ethernet address as the PC identifier.

Many Thanks
-- 
Renrut Werdna			Probable-Possible, my black hen,
				She lays eggs in the Relative When.
				She doesn't lay eggs in the Positive Now
act@ss.canberra.edu.au		Because she's unable to postulate how

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 1992 03:56:27 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Name Server Lookup: No. to Name?

In article <1992Nov15.171533.60873@cc.usu.edu>, sl870@europa.ee.usu.edu
 (ullas gargi) wrote:
>How does one convert an internet no. (address) to an internet (canonical) name?
>NSLOOKUP doesnt seem to have an option for it, only for the other way round of
>direct name lookup, not the reverse lookup.

Let's say the IP address you want to map to a domain name is
[11.22.33.44], the following sequence would do it.

	nslookup
	set q=ptr
	44.33.22.11.in-addr.arpa.
	^D

Note that while the IP address is [11.22.33.44], its corresponding
name inside the reverse lookup domain .IN-ADDR.ARPA is 44.33.22.11
(reverse order). 

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 1992 04:43:18 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: Name Server Lookup: No. to Name?

In article <1992Nov15.171533.60873@cc.usu.edu> sl870@europa.ee.usu.edu (ullas gargi) writes:
>Hi,
>
>How does one convert an internet no. (address) to an internet (canonical) name?
>NSLOOKUP doesnt seem to have an option for it, only for the other way round of
>direct name lookup, not the reverse lookup.
>(I couldn't find the FAQ in case this is in there)

The domain name for 128.1.2.3's "reverse lookup" is:

3.2.1.128.in-addr.arpa.

That's right.  Reverse the octets, and add "in-addr.arpa" to the end.  Ask
for that with record type "PTR".  You'll get the name associated with the IP
number (assuming the DNS administrator for that domain correctly set up the
DNS system).

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 1992 09:29:16 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting the ethernet address off (SMC)WD8003E Lan Cards

In article <1992Nov16.032841.7572@csc.canberra.edu.au>,
 act@softserver.canberra.edu.au (Andrew Turner) wrote:
>Would someone please e-mail a code fragment assembler/pascal/C
>that will return the ethernet address from an WD8003E card.

	unsigned int i, sum = 0, io_base = 0x...;
	unsigned char eprom[8];
	...
	for (i = 0; i < 8; i++)
	    sum += (eprom[i] = inportb(io_base + 8 + i));
	sum &= 0x00ff;
	if (sum != 0xff)
	    /* checksum failed, possibly no board there */
	else
	    printf("MAC address = %02x:%02x:%02x:%02x:%02x:%02x\n",
		eprom[0], eprom[1], eprom[2], eprom[3], eprom[4], eprom[5]);

If you use a Packet, NDIS or ODI driver to access your card, you
could also call the driver to query for the MAC address instead of
asking the card directly as in the above.

>Technical specs and/or info on where I could get the info would also be
>welcome.

SMC/WD provides a driver development kit to those who want to write
codes to talk to the card directly.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 92 11:28:27 GMT
From:      HS99@music.mus.polymtl.ca (S. Guimont)
To:        comp.protocols.tcp-ip
Subject:   IRC (Internet Relay Chat) protocol need

Hello,
       Where I can find the IRC (Internet Relay Chat) protocol?
(Or if somebody have it, Please send me...)

Thanks!

Regards, S. Guimont
RDI - Research and Development Informatik
Internet : hs99@music.mus.polymtl.ca
Bitnet   : hs99@polytec1.bitnet

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 92 12:03:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   X.25 X.29 software wanted for RS6000


	Hi, I've been entasked with locating software which runs
	on an RS6000 under AIX and which provides X.25 connectivity
	(serial 56Kbps links) and X.29 PAD (incoming and outgoing)
	as well as application hooks (like sockets).

	Can anyone here direct me to who makes or sells such
	software? 

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
"If the OSI developers are sending mail to each other, they're
 probably doing it over TCP/IP :-)"    -- Gary Scott Malkin

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 92 14:01:33 GMT
From:      yan_arrouye@gateway.qm.apple.com (Yan Arrouye)
To:        comp.protocols.tcp-ip
Subject:   Public dom impl of RFC1006 for MacTCP?



Is there any public domain implementation of RFC 1006 on top of MacTCP ?
Otherwise do you know any easy to port public domain implementartion of RFC
1006?

Thanks
Yan

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 1992 14:49:04 GMT
From:      rjberke@berke.itg.ti.com (Richard Berke)
To:        comp.protocols.tcp-ip
Subject:   FAQ - SLIP vs SLFP vs PPP

What are significant differences among those three?  
If your workstation and its software can support all of them,
which would you choose?  Why?

Thanks,
Richard Berke   RBRK   Richard.Berke@lobby.ti.com  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 92 19:08:58 GMT
From:      sgriffee@nynexst.com (Steve Griffee)
To:        comp.protocols.tcp-ip
Subject:   remote tcp/ip LAN access ideas

I'm looking for ideas for connecting remote PC and MAC workstations
to our TCP/IP LAN using regular dial-up phone lines.  I've seen all
the usual asynch access devices.  I'm looking at the relatively hi
bandwidth facilities such as ISDN.  For example, so far I have
found out about the IMAC ISDN bridge made by DigiBoard and the RLN
asynch bridge (using hi speed modems and regular phone lines) made
by DCA which uses the PPP protocol.  Has anyone else found any
interesting means of connecting remote offices or workstations to
the LAN?  Let's swap discoveries.  Can We Talk?  Please respond
directly to my email address below.  I will summarize all submitted
responses if requested.

Watch out.  Telecommuting may be just around the bend for your
company.  Don't let it catch you asleep at the wheel.

Thanks
Steve

The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue
914-644-2531  fax: 914-644-2301      White Plains, NY 10604

This is your email.  This is your brain on email.  Any questions?
-- 
The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 1992 22:37:38 GMT
From:      jon.taylor@uuserv.cc.utah.edu (JON M. TAYLOR)
To:        comp.protocols.tcp-ip
Subject:   Looking for a UNIX TELNET with Zmodem

	Title sez it all.  Does such a beast exist anywhere?

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 1992 23:55:22 GMT
From:      nancyf@sug.org (Nancy Frishberg)
To:        comp.protocols.tcp-ip,ba.internet
Subject:   Tutorials (12/7, San Jose) Internet & Protocols, Network Debugging (Sun User Group Conference)

If you're interested in the structure and protocols of the Internet or
debugging Sun networks, plan to be at the Sun User Group Conference
(San Jose Convention Center) on Monday, December 7, 1992.  The
Conference and Exhibition extends through Thursday.

"The Internet and its Protocols" is one of nine tutorials currently
scheduled for the first day of the Sun User Group Conference. Taught
by William LeFebvre (Northwestern University), the course will use
Douglas Comer's text "Internetworking with TCP/IP" and will cover
important protocols, packet routing, client-server model of
interaction and more.

Concurrently, Smoot Carl-Mitchell (Texas Internet Consulting) will
discuss "Sun Network Debugging" focusing on built-in network debugging
tools.  Other topics include diagnosing routing problems, nameservice
problems, networking snooping with Ping and other tools, and broadcast
storms on Ethernets.

SPECIAL OFFER: 5 full conference registrations (each includes a day of
any tutorial) for the price of 4 when preregistering with a single
payment.

Other full-day tutorials:
- Advanced Unix Security (Matt Bishop, Dartmouth College)
- Preparing for Disaster (a.m. - Brent Chapman, Great Circle Associates),
  plus, Why have Computer Security? (p.m. Bob Baldwin, Tandem Computers)
- Topics in Perl (Tom Christiansen, Convex Computer Corporation)	
- Programming in POSIX (Jeffrey S. Haemer, Canary Software)	
- UNIX Programming Tools (Kenneth Ingham, consultant)
- Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems)
- Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and Computer Systems)

If you just want to go to the exhibits, ask for a free show-only pass.

To get more information by email about these tutorials, the technical
program, or exhibits at the Sun User Group conference, send requests
to sugshow@sug.org .

You will receive the full tutorials and program description with
registration information.  Or call 1-800/727-EXPO.  (Outside the U.S.,
use 512/331-7761 (voice) or 512/331-3950 (FAX).)  

-- 
Nancy Frishberg, Sun User Group.







-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 01:56:32 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Is the Balkanization of the InterNet inevitable?


  Are network security firewalls between organizations and the InterNet
going to be the norm in the future?  This seems to be the answer some of
our local people think is inevitable.  I haven't had time to keep up with
network security issues for a couple of years, so I just don't know what
the state of current work is or what the consensus on this issue is.

  If the Balkanization of the InterNet is inevitable, I feel it will be a
great loss.  It will be an acknowledgement that irresponsible criminal
hackers have won from us our freedom of open inter-operation.  What a
sad thought.  Are there no other realistic options for providing security?
Is it impossible to conceive of effective authentication methods?

  If this has already been hashed out dozens of times before I'm sorry.
(I also haven't been able to keep up with USENET for some time.)  I'm
sure it's a flame-ridden topic.  But I'd really like to see a non-flame
driven dialogue on the topic.

Casey

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 92 01:59:18 GMT
From:      joe@igor.tamri.com (Joe Carlson)
To:        comp.protocols.tcp-ip
Subject:   CMUTEK for vms 4.7  name server? how?

I'm having trouble getting a domain server to respond to CMUTEK
tcp/ip in vms land (4.7)  Anybody got a namsrv.config or internet.config
(or other sorts of hints...) that could shed light on this for me?
I got hosts.txt to resolve names for the local machines and i can
telnet and ftp if i know the address, but i have problems beyond that.

sorry if this is a RTFM, but i don't got no FM.

joe@igor.tamri.com
or
jcarlsn@itsa.ucsf.edu


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 07:22:49 GMT
From:      gutherz@europa.rutgers.edu (Matt Gutherz)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   routing trouble - one ethernet/two subnets



Hi. 

I have an ethernet segment configured to support two different
subnets.  Unfortunately the routers serving this segment only
generate one routing update sourced from one of its two configured
IP addresses on that segment.  For the SUN workstations in the
subnet that the routers sources the update from this is not a
problem.  Routed functions properly.  The SUN workstations
in the other subnet are not as fortunate.  Routed on these machines
is currently not excepting updates from a router it considers
non-local.  

Does anyone have any ideas how I might be able to make this
work (without using gated or fudging subnet masks on the 
workstations)?  The SUNs are 4.1.

Thanks.

Matt Gutherz
matt@japan.sbi.com	"Savoir Faire is everywhere."
-- 
blah!

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 08:36:45 GMT
From:      drake@drake.almaden.ibm.com (Sam Drake)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: NFS

In article <1992Nov13.172400.5004@gumby.dsd.trw.com> modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona) writes:
>
>Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM 
>mainframe via TCP/IP? If so, how?

IBM sells a (ahem) wonderful product to do this, the Workstation Data Save
Facility.  Allows you to back up DOS, AIX, OS/2, SunOS and Mac clients
to a central VM mainframe.  The follow-on product, DFSMS, supports the same
clients and both VM and MVS mainframes.

Backup and restore are completely automatic; you can retrieve previous versions
of files; both disk and offline media are supported in a storage hierarchy;
etc.   Designed to back up all your PCs and workstations without strain.


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 08:40:15 GMT
From:      P88037@BARILVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   PC control over TCPIP

Question: is there a software that allows one to control a PC via TCPIP,
i.e. telnet to the PC and get a DOS prompt?

please mail to elharrar@bimacs.cs.biu.ac.il or reply in post.

Thanks!

          Yair

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 09:21:54 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp sample sources wanted



 >
 >	Are the sample sources available from the Comer or Stevens books on
 >	tcp/ip - UNIX Network programming? 
 >

stevens' stuff is certainly gettable

e.g. (from archie)
emx.cc.utexas.edu:/pub/netinfo/src/netprog
or 
nic.ddn.mil:/netprog/

i havnt seen comers...srconline, but archie says
arthur.cs.purdue.edu:/pub/comer/
has something in!

 jon


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 12:37:36 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and ISDN / experiences with ISDN ?


Hi guys !
I would like to know something about ISDN !
Which possibilities are there to use TCP/IP over
ISDN ?
How does it work (it would be nice to geta any details!) ?
How about ISDN in other countries or between countries ?
ISDN between:
germany and UK ?
germany and spane ?
germany and france ?
germany and USA ?

Any experiences with ISDN ?
Any information would be appreciated !


-- 
------ < MAGIC > ------

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 14:07:50 GMT
From:      paul@tivoli.UUCP (Paul Greenspan)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: TLI and non-blocking I/O

I just wanted to thank all of the people that helped with our problem
with non-blocking I/O, TLI and SVR4.

The problem has been determined to be a bug in SVR4 that shows up
when the same process uses both TCP and UDP and uses non-blocking
endpoints. 

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

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 14:28:56 GMT
From:      craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
To:        comp.protocols.tcp-ip
Subject:   NIS broadcasts over IP subnets

I have a potential problem with NIS in the presence of subnets. Advice would 
be appreciated.

If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255
in the case of 24 bit subnets), a router will not propogate the broadcast onto
other subnets on the LAN and hence the client won't be able to bind to a NIS
server unless a server is on the same subnet. If however the NIS client
broadcasts to the class B broadcast address (130.159.255.255) even when using
an 24 bit subnet mask, the router can be configured to forward all subnet 
broadcasts and there is no problem. 

Which way does NIS do it? 

-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K. 

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 92 14:30:12 GMT
From:      berman@nlm.nih.gov (Lew Berman)
To:        comp.protocols.tcp-ip
Subject:   tcp client/server performance

I am building a client/server to transfer 5Mbyte 
images over the internet.  The system is up and running, 
but I would like to know what I can do to improve the
performance of the system.  Besides data compression, 
different protocols (VMTP, etc.), what can I do with the
standard sockets, etc?

I've changed the SO_RCVBUF and SO_SNDBUF size at both the
client and server sides so that they are now 16384 bytes.
Should I make them larger?  How large can they be (I'm 
on SUN workstations)?  Currently I just do one massive
write into the socket, should this be split into smaller
blocks and then written to the socket?  If so, what would
be a good size block?  

Any other suggestions for improving the performance?


Please send all e-mail directly to me and I will repost
to the net.

Thanks,

Lew Berman
National Library of Medicine
Bethesda, MD





-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 92 14:42:47 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.dcom.lans.ethernet,comp.dcom.isdn,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   remote tcp/ip LAN access ideas

In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes:

   Watch out.  Telecommuting may be just around the bend for your
   company.  Don't let it catch you asleep at the wheel.

   Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
   Data & Information Services          500 Westchester Avenue
   914-644-2531  fax: 914-644-2301      White Plains, NY 10604


Holy shit, Steve, is NYNEX just figuring this out?!?!???

No wonder It Still Does Nothing in New York.

Sorry for the gratuitious flamage, but maybe that's what the baby
bells need?

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

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 15:44:50 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: PC control over TCPIP

 P88037@BARILVM.BITNET writes:
>Question: is there a software that allows one to control a PC via TCPIP,
>i.e. telnet to the PC and get a DOS prompt?
>
>please mail to elharrar@bimacs.cs.biu.ac.il or reply in post.
>

This is often called a TELNETD, and there are four options:

1. Free TELNETD - it's not the greatest but it is free.  FTP to 129.97.50.50
   and get pub/wattcp/telnetd.zip

2. Beame&Whiteside include a TELNETD inside their BW-TCP 3.0.  The package 
   comes with other TCP applications like TELNET, FTP, a nifty LPD, etc.  
   Mail to sales@bws.com

3. Essex also includes a TELNETD with their collection of TCP applications
   and network stack called TCP/2.  I don't have an Email address.

4. SNSI specializes in TELNETD with versions for LanWorkPlace, PC/TCP, Pathway,
   Lantastic/TCP, Beame&Whiteside and packet drivers.  Mail to info@snsi.com

-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 15:47:27 GMT
From:      paola@hplb.hpl.hp.com (paola fulchignoni)
To:        comp.protocols.tcp-ip
Subject:   IP security labels


Could anyone give me more details about RFC 1108 (IETF document in which
security labels handling in IP packets is explained) and/or how to find it? 

Thanks,
Paola

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 16:03:14 GMT
From:      tching@target.uucp (Tracy Ching <SysAdmin>)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp sample sources wanted

In article <3223@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
> >	Are the sample sources available from the Comer or Stevens books on
> >	tcp/ip - UNIX Network programming? 
>
>i havnt seen comers...srconline, but archie says
>arthur.cs.purdue.edu:/pub/comer/
>has something in!
>
	Don't do this one... it is just for students to try an ftp session.
There is nothing there except for two file that say "are you kidding...
it was just an example in the text book"


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 16:07:55 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS broadcasts over IP subnets

In article <1992Nov17.142856.19947@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>I have a potential problem with NIS in the presence of subnets. Advice would 
>be appreciated.
>
>If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255
>in the case of 24 bit subnets), a router will not propogate the broadcast onto
>other subnets on the LAN and hence the client won't be able to bind to a NIS
>server unless a server is on the same subnet. If however the NIS client
>broadcasts to the class B broadcast address (130.159.255.255) even when using
>an 24 bit subnet mask, the router can be configured to forward all subnet 
>broadcasts and there is no problem. 

The best (and recommended by Sun) solution is to have an NIS slave on every
subnet.  It is not a good idea in general to configure your router to route
broadcasts outside of a subnet.  (The purpose of a router is to decrease
traffic, not increase it)

--Dave

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 16:38:25 GMT
From:      stewart@tweety.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS broadcasts over IP subnets

In article <1992Nov17.142856.19947@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>I have a potential problem with NIS in the presence of subnets. Advice would 
>be appreciated.
>
>If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255
>in the case of 24 bit subnets), a router will not propogate the broadcast onto
>other subnets on the LAN and hence the client won't be able to bind to a NIS
>server unless a server is on the same subnet. If however the NIS client
>broadcasts to the class B broadcast address (130.159.255.255) even when using
>an 24 bit subnet mask, the router can be configured to forward all subnet 
>broadcasts and there is no problem. 
>
>Which way does NIS do it? 

NIS was not designed so that clients on a LAN which have no NIS
servers (master or slave) for a given NIS domain could participate
in that domain.  You can use "ypbind" and "ypset" in /etc/rc.local
to do what you want (and many people, including me, do it), but it
is a kludge at best.  I understand from a "white paper" from Sun
that NIS+ is supposed to do this better.

Good luck.

/jws

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 17:41:09 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Balkanization of the InterNet inevitable?

In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes:
>   Are network security firewalls between organizations and the InterNet
> going to be the norm in the future?  This seems to be the answer some of
> our local people think is inevitable.  I haven't had time to keep up with
> network security issues for a couple of years, so I just don't know what
> the state of current work is or what the consensus on this issue is.
> 
>   If the Balkanization of the InterNet is inevitable, I feel it will be a
> great loss.  It will be an acknowledgement that irresponsible criminal
> hackers have won from us our freedom of open inter-operation.  What a
> sad thought.  Are there no other realistic options for providing security?
> Is it impossible to conceive of effective authentication methods?

For the most part, authentication isn't the issue.  We already know
how to build effective authentication methods; they just aren't deployed.
But even if they were, it wouldn't help that much.  There are too many
break-ins caused by buggy software and/or system administration errors.
The former is just a special case of the general software engineering
problem, and I don't think it's close to being solved.  The latter --
well, it would help if vendors would try to ship stuff in a default
secure configuration, but there are still so many knobs to twiddle
that mistakes are inevitable.

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 92 17:43:21 GMT
From:      steve@terminus.ericsson.se (Steve Reynolds)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp sample sources wanted

The Comer sources are available on tape from the publishers 
Prentice hall (sorry no ISBN)
The tape also holds XINU and some user contributed stuff

. cost about 100GBP

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 18:11:39 GMT
From:      syscrc@pickle.gsu.edu (Randy Carpenter)
To:        comp.protocols.tcp-ip
Subject:   Rigging up telnetd(1m) for an application.

We want users to be able to telnet into an application on an RS/6000
(running AIX 3.2) and not have to enter a login or password.  So, we are
considering using a binary editor (say "hex") to patch the telnetd(1) 
executable and substitute "/bin/fubar" instead of "/bin/login".
The program "/bin/fubar" will start the application (our University's
registration system).  Of course, we will provide the original telnetd(1)
on another port so that a real login is possible.

Will this interfere with any TELNET negotiations or cause other problems?

-- 
===========================================================================
Randy Carpenter                    rcarpent@gsu.edu          % Got a light?
Georgia State University           (404) 651-2648            No match.
Wells Computer Center                                        %

-- 
===========================================================================
Randy Carpenter                    rcarpent@gsu.edu          % Got a light?
Georgia State University           (404) 651-2648            No match.
Wells Computer Center                                        %

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 18:35:45 GMT
From:      ellingsen_jim@Tandem.COM (Jim Ellingsen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over Token-Ring

Do most TCP/IP over token-ring implementations
support source routing?  

Jim Ellingsen        ellingsen_jim@tandem.com
Tandem Computers
Cupertino, CA


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 18:58:20 GMT
From:      nectar@world.std.com (Jacques A Vidrine)
To:        comp.protocols.tcp-ip
Subject:   TN5250 ?

I'm looking for a TELNET 5250 client for
DOS or Microsoft Windows 3.x.  Does anyone
know of a freely available package?
-- 
Jacques A. Vidrine...	   |
nectar@world.std.com	   |  There's no use crying over
			   |  spilled mitochondria.
			   |		- Ren

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 19:03:08 GMT
From:      ihsan@ferranti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   TCP simul- & broadcast

At one time class D IP address (224.0.0.0 thru 255.255.255.254) were
reserved for simul-cast and of course 255.255.255.255 for broadcast.

I have a few questions reguarding TCP simul- and broadcasts, if
someone could please enlighten us:

1. What do the latest standards demand from an implementor in this
   regard.

2. What happens to TCP's reliable delivery feature, specially 
   in case of broadcast ?  Does it drop down to the level of UDP ?

3. What are the vendors providing  and supporting in the market place.

I think I saw an article saying that some one has used TCP simulcast
for video teleconferencing (over ISDN perhaps) but I am not sure.


-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 20:22:59 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS broadcasts over IP subnets

In article <c241Hya0za@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
> In article <1992Nov17.142856.19947@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
> >I have a potential problem with NIS in the presence of subnets. Advice would 
> >be appreciated.
> >
> >If a NIS client broadcasts to the subnet broadcast address (e.g. 130.159.248.255
> >in the case of 24 bit subnets), a router will not propogate the broadcast onto
> >other subnets on the LAN and hence the client won't be able to bind to a NIS
> >server unless a server is on the same subnet. If however the NIS client
> >broadcasts to the class B broadcast address (130.159.255.255) even when using
> >an 24 bit subnet mask, the router can be configured to forward all subnet 
> >broadcasts and there is no problem. 
> 
> The best (and recommended by Sun) solution is to have an NIS slave on every
> subnet.  It is not a good idea in general to configure your router to route
> broadcasts outside of a subnet.  (The purpose of a router is to decrease
> traffic, not increase it)


I think a better way is to use a class-D multicast address and routers
which forward multicasts.  


Vernon Schryver,  vjs@sgi.com

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 1992 20:48:02 GMT
From:      fsgreen@dredd.lerc.nasa.gov (Doug Greenwald)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY:  Need Ethernet types/IP Frame and Header Formats

I wish to thank the following people for responding to my request for
Ethernet frame headers for the small network analyzer I'm writing.

From: stewart@ra.cis.udel.edu (John Stewart)
From: Dave Curry <davy@ecn.purdue.edu>
From: Stephen C. Trier <trier@odin.INS.CWRU.Edu>
From: Amos Shapira <amoss@CS.HUJI.AC.IL>
From: Bruce Jones <bj@unislc.slc.unisys.com>
From: karwowska@dg-rtp.dg.com (Joanna Karwowska)
From: John_Burton@gec-epl.co.uk

For people that are interested in the program, it runs on the sun4c platform
under SunOS 4.1.x (Solaris 1.x).  It takes one argument (the number of
packets to grab) and generates a list of packets received (and decodes the
packets I've been able to find time and info to decode), and then generates
a packet breakdown.  It's a very simple program.  Time permitting, I will
continue to add packet decoding and some filtering ability.  

-- 
Doug Greenwald                       fsgreen@icomp01.lerc.nasa.gov
Sun System Administrator             (216) 433 5965
ICOMP, NASA Lewis Research Center

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 00:02:09 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Flow Control

In article <1992Nov14.012946.13136@advtech.uswest.com> kdlin@advtech.uswest.com (David Lin) writes:
>I understand that many end-to-end sliding window flow control schemes 
>( eq. in TCP/IP and in XTP ) use byte as the unit for calculation. For 
>example, if the window size is 6K bytes and you have transmitted 2K bytes
>without receiving ACKs from the receiver, then you are allowed to transmit
>4K more bytes.
>
>Now, if I change the unit for flow control calculation to packet ( or 
>frame ), what is the impact to the whole system? What's the implication?
> [ ... ]
>1. Are there any circumstances that this scheme ( using packet as
>   the computation unit ) is desirable?
>2. When it is NOT desirable?
>3. Do I really achieve anything by doing that?

HDLC, X25 and TP4 do flow control by counting PDUs (protocol data units)
instead of bytes. If the protocol that you are flow controlling has firm
record boundaries that must be preserved, it may be simpler to use
packet counts for flow control.

TCP on the other hand, views the data stream as an unstructured byte
stream. Data from several original PDUs may be coalesced on
retransmissions. This saves link bandwidth. Depending on the
implementation of the protocol stack, either model may more accurately
describe the loading on the buffer pools on the two end systems.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 02:41:13 GMT
From:      hcb@world.std.com (Howard C Berkowitz)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Wanted: Advice on calculating timing gaps between packets.

A few random things to consider.  You will never get the true 10 MBPS from
an IEEE 802.3/ETHERNET LAN, due to some timing requirements of the protocol
itself.  There must be a minimum 9.6 microsecond delay between packets; this
is part of the medium access control process.  There must be enough idle
time that the most distant station will hear a jam signal.

Assuming a single transmitter and a single receiver, the maximum possible
frame-level transfer rate will be based on the length (or length distribution)
of frames, plus the interframe delay.

I often find it worthwhile to write a reasonably quick-and-dirty Monte Carlo
simulation of the line protocols rather than go too far in analyzing them.  

Retransmission time will be based on the time to send the colliding frames, the
interframe delay, and the time to send the next frame.  The backoff algorithm
uses an exponentially increasing delay after each successive collision.  In a
reasonably loaded network, a frame should get through with a maximum of 3-4
collisions (this is fairly pessimistic).  

So much depends on the interarrival times of new frames, the length of frames, and
the number of stations that simulation often is easier.


Always remember that ETHERNET is a service to Arnold Schwarzenegger.  After all, it
is a cable that connects Terminator I with Terminator II. :-)


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 04:11:41 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Oditrpkt ( One last Problem! )


I am still haveing problems with oditrpkt.com.  At the moment I have almost

everything working.  My current problem is that my driver or ODI is changeing

my offset in TCP this is this field which tells where exactly the data 

starts.  For some reason every time I send a TCP packet out threw my driver and 

odi this offset is set to 5.  Unfortunitally the first packet has an options 

field giving the maximum segment size so this field should be 6.  I have been 

able to get a telnet session open too our 3Com Token-Ring Bridge's.  Also once 

by some glitch it worked ok.  I do know that this field is correct when it goes

into my driver so somehow it is getting changed.  It appears to me that this 

is being changed by the LSL or MLID but is always eaiser to place the blame 

somewhere else.  Everything else is working perfectly I even have route.com 

doing the source routing for me.  


A brief description of what I do

First I get the type field and move it to the Stack ID and also the ProtocolID

fields in the ECB then I move the dest address to the immediate address of the

ECB if its arp I change the hardware field and also reduce size.  Then I move

the pointer to where the data begins.
 
Below is a copy of the send routine sECB is a pointer to the beginning of
the Event Control Block.  I have also marked the portion which differs from 
odipkt.com which consists of code to alter the mac header.  

This code is copyrighted by Daniel D. Lanciani and the complete copyright
message is given in the odipkt.asm source file.  That message also applies
to here.  ( Just to be safe )

	;	This part is done at initialization.  
 ; 	Initialization for sECB is the same as for odipkt execpt no raw send
	mov     word ptr sECB + 10, offset transcom    ; Call Transcom 
	mov     word ptr sECB + 12, cs                 ; Also ptr to transcom
	;	mov     word ptr sECB + 14, -1                 ; stack ID
	mov     ax, board                              ; Board #
	mov     word ptr sECB + 22, ax                 ; Board # 
	mov     word ptr sECB + 44, 1                  ; Fragment0Count

send_pkt:sti
	push    ds
	mov     bx, ds
	mov     dx, cs
	mov     ds, dx
send_pkt1:
	cmp   word ptr 8 + sECB, 0        ; status clear ?
	jg      send_pkt1		  ; If not wait until it is.

	add     stab + 4, 1               ; Stistics for Pktdrvr
	adc     stab + 6, 0
	add     stab + 12, cx
	adc     stab + 14, 0		  ; End stats

	mov     word ptr sECB + 48, bx          ; Fragment0address LW
	
;*********Here is where my code and odipkt differ.*********
	; They would be the same if you took out this.

	push    cx
	mov     es, bx
	; Move type into ECB fields
	mov     cx, word ptr es:12[si]		; Get type field from packet.
	mov     word ptr sECB + 14, cx          ; StackID        
	mov     word ptr sECB + 20, cx          ; ProtocolID
	
	mov     cx, word ptr es:0[si]
	mov     word ptr sECB + 24, cx          ; Immediate address
	mov     cx, word ptr es:2[si]
	mov     word ptr sECB + 26, cx
	mov     cx, word ptr es:4[si]
	mov     word ptr sECB + 28, cx          ; *****************
	pop     cx
	cmp     word ptr es:12[si], 0608h       
	jnz     not_arp_send                    ; if not arp then jump
	mov     byte ptr es:15[si], 06h         ; is arp
	sub     cx, 18                          ; Reduce size for arp

not_arp_send:        

	add     si, 14	 	Offset stack pointer by 
				send and recieve address + AC + FC
	sub     cx, 14		Offset size by the same.

;*********From here on it is the same as odipkt.********

send_pkt4:
	mov     word ptr sECB + 42, cx           ; Data Length
	mov     word ptr sECB + 46, si           ; Fragment0Address
	mov     word ptr sECB + 50, cx           ; Fragment0Legnth
	mov     si, offset sECB
	mov     es, dx
	mov     bx, 12                           ; Send Packet
	call    psup
	sti

send_pkt2:
	cmp   word ptr 8 + sECB, 0              ; Status 
	jg      send_pkt2			; loop until clear or fail
	jnz     send_pkt3
	pop     ds
	jmp     good

send_pkt3:
	add   stab + 20, 1                     ; Stats
	adc     stab + 22, 0
	pop     ds
	mov     dh, 12
	jmp     bad


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 05:41:15 GMT
From:      peter@palin.cc.monash.edu.au (Peter Hawkins)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   REQ: MSDOS TCP/IP stack in ASM or Pascal

I need to interface a turbo pascal (V6) application to TCP/IP. The
application is heavily OOP & TVision etc so I pretty well am forced
to use turbo pascal. It's huge & re-writing in C is not practical.
I could use novell IPX & Banyan Vines, but I want it to be more
general if I can.

I got a copy of wattcp - a mixture of asm & C, and compiled it with
BCC, but unfortunately I couldn't link the C & pascal object files
without leaving unresolved externals - Borland's advice was that
interfacing C to Pascal will not work with any C code which is either
not-straightforward (in calling) or which utilises intrinsic libraries.
(They advised against my attempting it - and suggested I re-write the
TCP/IP stack in pascal!)

Before embarking on a major project such as re-writing the stack, or
giving up and using IPX and Vines, I thought I'd try and see if anyone
knew:

1)  What public domain / commercial TCP/IP stacks are there which might
    be callable from turbo C?

2)  Are there any stacks around written entirely in assembly or (joy of
    joys!) pascal?

Thanks in advance,

Peter
-- 
Peter Hawkins,
Assistant Lecturer, Computer Centre
Monash University, Australia
peter@palin.cc.monash.edu.au

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 08:25:52 GMT
From:      benolie@tid.es (Luis Benoliel)
To:        comp.protocols.tcp-ip
Subject:   FAQ AVAILABLE FOR THIS NEWSGROUP ?



Is the faq for this newsgroup available? If so, where ?


-- 
 ////////  ///////  /////       Luis Benoliel
   //        //    //   //        	     email: benolie@tid.es
  //        //    //    //                   tel  : +34 1 337 41 85
 //        //    //    //                    fax  : +34 1 337 42 02

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 11:57:15 GMT
From:      mrc@Ikkoku-Kan (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   WARNING on NetInfo

This warning is posted to anyone as an advisory to anyone else who may
be so foolish as to try to run a bootp daemon on the NeXT and think he
can install it by something as simple and straightforward as
	niload bootptab . < bootptab

Beware!!  NetInfo does not maintain the information from /etc/bootptab
separately.  Instead, it and the information from /etc/hosts are both
co-located in the `machines' NetInfo directory.

So you do the niload and you discover that the information isn't
right.  In fact, what appears as the bootp IP address is another IP
address for that machine; that client uses both SLIP and Ethernet and
so it's dual-homed.  Wierd, you think.  After all, you put the correct
IP address in bootptab.  Oh well.  No problem, you think, just do
	niload -d bootptab . < bootptab

Yup, that fixed the problem all right.  Now you got a worse problem.
As you discover after a lot of pulling of hair trying to figure out
why everything is falling down in flames, you just hosed the entire
hosts database including the definition of localhost.

I learned this the hard way.  I was not pleased.

This is a warning too, to you folks with SUNs and other non-NeXT
platforms who may be receiving advertising from NeXT about NetInfo for
your machine.  DON'T BUY IT.  NetInfo is the single worst piece of
system administration software, bar none, that I have ever had the
misfortune of dealing with.  If you thought Yellow Pages was a can of
worms, you haven't begun to imagine the myriad ways in which NetInfo
can screw you.

For those of you who haven't figured out what NetInfo is, it is a
distributed system configuration database that pretty much turns off
ALL of the standard Unix configuration files: aliases, bootptab,
bootparams, exports, fstab, group, hosts, networks, passwd, printcap,
protocols, rpc, services.  Among its many faults, it stores the data
in binary, since you are expected to use the NetInfoManager tool
(which has a user interface designed by the Marquis de Sade) to edit
it.  To some degree, you can edit the Unix configuration file and
`niload' it into NetInfo, but there are all sorts of ways it can screw
up and I just discovered a new one.

What's worse, you can't turn it off on a NeXT.  I can't imagine anyone
wanting to run it on a machine which doesn't force you into it the way
a NeXT does.

Verbum sat sapenti.

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 1992 22:55:35 -0600
From:      usbill@ustores.missouri.edu (Bill Canning)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Recommended Terminal Server

I'm looking for a fairly basic terminal server that won't cost a fortune.  I
need to get between 24 and 32 ports, although this could be with more than one
unit.  We will only be running 9.6K terminals on it, and we will be using it to
attach to a Unix host via Telnet on an ethernet LAN.  Does anyone have any
recommendations?

Thanks in advance for your help,
Bill
-- 
Bill Canning                             usbill@ustores.missouri.edu (Internet)
(314) 882-2131                           usbill@muccmail.missouri.edu (cc:Mail)
[314] 882=4699 (Fax)                     CSPECWC@MIZZOU1 (BITNET)

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 14:23:27 GMT
From:      stodola@orion.fccc.edu (Robert K. Stodola)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Balkanization of the InterNet inevitable?

In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes:
> 
>   Are network security firewalls between organizations and the InterNet
> going to be the norm in the future?

I think you'll see a lot more of them (certainly, at least one!-).

>   If the Balkanization of the InterNet is inevitable, I feel it will be a
> great loss.  It will be an acknowledgement that irresponsible criminal
> hackers have won from us our freedom of open inter-operation.  What a
> sad thought.  Are there no other realistic options for providing security?

This need not be true.  Many firewalls allow limited access (ie. particular
systems or ports accessible), and it is always possible to keep machines
designed for public access on the other side of your firewall.  It just means
you have to think about what belongs in the public arena and what doesn't.

But you should be doing that anyway.

Suggest you redirect followups to the firewalls (or other) mailing list:

  Send the following command in email to "Majordomo@GreatCircle.COM":

    subscribe firewalls <your-email-address>
-- 

stodola@fccc.edu -- Robert K. Stodola (occasionally) speaks for himself.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 15:24:33 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over Token-Ring

I am also interested in this topic.  Please include me in any non
posted milings on the subject as my next assignment is TCP/IP
over 802.5 (token ring).  Thanks.

-- 
Mark

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

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 15:28:52 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Multicast Routers (was Re: NIS broadcasts over IP subnets)

In article <sg3chj4@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>   I think a better way is to use a class-D multicast address and routers
>   which forward multicasts.  

I agree, but which routers support Network groups? 

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 16:57:07 GMT
From:      stewart@daffy.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP simul- & broadcast

In article <id.XP1V.B11@ferranti.com> ihsan@ferranti.com (jaleel ihsan) writes:
>At one time class D IP address (224.0.0.0 thru 255.255.255.254) were
>reserved for simul-cast and of course 255.255.255.255 for broadcast.
>
>I have a few questions reguarding TCP simul- and broadcasts, if
>someone could please enlighten us:
>
>1. What do the latest standards demand from an implementor in this
>   regard.
>
>2. What happens to TCP's reliable delivery feature, specially 
>   in case of broadcast ?  Does it drop down to the level of UDP ?
>
>3. What are the vendors providing  and supporting in the market place.
>
>I think I saw an article saying that some one has used TCP simulcast
>for video teleconferencing (over ISDN perhaps) but I am not sure.

At this point, multicast has been done at the IP-layer, rather
than the TCP (or UDP) layer.  For example, the Internet
Engineering Task Force meeting, which is going on right now in
Washington, D.C., is having some of its meetings video and
audio mutli-cast over the Internet; applications with such huge
bandwidth demands have, to date, all been based on UDP.  To do
this, a logical multi-cast network has been created within the
Internet; this has been called MBONE (multi-cast backbone).
Internet-attached customers interested in becoming part of
MBONE should contact their regional provider.

For more information of a technical nature, I direct you to the
Association for Computing Machinery's Special Interest Group on
Communication's (ACM SIGCOMM's) Computer Communication Review
(CCR) from this fall (I don't have the publication with me, so
I can't give you an exact date -- sorry).  There is an article
there by Steve Casner et. al. describing how MBONE is achieved.

/jws

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 17:06:22 GMT
From:      ajudge@maths.tcd.ie (Alan Judge)
To:        comp.dcom.servers,comp.dcom.lans,comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.sys.mips
Subject:   Routing using a dual-homed machine vs a router

Does anybody have any comments on the performance of a Unix machine
as a router vs that of a dedicated router, such as a Cisco?
How much delay is imposed by each solution?

Are there any other issues here that I am missing?  (I realise that
a Unix box is likely to be down more than a dedicated router.)

Given the simple nature of our setup (no fancy leased lines, only
one ethernet at present), what models of router should I be
considering if I go for a router?  What do these models cost?
[I am asked the net, as I need the answer in a hurry.]

Background:
	We are connected to the campus fibre-optic backbone using a bridge at
	present.  There is a possibility that we will switch to using
	subnetting and routing instead.  If that happens, we will either
	purchase a router or install a second ethernet into one of our
	machines.

	There is little bulk traffic between the department and the rest of
	College, mainly NNTP, SMTP, NTP, telnet, rlogin.  No NFS or other
	file sharing.

	The machine in question is likely to be an R4000 based MIPS server
	(a Millenium 4000 SC-50).  We would probably run gated.


Please reply by email and I will summarise.
-- 
Alan Judge   ajudge@maths.tcd.ie  a.k.a. amjudge@dsg.cs.tcd.ie +353-1-7021782

A year spent in Artificial Intelligence is enough to make one believe in God.
						-- Alan Perlis

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 17:09:22 GMT
From:      mazzucch@ghost.dsi.unimi.it (massimo mazzucchi)
To:        comp.protocols.tcp-ip
Subject:   SLIP info


Hi

I am Max from Milan Italy

I use to communication UNIXtoDOS SLIP

FTP Software PC/TCP version 1.16pl4

i will know:

- exist a new version and it is a commercila program or public domain?

- for example if i have connect my pc with a serial port of 

 a modem in which way i can use command ftp correctly?( there

 are 2 file *.sys that i have place in Config.sys)

 - there 2 file IPCONFIG and IFCONFIG 
   
    in which way i must use them?


    Thanks for your help

    Bye
--------------------------------------------------------------------------------
!  Massimo Mazzucchi                         address    e-mail                !
!  University of State                       mazzucch@ghost.dsi.unimi.it      !
!  Departement of Computer Science            149.132.2.1                     ! 
!  Via Comelico, 41 -  20133 MILAN ITALY                                      !
 -------------------------------------------------------------------------------

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 17:29:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

In article <BARNETT.92Nov18102852@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
> In article <sg3chj4@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >   I think a better way is to use a class-D multicast address and routers
> >   which forward multicasts.  
> 
> I agree, but which routers support Network groups? 


Well, most routers in the world do.  That is because cause nearly all
routers in the world are UNIX workstations and PC's, instead of
Official Real Routers (tm) and since mrouted & friends work in common
workstations.  Someone once observed that Sun all by itself has
probably shipped more "IP routers" than all of the "router vendors"
combined.

It is often enough to just get mrouted running on the workstations you
are using as routers.

You'll notice that an official class-D address has been registered for
the portmapper, 224.0.2.2.


In the sense you probably meant the question, I don't know.  For years
I hounded router vendors at Interop, and was always told "wait for
OSPF."  Then they started saying "wait until the replacement for the
distance-vector-multicast-routing-protocol."  This year I didn't
bother.

The IETF Entertainment Network should finally give the router vendors
enough reason to finish the work.


Vernon Schryver,  vjs@sgi.com

P.S. I hope no one finds it necessary to point out all of the reasons
    to use an Official Real Router (tm) instead of a workstation, or the
    other way around.  I trust anyone who cares is already quite familiar
    with all sides of that old argument.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 18:11:15 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip
Subject:   Tricky subnet question for gurus

Hi,

can someone tell me if the following is cool.

I have a bunch of units with hard coded ip addresses ( yuck ).
I have four networks these must go on.
I have workstations on these networks which need to talk to the units.
The units must be interchangable.


I want to be able to connect to the workstations from any net.  I only need
to talk to the units via the local workstations.

The units and workstations must be able to interact wothout anything 
routing betweeen them.  I'll have a router connecting to each net to
allow access to the workstations.

Is the following valid.


net 1 x.x.4.0	mask 255.255.248.0
net 2 x.x.5.0	mask 255.255.240.0
net 3 x.x.6.0	mask 255.255.248.0
net 4 x.x.7.0	mask 255.255.248.0

units x.x.1.0	mask 255.255.248.0


last three bits of octet 8 are zero.

Using the subnet system, each net can talk to their local units.  Each net
thinks it can talk to each other ( will never happen ).  Each net will think
it can talk to units on other nets ( never happen )

If I put routers on each net with subnet masks of 255.255.255.0, each router
will advertise a router to each net, and only that net.

Is it ok to have different subnet masks on the one net ?

I'd appreciate any reply's by EMail,

Thanks,



john



-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 92 22:18:47 GMT
From:      sullivan@samsung.com (Chris Sullivan)
To:        comp.protocols.tcp-ip
Subject:   CSLIP for Karn's TCP...


Im looking for a CSLIP implementation that I can use
with Phil Karn's TCP/IP.

Possibly Karn himself has done it????

Any ideas would be greatly appreciated.


-- chris

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris Sullivan                                  sullivan@samsung.com
Samsung Software America                        ...uunet!samsung!sullivan
One Corporate Drive                             Voice: (508) 685-7200  x132
Andover MA 01810                                Fax: (508) 685-4940


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 1992 23:48:18 GMT
From:      peter@palin.cc.monash.edu.au (Peter Hawkins)
To:        comp.protocols.tcp-ip
Subject:   REQ: MSDOS TCP/IP stack in ASM or Pascal

I need to interface a turbo pascal (V6) application to TCP/IP. The
application is heavily OOP & TVision etc so I pretty well am forced
to use turbo pascal. It's huge & re-writing in C is not practical.
I could use novell IPX & Banyan Vines, but I want it to be more
general if I can.

I got a copy of wattcp - a mixture of asm & C, and compiled it with
BCC, but unfortunately I couldn't link the C & pascal object files
without leaving unresolved externals - Borland's advice was that
interfacing C to Pascal will not work with any C code which is either
not-straightforward (in calling) or which utilises intrinsic libraries.
(They advised against my attempting it - and suggested I re-write the
TCP/IP stack in pascal!)

Before embarking on a major project such as re-writing the stack, or
giving up and using IPX and Vines, I thought I'd try and see if anyone
knew:

1)  What public domain / commercial TCP/IP stacks are there which might
    be callable from turbo C?

2)  Are there any stacks around written entirely in assembly or (joy of
    joys!) pascal?

Thanks in advance,

Peter

-- 
Peter Hawkins,
Assistant Lecturer, Computer Centre
Monash University, Australia
peter@palin.cc.monash.edu.au

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 1992 00:56:01 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   Re: REQ: MSDOS TCP/IP stack in ASM or Pascal

In article <peter.722065275@palin.cc.monash.edu.au>, peter@palin.cc.monash.edu.au (Peter Hawkins) writes:
> I need to interface a turbo pascal (V6) application to TCP/IP. The
> application is heavily OOP & TVision etc so I pretty well am forced
> to use turbo pascal.
 [...]
> (They advised against my attempting it - and suggested I re-write the
> TCP/IP stack in pascal!)
> 
> Before embarking on a major project such as re-writing the stack, or
> giving up and using IPX and Vines, I thought I'd try and see if anyone
> knew:
> 
> 1)  What public domain / commercial TCP/IP stacks are there which might
>     be callable from turbo C?
 
> peter@palin.cc.monash.edu.au

Peter, a better idea is to buy a commercial stack, which usually loads a
as a TSR. They usually have a documented API, or even a development kit
with the relevent routines to interface to it. That way you can write
your own pascal code or assembler to stuff registers and do an interrupt
(or whatever mechanism they use to interface to the TSR), which is FAR
easier than re-writing a TCP stack inside your application. All of the
common commercial stacks have documented APIs...
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1992 06:30:57 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Recommended Terminal Server

Bill Canning (usbill@ustores.missouri.edu) wrote:
: I'm looking for a fairly basic terminal server that won't cost a fortune.  I
: need to get between 24 and 32 ports, although this could be with more than one
: unit.  We will only be running 9.6K terminals on it, and we will be using it to
: attach to a Unix host via Telnet on an ethernet LAN.  Does anyone have any
: recommendations?

We have had good luck with a Livingston Portmaster unit.  They make
a 30 port box which plugs into the ethernet; it can be configured either
to tie ports back to a specific box (via telnet, rlogin, or their
portmaster-special daemon), or you can make it a little more general
and let people pick their host or even use SLIP or PPP to get out.

It sounds like the feature list is a little bit longer than you really
require, and that there might be a previous-generation stone dumb
terminal server that would do the job.  

Here's the mailing list announcement I sent out...

To: tcp-ip@nic.ddn.mil
Cc: ppp-users@MorningStar.Com
Subject: new mailing list for Livingston Portmaster terminal servers
Date: Wed, 09 Sep 92 15:54:49 EDT
From: Edward Vielmetti <emv@msen.com>

I've set up a new mailing list for users of the Livingston Portmaster
line of terminal servers and routers.  These boxes are in use by
several network service providers (including ourselves) to support
dialup SLIP and PPP access.  Given that the demands of public
access dialup are somewhat more stressful than ordinary async service,
I thought it would be a good idea to get people working with the
equipment off on their own list to exchange working ideas and to
coordinate development requests.

The Portmaster series includes a 4-port 56K router (the IR-4) and a 10
port async terminal server (the PM-11) that supports SLIP and PPP. 

To join the list send mail to
	portmaster-users-request@msen.com
To submit messages to the list send to
	portmaster-users@msen.com

Disclaimer: though we at Msen have some investment in the actual
equipment we have no financial stake in Livingston, and I see this as
a user self-support forum as much as it is a way to get information
from the equipment makers.  Caveat vendor.

---
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562
 A distributed system is one in which the failure of a computer you didn't
 even know existed can render your own computer unusable. (Leslie Lamport)




------- End of Forwarded Message

 

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 10:41:16 GMT
From:      possoz@sic.epfl.ch (Anne Possoz EPFL-SIC/SL)
To:        comp.protocols.tcp-ip
Subject:   RPC vs sockets performance and network influence

Working a lot on transfer of huge arrays across different computers,
I reached the following conclusions.

1) using Sun RPC (with underlying XDR), I can handle .2 to .6 Mbytes/sec
   depending on the platform on which I am working (here the CPU time
   is converted in Mbytes/sec); this has to be compared to the network
   which can handle around 1. Mbytes/sec for ethernet.
   So the CPU is slower than the network. The reason for this is that
   the XDR package is not at all optimized for this kind of problems.

2) using sockets, I can handle 3. to 10. Mbytes/sec instead. So now the
   network is my limitation. Moreover, I noticed that if data are going
   from FFDI network to ethernet network, I reach that performance only
   if I decrease the SO_RCVBUF size to 8 kbytes (the gain is a factor of 3
   to 4 if SO_RCVBUF is set to 8 kbytes compared to 32 kbytes).
   Note that by default, SO_RCVBUF is 4K on SUN, 8K on HP, 32K on crays and
   61K on SG. There is also some interest to increase the SO_SNDBUF to a value
   of 32K.

Thus I have some questions to who migth help :

 - where can I find any information on performances?

 - does this means that any application using RPC are not suitable for large
   transfer of data? And, as far as I can read, NFS is based on RPC; does that
   mean that NFS is not optimized?

 - do you know of any other newsgroup where I could read on that subject?

						Anne
-- 

Anne Possoz
possoz@sic.epfl.ch

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 1992 11:17:05 GMT
From:      viau@wm.estec.esa.nl (Pierre "play-soccer-not-football" Viau)
To:        comp.protocols.tcp-ip
Subject:   Class D addresses and Multicast routers

Is there a FAQ about Class D addressing and Multicasting ?

If yes, could someone post it please ?
If no, could somebody say what the status of this thing is today ? 

Thanks in advance.

---


Pierre Viau

ESTEC - WMS
European Space Agency
Keplerlaan, 1
2200 AG Noordwijk
The Netherlands

Fax:	(31) [0]1719-85420
                     17400
Phone:	(31) [0]1719-84357
		     83816

Preferred Email:	viau@wm.estec.esa.nl

Desperate Email:	pviau@estec.bitnet
			pviau@estec.esa.nl



-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 12:58:34 GMT
From:      G.Knight@cs.ucl.ac.uk (Graham Knight)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and ISDN / experiences with ISDN

Markus,

	We do this here with our own primary rate kit - basically we
just put IP datagrams between HDLC flags on ISDN B-Channels which are
set up on demand.

	I think lots of other people to this too. Try the list
isdn@teknology.agderforskning.no for more information. Since you are
in Germany you could talk to Clemens Schrimpe (csch@com.netcs) also.

						Graham

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 1992 15:13:55 GMT
From:      tbooth@netcom.com (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

>...
>In the sense you probably meant the question, I don't know.  For years
>I hounded router vendors at Interop, and was always told "wait for
>OSPF."  

Why have you been waiting?

OSPF is a draft internet standard and has been available for over
a year and a half from Wellfleet Communicaitons (and other vendors).
Cisco has been shipping OSPF since April?

--todd 

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 16:16:08 GMT
From:      scoggin@opus.ee.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

In article <1992Nov19.151355.20000@netcom.com> tbooth@netcom.com (Todd Booth) writes:
>>...
>>In the sense you probably meant the question, I don't know.  For years
>>I hounded router vendors at Interop, and was always told "wait for
>>OSPF."  
>
>Why have you been waiting?
>
>OSPF is a draft internet standard and has been available for over
>a year and a half from Wellfleet Communicaitons (and other vendors).
>Cisco has been shipping OSPF since April?
>
>--todd 

Because having OSPF is one thing, and having OSPF MULTI-CAST is quite another
issue.  Last I remember, OSPF Multicast is still in Draft state, as is the
MIB.  BTW, on the subject of Wellfleet - implementation of OSPF MIB has lagged
FAR behind that of OSPF itself.  Then the issue becomes - you can pass 
packets OK, but you want to MANAGE it too?? :-)

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 1992 17:14:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

In article <1992Nov19.151355.20000@netcom.com>, tbooth@netcom.com (Todd Booth) writes:
> >...
> >In the sense you probably meant the question, I don't know.  For years
> >I hounded router vendors at Interop, and was always told "wait for
> >OSPF."  
> 
> Why have you been waiting?
> 
> OSPF is a draft internet standard and has been available for over
> a year and a half from Wellfleet Communicaitons (and other vendors).
> Cisco has been shipping OSPF since April?


I know OSPF has been a draft standard for ages.  I was only repeating
what the router vendors told me at Interop90 and before.

In the rest of my text, I wrote that at Interop 91 I was told by Cisco
and others "forget DVMRP, and wait for the new link state multicast
protocol that even Steve Deering supports."  (Well, I didn't explicitly
write "Interop 91".)

Why is the IETF multicasting this week being done with tunnels?
Is that only because of the backbone?

Do Wellfleet, Cisco, or others now do the right things when they see a
class D address?  Do they forward such IP packets?

As far as I can tell, the router vendors have been dragging their feet
vigorously on any kind of multicast routing for at least 4 years.  The
router vendors have shown more enthusiasm for PPP, despite the danger
PPP represents to their locked-in customer bases.


vjs

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 17:25:42 GMT
From:      ric@updike.sri.com (Richard Steinberger)
To:        comp.protocols.tcp-ip
Subject:   tcp vs. udp transfer rates in a LAN


	I have two Suns separated by two repeaters (but no bridges or routers).
When I do an FTP transfer I get xfer rates of 90 - 170 Kbs with an average
of about 120 Kbs.  When I do rcp I get rates closer to 1/10 of that:
14 - 21 Kbs (with one unusual xfer at 127 Kbs).  nfs transfer rates
(to/from disk from/to imported disk) are similar to rcp rates.

	When I do similar transfers between 2 SUNs on the same section
of ethernet (no repeaters between them), I get ftp rates of 330 Kbs - 830 Kbs.
rcp rates are 170 Kbs - 360 Kbs.  

	I have been told that the repeaters can occassionally go into
something called "partition" mode, where, if they see "too many"
collisions, the temporarily stop repeating.  I don't know if this is
actually happening.

	Can anyone help with this?  What should we look at next?  [We have
LAN analyzers and SW tools like tcpdump].  Is there any way to "tune" UDP
tranfers?  Is it likely that one or both repeaters can't handle the udp
traffic, but is better able to handle tcp traffic?

	Thanks in advance for any replies/suggestions.

ric steinberger
ric@updike.sri.com


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 19:15:00 GMT
From:      fredrik@ludd.luth.se (Fredrik Markstrom)
To:        comp.protocols.tcp-ip
Subject:   Tokenring Without mau ???

I realy don't know is this is the right place to ask ???
But If I'm wrong please correct me  !!!

I've seen that a Token Ring MAU hasn't got any power-connection, and
thereby I assume that it can't contain any active electronics, maybe 
some filters and relays (I've heard it clicking !!!).
To the question : Is it possible to connect my to PC:s running TCP/IP 
on token ring, without a mau ???

Please answere by mail....

Pretnx...

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 20:25:43 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   Difference between 32/16 bit ethernet boards?


Can anyone tell me what the performance differences are 
between a 32 bit and 16 bit ethernet card?

(We will be going from a 386 PC to a Sun sparc if 
that is any help)


--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 1992 20:36:21 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   select()/ Bad File Number

I have got a puzzler???????

I have a situation where a socket gets closed and instead of select() 
returning informing me that the socket is ready for reading, I get -1 and errno
"Bad File Number".  Of course I have no clue as to which fid is bad. I really
don't want to have to do a sequential search through my FD_SETs checking
status on every fid.  Is there any easier way?????

Any help/info/clues would be greatly appreciated!!!!!

Ron 



-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 92 21:45:55 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   Wanted ftp sites for wattcp and cutcp

Can someone please tell me where to get the above?

If it's on wuarchive.wustl.edu I have not
been able to log on for weeks. Maybe I'll have 
to get autoftp working again. :(



--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 05:36:47 GMT
From:      logier@cheops.qld.tne.oz.au (Rob Logie)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: SNA <-> IP Encapsulation

mndot@msus1.msus.edu writes:


>I am new to this particular news feed so this may have been asked in the past.
>I am not very familiar with IBM host equipment either.
 
>I am trying to provide mainframe connectivity to a number of remote sites. 
>Most of the sites have IBM 3174 (or compatible) remote controllers for SNA
>communications.  This comm. takes place over multidrop 9600 bps lines.  We are
>in the process of installing T1 circuits to all of those same locations.  The
>T1's are primarily IP.  Does software exist for the 3174 to allow SNA
>encapsulation in IP packets?  I have seen hints of this scenario on some of the
>news feeds but I am not sure which ones.  Any help with this would be greatly
>appreciated.
 
> -- Al


I have done it using perment virtual circuits between terminal servers using
a terminal server at each end (3COM CS200's).  Been working for a few years
without trouble.


-- 
Rob Logie                         | The opions expressed are mine alone and in
Telecom Australia ACN 051 775 556 | no-way reflect the views or policies of the
TNE Computer Support Services     | Australian and Overseas Telecommunications
EMAIL: logier@cheops.qld.tne.oz.au| Corporation. "These are my opinions alone"

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 06:10:08 GMT
From:      sss@scammell.ecos.tne.oz.au (Steve Silver)
To:        comp.protocols.tcp-ip
Subject:   Details of Service Name to Socket Type

To all TCP/IP gurus.

I am trying to locate the RFC or documention describing all known
Service Name types to Socket types (eg. telnet = 23/tcp, ftp = 21/tcp).

Could you please send the info to my E-mail address and/or this Bulletin
Board.

Thank you for your anticipated help.
-- 
Steve Silver         sss@scammell.ecos.tne.oz.au

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 06:22:32 GMT
From:      tbooth@netcom.com (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

>>OSPF is a draft internet standard and has been available for over
>>a year and a half from Wellfleet Communicaitons (and other vendors).
>>Cisco has been shipping OSPF since April?
 
> ...BTW, on the subject of Wellfleet - implementation of OSPF MIB has lagged
>FAR behind that of OSPF itself...

Are there *any* leading router vendors that support the OSPF MIB?
I don't think Cisco has as of 9.1B.

There are at least a few sites out there that *think* they can MANAGE
their nets without the OSPF MIB  :-)  .

--todd

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 06:57:33 GMT
From:      tbooth@netcom.com (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>...
>As far as I can tell, the router vendors have been dragging their feet
>vigorously on any kind of multicast routing for at least 4 years.  The
>router vendors have shown more enthusiasm for PPP, despite the danger
>PPP represents to their locked-in customer bases.

I can't speak for others, but I get requests for multi-vendor
interoperability over leased lines over 50 times as often as
for multicast routing.  Are there a lot of people out there
with requirements for multicast routing?  Could anyone quantify
how many routers would be used for multicast routing?  Maybe
1 out of 10, 1 out of 1000...?

Assuming it is closer to 1 out of 1000, why not use a high end
router for the non-multicast and a Sun or whatever for the 
multicast?

PPP allows our customers to use less expensive IPX or IP routers,
from other vendors, and interoperate with Wellfleet equipment at
the central site.

I think this newsgroup would tear to shreads any router vendors
that did not support PPP (at least IP over PPP with static support).

--todd

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 10:00:42
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Wanted: Advice on calculating timing gaps between packets.

hcb@world.std.com (Howard C Berkowitz) writes:
>A few random things to consider.  You will never get the true 10 MBPS from
>an IEEE 802.3/ETHERNET LAN, due to some timing requirements of the protocol
>itself.  There must be a minimum 9.6 microsecond delay between packets; this
>is part of the medium access control process.  There must be enough idle
>time that the most distant station will hear a jam signal.
>
>Assuming a single transmitter and a single receiver, the maximum possible
>frame-level transfer rate will be based on the length (or length distribution)
>of frames, plus the interframe delay.

You may not get 100%, no. But modern workstations can get very close (say
better than 95%).

>I often find it worthwhile to write a reasonably quick-and-dirty Monte Carlo
>simulation of the line protocols rather than go too far in analyzing them.  

How about actually *measuring* instead? With tools like ttcp and a quiet
(two station) Ethernet, I can get better than 1 MByte/s (yes, 1048576 B/s)
between two Sparc IPCs. And you certainly can't claim they are top of the
line these days...

People seem fond of propagating the idea that you will never be able to fully
load an Ethernet. Well, you can! And despite theoretical predictions to the
contrary, Ethernet handles a high load very well, degrades gracefully and is
in general extremely reliable.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 09:00:57 GMT
From:      cproto@cs.curtin.edu.au (Computer Protocol)
To:        comp.protocols.tcp-ip
Subject:   RIP and OSPF implementations

I am looking for public or commercial implementations of the following
IP routing protocols: OSPF and RIP. 
Any contacts which you can suggest (either via news or mail
to me direct) would be appreciated.

Heather Payne
Datacraft Technologies
11 Brodie Hall Drive
BENTLEY WA 6102
AUSTRALIA

EMAIL: cproto@cs.curtin.edu.au
PHONE: + 61 9 470 2333
FAX:   + 61 9 362 2430


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 09:40:14 GMT
From:      jim@grimaldi.rutgers.edu (Jim Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted ftp sites for wattcp and cutcp

lvandyke@balboa.eng.uci.edu (Lee Van Dyke) writes:
>Can someone please tell me where to get the above?

	Both packages are available on dorm.rutgers.edu (128.6.18.15).
Dorm mirrors both wattcp and cutcp, as well as a number of other PC
(and Mac) network packages on a nightly basis.
							Jim

-- 
	Jim Martin			Internet: jim@dorm.rutgers.edu
	Network Services		UUCP: {backbone}!rutgers!jim
	Rutgers University		Phone: (908) 932-3719

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 10:26:16 GMT
From:      cgra@btma74.nohost.nodomain
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: NFS


In article <1992Nov13.172400.5004@gumby.dsd.trw.com>, modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona) writes:
|>Path: se.alcbel!alcbel!ub4b!mcsun!Germany.EU.net!rrz.uni-koeln.de!unidui!math.fu-berlin.de!news.belwue.de!ira.uka.de!ira.uka.de!sol.ctr.columbia.edu!usc!venice!gumby.dsd.trw.com!modic
|>From: modic@gumby.dsd.trw.com (Jeanine A. Modic-Carmona)
|>Newsgroups: comp.protocols.ibm,comp.protocols.tcp-ip
|>Subject: NFS
|>Message-ID: <1992Nov13.172400.5004@gumby.dsd.trw.com>
|>Date: 13 Nov 92 17:24:00 GMT
|>Organization: TRW Space & Defense, Redondo Beach, CA
|>Lines: 122
|>Xref: se.alcbel comp.protocols.ibm:286 comp.protocols.tcp-ip:5086
|>
|>
|>Hi! I was wondering if anyone has tried to backup a PC or Mac to an IBM 
|>mainframe via TCP/IP? If so, how?
|>
[ text deleted...]

[repetitions deleted...]

Tried using echo suppression?:-))

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 10:52:33 GMT
From:      gdox@informatik.tu-chemnitz.de (Guntram Dox)
To:        comp.protocols.tcp-ip
Subject:   What is  "RMON" ? Please explain .


Hi,

I read the term "RMON" in a marketing paper from cabletron. 

Somebody told me, it should be something new on top of SNMP .  Programming
interface , or so.

Could somebody explain it in more detail ?
Please, email to me, too. My access to this news group will be a little bit
difficult in the next weeks.
Or any pointers to other information would be great.

Ta,
Guntram

University of Humberside, UK

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 16:11:42 EST
From:      jehresman@eagle.wesleyan.edu
To:        comp.protocols.tcp-ip
Subject:   SUN RPC in sys V r 3 w/ WIN/TCP?

Has anyone successfully compiled the sunrpc-4.0 package to a sys V r 3 machine
using WIN/TCP?  Would it be better to rewrite the functions in the BSD
libraries ourselves or to find source for a general purpose BSD library?  Our
intention is to try to get a PD version of NFS working on top of this, so I
also want info / comments on the PD versions of nfs.

Thanks in advance,

John Ehresman

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 13:27:32 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Details of Service Name to Socket Type

In article <1992Nov20.061008.6630@scammell.ecos.tne.oz.au> sss@scammell.ecos.tne.oz.au (Steve Silver) writes:
>To all TCP/IP gurus.
>
>I am trying to locate the RFC or documention describing all known
>Service Name types to Socket types (eg. telnet = 23/tcp, ftp = 21/tcp).
>
The current Assigned Numbers document is RFC 1340.

-Bill


-- 
Bill Warner						(317)494-1787
General Consulting					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 14:57:12 GMT
From:      bj@unislc.uucp (Bruce Jones)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Wanted: Advice on calculating timing gaps between packets.

In article <STEINAR.HAUG.92Nov20100042@delab.sintef.no> Steinar.Haug@delab.sintef.no (Steinar Haug) writes:

>How about actually *measuring* instead? With tools like ttcp and a quiet
 			^^^^^^^^
>(two station) Ethernet, I can get better than 1 MByte/s (yes, 1048576 B/s)
>between two Sparc IPCs. And you certainly can't claim they are top of the
>line these days...
>
>Steinar Haug, system/networks administrator
>SINTEF DELAB, University of Trondheim, NORWAY
>Email: Steinar.Haug@delab.sintef.no, 
>	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

Is this program freely available (ttcp)?   I am looking for some kind of
performance measurement tool.

Thanks,
Bruce Jones
-- 
Unisys				bj@unislc.slc.unisys.com
Salt Lake City, Utah		{sun, uunet}!unislc!bj
(801)-594-7046

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 18:08:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Wanted: Advice on calculating timing gaps between packets.

In article <1992Nov20.145712.5931@unislc.uucp>, bj@unislc.uucp (Bruce Jones) writes:
> ...
> Is this program freely available (ttcp)?   I am looking for some kind of
> performance measurement tool.


The original is somewhere on brl.mil.

You can also ftp the original and a spiffed up version of the source on
sgi.com.


Vernon Schryver,  vjs@sgi.com

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 19:40:54 GMT
From:      ramon@helix.nih.gov (Ramon J. Hontanon)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.wintcp
Subject:   WIN-TCP/DECwindows device conflict. Whats's up with that?????

In upgrading our trusty VAXstationII GPX from VMS 5.0 to VMS 5.4 we
found out that our version of The Wollongong Groups's TCP/IP allocates
three devices (GAA0: GAA1: GAA2:) that will need to be used by
DECwindows.
The result: DECwindows refuses to install. The DEC people found this
out, and it seems true, 'cause DECwindows starts fine if I don't run
WIN/TCP. I guess my question is:

What version of WIN/TCP do I need to go to in order to fix this bug?

Will we be required to buy the product again, or do we just simply
upgrade? 

The e-mail address of The Wollongong Group would also be appreciated.

Thanks in advance

ramon@helix.nih.gov



-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 20:09:10 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Wanted: Advice on calculating timing gaps between packets.

Measured Capacity of an Ethernet: Myths and Reality
Boggs, Mogul, and Kent
Digital Western Research Laboratory

Mail server is

WRL-techreports@decwrl.dec.com

Send a message w/subject: help to get info.
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 20:29:06 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   ARP & Duplicate IP addresses

Hello Net

I would value opinions, advice and information on the topic of handling 
duplicate IP addresses with ARP.

Specifically
- Is it a good idea to ARP your own IP address on startup? A returning
  ARP would tell you that the address was a duplicate.
  - if so is it a good idea to automatically shut your interface down 
    if a duplicate IP address is detected on startup? Are there any
    situations where false returns might be reported? 
 -  What about detecting one after startup? Should you advise the user
    and gently start terminating connections? Could be real annoying.

- If you receive an incoming ARP request and the sender IP address matches
  yours should you reply to it? Doing so would advice the other node that
  a duplicate exists (assuming it checks) but also could hopelessly confuse
  a host that doesn't.  All of the implementations that I have tested do not
  reply - but I have not tried all that many.

- What are the consequenses of staying up with a duplicate IP address?

I would value some insight into this topic. Thank You

						- Dale Edgar
						  Cybernetic Control Inc.
						  DEDGAR@MTA.CA



   

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 20:36:57 GMT
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.protocols.tcp-ip
Subject:   Recommendations for Terminal Servers


I had an error in a previous post, and am not sure if it got posted,
so this may be a REPOST. If so, I apologize.



Fellow Netters,
	The following is being posted for a friend with no Internet
access. Please send responses to this account, and I will forward them.
Raj.

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

We are looking for recommendations for SLIP connectivity to an IBM RS/6000.
We have been told that the included SLIP device driver on the RS/6000
only supports 8 concurrent connections.  We are considering placing
terminal servers across an ethernet connection.  By placing the modem
pool on the terminal server we will be able to have the Slip connection
be routed across the ethernet to the RS/6000.  We know of no limit on
the number of TCP connections to the RS/6000.  

The requirements are:

	1. 9 to 50 SLIP connections to one or more terminal servers.
	2. Data rates of 19.2 to 56.7Kbps, expecting to use some
		switched 56kbps lines with async to sync converters.
	3. Transparent access  directly from the Mac to the RS/6000.
		We wish to avoid the need to login to the terminal server.
		We wish to have all calls routed to 1 or alternate
			 RS/6000's.
		We wish to have IP addresses dynamically assigned to 
		the remote user, independent of the phone line to the
		terminal server that they use.

The remote nodes are Apple Macintoshes running MacTCP, by Apple,
and MacSLIP, by Hydepark Software.  Without a terminal server we can
use the bootp daemon to dynamically assign addresses to the remote
users(so I'm told).  Do any terminal servers do this or have an
alternative method?  The goal is to forego addressing changes on the
remote nodes based on the phone line used for access.

We are considering the Telebit Netblazer.  We would also consider a
better SLIP device driver.  Recommendations?

--------------------------------------------------------------------------
-- 
===============================================================================
  __  __     .
 /   __/    /                               Raj Malhotra.
/   ( /_   /                                voice : (908)613 4313. 
        __/                                 email : manmetha@gauss.rutgers.edu

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

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 20:43:38 GMT
From:      solomon@becks.comm.mot.com (James Solomon)
To:        comp.protocols.tcp-ip
Subject:   Need list of commercial TCP/IP source code vendors


The subject line says it all.  Sorry if this is a FAQ but I haven't seen this
here lately.  Please respond by Email.  If I get enough interest I'll post the
response.

Thank you,
--
Jim Solomon (solomon@comm.mot.com)
Disclaimer:  It's my fault, not Motorola's.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 21:26:17 GMT
From:      "Mun Kein CHANG" <p00196@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Public Domain DNS

I am looking for a public implementation of a DNS server on PC, 
preferably being able to work in conjunction with FTP's PC/TCP.
Anyone's got any ideas?

Thanks and regards,
Mun-Kein.

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 21:38:14 GMT
From:      pearce@hook.corp.mot.com (Mike Pearce)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.realtime,mot.general
Subject:   Looking for embedded TCP/IP implementations


I'm looking for suggestions of TCP/IP products available in
source-code form in embedded environments as well as MS-DOS. Our
requirements are (briefly):

	- must support multiple interfaces per host (i.e.
	  'multi-homing' as defined by the rfc's), but does not
	  require full routing capabilities.

	- fairly small (I'll take what I can get, though).

	- supported (I'd really only consider commercial solutions in
	  other words).

	- source-licensable for development, binary licensable for
	  distribution with a product. Pricing is negotiable.

	- 'standard' API (i.e. Berkeley sockets preferred, TLI second
	  choice). Since this will be running inside of a DOS
	  virtual-machine under Windows 3.1 in 386 enhanced mode,
	  there is no hard requirement for the API to be available to
	  other Windows &/or DVM processes, but would that would be
	  nice.

	- 'standard' network interface, preferably Crynwr (Clarkson)
	  packet driver, but NDIS or ODI will do.

So far I've played with KA9Q's NOS, but it's kind of buggy, large, and
is really starting to look hacked up. Also, its lack of real support
and unclear licensing really rules it out for serious consideration.

We're also talking with Interactive about their StreamWare/TCP, which
provides a System V compatible STREAMS environment, is supported, and
source and binary licensable. But it's a little expensive, and I'd
really like to find out what else is available.

Please email responses to pearce@hook.corp.mot.com - I will summarize
to the net if requested.

Thanks for your time,

Mike

----
Mike Pearce
Staff Engineer, Motorola, Inc.
Corporate Computer & Communications Research & Development
Schaumburg, IL
email:	pearce@hook.corp.mot.com
phone:	(708) 576-0999
fax:	(708) 576-0892

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 92 22:23:19 GMT
From:      kherron@ms.uky.edu (Kenneth Herron)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: select()/ Bad File Number

ronf@panther3.panther.mot.com (Ron Feigen) writes:

>I have a situation where a socket gets closed and instead of select() 
>returning informing me that the socket is ready for reading, I get -1 and errno
>"Bad File Number".

We have a daemon that does the same thing when it accepts a connection
and no fds are available (this is dynix so the fd table is small and
static).  As far as I can tell, the client's connect succeeds, and
the server sometimes acts like the accept() has succeeded (I'm not
too clear on this part), but any attempt to use the fd from either
side gives an EBADF.  My conclusion is that dynix's network code
is completely unprepared to deal with this problem :-)

In summary:  Check the size of your fd table.
-- 
Kenneth Herron                                              kherron@ms.uky.edu
University of Kentucky                                         +1 606 257 2975
Dept. of Mathematics     "Your ball goes over them, it sails off the edge into
a huge cauldren of fire-breathing dragons."  "And they call this a par three?"

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 22:56:39 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Domain Name Service Deficiencies

tld5032@bcstec.ca.boeing.com (Terry Davis) writes:
}
}        This post attempts to summarize some experiences in utilizing DNS
}        in  a  very large corporate environment.  The installed base here
}        of TCP/IP includes over 50,000 active IP  addresses ...

     Here are some of my thoughts.  We are about an order of magnitude
     smaller but make a fair use of DNS and its cousin Hesiod.

}        1) DNS is designed to support INTERNET access  not  local  users.
}        If  the local LAN does not have a DNS nameserver on it, many user
}        environments will cease to function if the primary  network  feed
}        is lost.

     I am not sure I understand what you are saying here.  I agree that
     if a host can not reach a nameserver then things get grim, but I
     don't know why you'ld need one on each LAN.  I would think 2
     or 3 per "campus" would be adequate.

}        Configurable timeouts and re-trys  might  help  this  greatly  by
}        allowing  the  system  to  be  tuned  for its environment, LAN or
}        INTERNET.  It seems likely that these should  be  placed  in  the
}        /etc/resolv.conf file if they are used.

     I hate the way it always scans /etc/resolv.conf from top to bottom.
     This file should be read in-core and when the number-1 server is
     not responding, switch to another until it returns -- in fact I have
     toyed with the idea of writing a kluge daemon which does periodic DNS
     requests and re-orders /etc/resolv.conf when trouble is found.

}        2) There is  no  standard  way  of  determining  which  secondary
}        database  to  use (/etc/hosts or yphosts) when DNS is inoperable.
}        Worse yet is the case where no secondary lookup is allowed by the
}        operating system.  Very strange things happen when DNS  fails and
}        the secondary lookup either is non-existent or also fails.  Often
}        mounts and remote processes simply vanish.  It should not be  re-
}        quired for instance, for the administrator to maintain /etc/hosts
}        when NIS is already  running on  the system or to run NIS just to
}        support a  secondary lookup  function for DNS when  /etc/hosts is
}        already configured.
}        
}        Again, a configurable database lookup sequence for  gethostbyname
}        and gethostbyaddress resolve would go far to solve this problem.

     Like DEC's /etc/svc.conf which I really like.   Example line:

       hosts=local,bind,yp

}        4) In the operations area one of the shortcomings of DNS is  that
}        the  "refresh"  and  "expire"  fields cannot be set to a specific
}        time like refresh 5 minutes after every hour, or expire  at  4:45
}        AM  on Thursdays much like a crontab entry.  In a large operation
}        with tens of primary and secondary servers, the timing  of  these
}        events  becomes  increasingly  important to overall DNS stability
}        and responsiveness.
}        
}        5) Another DNS flaw is the lack of the ability to force a primary
}        server to reload or update only one of its many zones.  Often DNS
}        primary servers are reloaded hourly in  order  to  keep  up  with
}        changes  coming  in.   This  can  render a server unavailable for
}        several minutes when it has dozens of zones and thousands of host
}        and address entries to re-hash.
}        
}        6) Full implementation of dynamic updates to DNS would be a major
}        improvement in its operational functionality.  This could relieve
}        many of DNS operational difficulties.

     This is what I wish for most.  We update every hour and every hour
     we have a minute or so of wierdness while they read their files.
     Also, if we happen to have lost connectivity to the world (the root
     DNS servers) everything is all hosed over.

}        9) Another issue on the horizon, is the compatibility of  Netbios
}        nameservice,  DNS,  and X.500.  It would seem that these services
}        should be converging on a single standard; as of yet  this  isn't
}        clear.

     DCE CDS, maybe?

}        11) In addition to  DNS, the  resolver  routines  "gethostbyname"
}        and "gethostbyaddr" need  some extensive enhancements for life in
}        the network environment.  Some form of short lived caching  needs
}        to be provided, probably a most recent "10" lookups ...

     There would need to be some sort of short clock-time limit as well.
     I know we have machines which could go for a long time before looking
     up that 11th machine.

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

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 1992 23:12:16 GMT
From:      mcs@unislc.uucp (Michael Sontum)
To:        comp.protocols.tcp-ip
Subject:   Re: What is  "RMON" ? Please explain .

From article <gdox.722256753@informatik.tu-chemnitz.de>, by gdox@informatik.tu-chemnitz.de (Guntram Dox):
> 
> Hi,
> 
> I read the term "RMON" in a marketing paper from cabletron. 
> 
> Somebody told me, it should be something new on top of SNMP .  Programming
> interface , or so.
> 
> Could somebody explain it in more detail ?
> Please, email to me, too. My access to this news group will be a little bit
> difficult in the next weeks.
> Or any pointers to other information would be great.
>

My knowledge is also sketchy but I recall that it is something like providing
almost a sniffer type capability to snmp. 

You might try comp.protocols.snmp

I looked through Marshall T. Rose "The Simple Book" from Prentice Hall and 
the index was down right annoying. I did not see any reference to it.

The only other thing is the gurus have an electronic magazine you can
get for free by emailing to
To: st_subscriptions@simple_times.org
Subject: help
Add me to the mailing list.

There is also an snmp discussion group: send a note to
snmp_request@uu.psi.com
and asked to be added to the snmp@uu.psi.com  list

Also look at the rfc's.

         Mike Sontum

"SNMP:That Dog'll Hunt" -Dr.Jeffrey D. Case       



 

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 02:05:08 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   SCO ODT, DNS queries within a C program

I am currently writing some code to enable a C application to lookup MX
records by calling res_mkquery() and res_send() under SCO ODT 2.0.  What I am
seeing is that the first time we do it everything works as expected, but the
second time the answer that comes back is much shorter and in the course of
trying to parse it we dump core.

The arguments to res_mkquery() and res_send() are the same both times.

Has anyone else ever seen a problem like this?

Frank.
--
___________________________________________________________________
Frank I. Reiter                 Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 09:03:52 EST
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: SNA <-> IP Encapsulation

In article <1992Nov20.053647.25809@cheops.qld.tne.oz.au>,
logier@cheops.qld.tne.oz.au (Rob Logie) says:

>mndot@msus1.msus.edu writes:
 
>>I am trying to provide mainframe connectivity to a number of remote sites.
>>Most of the sites have IBM 3174 (or compatible) remote controllers for SNA
>>communications.  This comm. takes place over multidrop 9600 bps lines.  We
 are
>>in the process of installing T1 circuits to all of those same locations.  The
>>T1's are primarily IP.  Does software exist for the 3174 to allow SNA
>>encapsulation in IP packets?  I have seen hints of this scenario on some of  e

Believe it or not, there is optional RPQs for LIC 3174 that allow
the 3174 to be a communications gateway to an IP network.  This also
involves converting/adding a TRN interface, and coax-attached PCs.
Don't know its available in IBM W.T. countries.

/Pete (pmw1@psuvm.psu.edu)
--
Peter M. Weiss                     | not affiliated with psuvm.psu.edu|psuvm
31 Shields Bldg -- Penn State Univ.| "Connectivity is more than a Connection"
University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 05:53:49 GMT
From:      jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy)
To:        comp.protocols.tcp-ip
Subject:   Pascal Waterloo TCP/IP library

In article <peter.722065275@palin.cc.monash.edu.au> peter@palin.cc.monash.edu.au (Peter Hawkins) writes:
>I need to interface a turbo pascal (V6) application to TCP/IP. The
>application is heavily OOP & TVision etc so I pretty well am forced
>to use turbo pascal. It's huge & re-writing in C is not practical.
>I could use novell IPX & Banyan Vines, but I want it to be more
>general if I can.
>
>I got a copy of wattcp - a mixture of asm & C, and compiled it with
>BCC, but unfortunately I couldn't link the C & pascal object files
>without leaving unresolved externals - Borland's advice was that
>interfacing C to Pascal will not work with any C code which is either
>not-straightforward (in calling) or which utilises intrinsic libraries.
>(They advised against my attempting it - and suggested I re-write the
>TCP/IP stack in pascal!)

First get the Waterloo TCP/IP manual and make identical functions in
C itself like psock_init(), psock_read() which calls sock_init()
and sock_read() respectively. Declare psock_init() in the waterloo
as 
pascal psock_init()
This directive is for linking your pascal routines correctly with
the C function with correct function parameters. You have do the
pascal psock_init()
in one of the Waterloo TCP/IP source files itself. Build the Waterloo
TCP/IP library. Now make a small pascal routine which calls psock_init()
or psock_read() and compile and link it with the new library and all
the support pascal and c libraries like cs.lib + maths.lib etc.,
Wild guess - Might work ...

>Before embarking on a major project such as re-writing the stack, or
>giving up and using IPX and Vines, I thought I'd try and see if anyone
>knew:
>
>1)  What public domain / commercial TCP/IP stacks are there which might
>    be callable from turbo C?
>
>2)  Are there any stacks around written entirely in assembly or (joy of
>    joys!) pascal?
>
>Thanks in advance,
>
>Peter

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



-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 06:31:11 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP & Duplicate IP addresses

In article <1992Nov20.202906.9279@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes:
> Hello Net
> 
> I would value opinions, advice and information on the topic of handling 
> duplicate IP addresses with ARP.
> 
> Specifically
> - Is it a good idea to ARP your own IP address on startup? A returning
>   ARP would tell you that the address was a duplicate.
>   - if so is it a good idea to automatically shut your interface down 
>     if a duplicate IP address is detected on startup? Are there any
>     situations where false returns might be reported? 
>  -  What about detecting one after startup? Should you advise the user
>     and gently start terminating connections? Could be real annoying.
> 
> - If you receive an incoming ARP request and the sender IP address matches
>   yours should you reply to it? Doing so would advice the other node that
>   a duplicate exists (assuming it checks) but also could hopelessly confuse
>   a host that doesn't.  All of the implementations that I have tested do not
>   reply - but I have not tried all that many.
> 
> - What are the consequenses of staying up with a duplicate IP address?
> 
> I would value some insight into this topic. Thank You


For some years Silicon Graphics systems have actively defended their IP
addresses.  Instead of just complaining on the console when they see
some other machine ARP'ing their IP address, they respond with an ARP
response of their own.  (With a suitable timeout to prevent network
storms.)

If you don't do this the first machine with the duplicate IP address to
speak disappears.  And the 2nd machine never notices that anything
is wrong.

On the other hand, this ARP screaming often keeps both stations on the
air for rlogin or telnet long enough to take corrective action,
avoiding the need for a house call.  As important, having the old
holder of the address scream causes the interloper to complain on its
console (assuming BSD style console complaints).  The machine that
needs correcting is probably the new user of the IP address.


Vernon Schryver,  vjs@sgi.com

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 92 10:08:55 GMT
From:      j.laidman@cowan.edu.au (Jeremy Laidman)
To:        comp.protocols.tcp-ip
Subject:   Re: REQ: MSDOS TCP/IP stack in ASM or Pascal

peter@palin.cc.monash.edu.au (Peter Hawkins) writes:

>I need to interface a turbo pascal (V6) application to TCP/IP. The
>application is heavily OOP & TVision etc so I pretty well am forced
>to use turbo pascal. It's huge & re-writing in C is not practical.

[stuff deleted]

>Before embarking on a major project such as re-writing the stack, or
>giving up and using IPX and Vines, I thought I'd try and see if anyone
>knew:
 
>1)  What public domain / commercial TCP/IP stacks are there which might
>    be callable from turbo C?
 
>2)  Are there any stacks around written entirely in assembly or (joy of
>    joys!) pascal?

I have a copy of PCGopher source code that I got on the internet somewhere.
This has been written in TP6 and interfaces to packet drivers.  I believe
this was written using TVision.  It went under the name of PCG2_SRC.ZIP.
Drop me a line if you work out how to use it.

---------------------------------------------------------------------
Jeremy Laidman, Computer Support Officer
Department of Computer Science                 Phone: (61 9) 370 6648
Edith Cowan University                         Fax:   (61 9) 370 2910
Perth, Western Australia                       j.laidman@cowan.edu.au
---------------------------------------------------------------------

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 92 11:21:50 GMT
From:      heimir@plusplus.is (Heimir Thor Sverrisson)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 X.29 software wanted for RS6000

gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:


>	Hi, I've been entasked with locating software which runs
>	on an RS6000 under AIX and which provides X.25 connectivity
>	(serial 56Kbps links) and X.29 PAD (incoming and outgoing)
>	as well as application hooks (like sockets).
 
>	Can anyone here direct me to who makes or sells such
>	software? 

Try:

    Hugbunadur hf, P.O. Box 437, 202 Kopavogur, Iceland
    Tel: +354-1-641024, Fax: +354-1-46288

They are selling a product called HBX-PAD conforming to X.3, X.28 and
X.29 with simple program hooks as well.  I have no direct connection to
them anymore, but was on the team that developed the product, so I
won't tell anymore about it - ask them.

-- 
Heimir Thor Sverrisson		|		heimir@plusplus.is
Plusplus Inc.			|
Laugavegi 13			|		Tel: +354-1-620 250
108 Reykjavik, ICELAND		|		Fax: +354-1-622 819

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 92 18:59:59 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: MS-Kermit 3.12 + TCP + PKTMUX-12 ???

In article <1992Nov21.181645.8204@nsscmail.att.com>, rick@nsscmail.att.com (Rick Calder) writes:
> 	Has anyone gotten mskermit 3.12 to work with pktmux 12 when other
> TCP software is also active ??
> 	When I run kermit via TCP as the 1st pktmux user, there is no problem.
> If something else has the 1st pktdrv, like PCTCP ethdrv, then the kermit
> session over TCP will lockup on the UNIX host side.  Kermit is still active,
> the UNIX side still has its shell running, but nothing can be entered to
> UNIX via kermit.  Kermit does still respond, as I can do a normal hangup.
> 
> setup that works :		setup that doesn't work :
> 	autoexec.bat :			autoexec.bat :
> 		pktmux				pktmux
> 		pktdrv				pktdrv
> 		pktdrv				pktdrv
> 	run kermit via tcp			ethdrv
> 					run kermit via tcp
> 
> 			Thanks in advance,
> 
> 		Rick Calder
> 		      [att!]rick!rick     rick@rick.att.com
> 				attmail!rcalder
> -- 
> 		Rick Calder, NCR Systems Support Center - New Jersey
> 		      [att!]rick!rick     rick@rick.att.com
> 				attmail!rcalder
-------------------
	Of course, it's not Kermit as such, but any TCP/IP Telnet application
which would produce this result. A packet monitor and a quiet day is needed 
to sort out the changes pktmux probably made to the Telnet traffic from Kermit 
(all legit stuff, nothing wierd). So, once again we need to remind people that
as clever as pktmux is, and it is clever, it cannot solve many fundamental 
conflicts because there are no solutions. I hope that nothing important was 
lost in these tests.
	You might notice something useful about the way Kermit employs
Telnet. It attaches to the Packet Driver when Telnet service is required, and
then it frees that attachment at the end of the Telnet session, all while 
remaining active.
	Folks will chuckle at the following suggestion, but it is consider
purchasing a second lan adapter. Today's prices of $100-$200 make it realistic.
And yes, the laughter is at the irony of coming full circle. Alternatively,
you could run Kermit over FTP's tnglass Int 14h hooker, or over a handy
NetBios link to the Unix box (if convenient), etc. Kermit supports most of
the communication methods associated with PCs.
        Joe D.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 92 17:35:49 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: What is  "RMON" ? Please explain .

Article <gdox.722256753@informatik.tu-chemnitz.de>,
  by gdox@informatik.tu-chemnitz.de (Guntram Dox):
>> I read the term "RMON" in a marketing paper from cabletron. 
>> Somebody told me, it should be something new on top of SNMP .  Programming
>> interface , or so.

In article <1992Nov20.231216.21904@unislc.uucp> mcs@unislc.uucp (Michael Sontum) writes:
>My knowledge is also sketchy but I recall that it is something like providing
>almost a sniffer type capability to snmp. 

The RMON (Remote MONitoring) MIB (Management Information Base) is a
programming specification for how a "sniffer"-like network monitor can
be remotely managed using a modular extension to the SNMP protocol.

Having defined RMON does not magically confer such a monitoring
capability to all SNMP manged network components. Rather, the spec is a
recognition by the IETF (Internet Engineering Task Force) that several
vendors wre implementing such monitoring stations (the first widely
deployed one was the "LANtern") and it would be helpful if they had a
common interface.

RMON boxes (i.e. boxes that do nothing but RMON) are available from
several sources, including some free MS-DOS/PC-based software. RMON
features are also becoming available on the management processor of some
"smart HUBs" (i.e. ethernet repeaters with a microprocessor on the side
for collecting statistics) and on some bridges.

What is harder to find, is an affordable management station that will
display something useful without going through contortions. There is a
lot of value in good user interfaces for massive amounts of data - just
look at the price of the Sniffer and its cousins.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 18:16:45 GMT
From:      rick@nsscmail.att.com (Rick Calder)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   MS-Kermit 3.12 + TCP + PKTMUX-12 ???

	Has anyone gotten mskermit 3.12 to work with pktmux 12 when other
TCP software is also active ??
	When I run kermit via TCP as the 1st pktmux user, there is no problem.
If something else has the 1st pktdrv, like PCTCP ethdrv, then the kermit
session over TCP will lockup on the UNIX host side.  Kermit is still active,
the UNIX side still has its shell running, but nothing can be entered to
UNIX via kermit.  Kermit does still respond, as I can do a normal hangup.

setup that works :		setup that doesn't work :
	autoexec.bat :			autoexec.bat :
		pktmux				pktmux
		pktdrv				pktdrv
		pktdrv				pktdrv
	run kermit via tcp			ethdrv
					run kermit via tcp

			Thanks in advance,

		Rick Calder
		      [att!]rick!rick     rick@rick.att.com
				attmail!rcalder
-- 
		Rick Calder, NCR Systems Support Center - New Jersey
		      [att!]rick!rick     rick@rick.att.com
				attmail!rcalder

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 18:27:04 GMT
From:      cs000hf@selway.umt.edu (Hong Fan)
To:        comp.protocols.tcp-ip
Subject:   how to setsockopt to reuse local address

Hi, everyone:


Does anyone know how to use 'setsockopt' to reuse the local address on the 
client site? I want to setup two socket connections as the following
associations.

 { tcp, server, 1500, client, 1000 }
 { tcp, server, 1501, client, 1000 }

One way I tried is setsockopt(sock,SO_SOCK, SO_REUSEADDR,(char *)&on,sizeof(on))
on the client site after the creation of sock. but it still gave me another
port number. Do I need to setsockopt on the server site?

If you know how to solve this problem, please mail me at cs000hf@selway.umt.edu
I appreciate your time and help.

sincerely

hong fan


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 20:02:24 GMT
From:      scoggin@snow-white.ee.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: What is  "RMON" ? Please explain .

In article <1992Nov20.231216.21904@unislc.uucp> mcs@unislc.uucp (Michael Sontum) writes:
>From article <gdox.722256753@informatik.tu-chemnitz.de>, by gdox@informatik.tu-chemnitz.de (Guntram Dox):
>> 
>> Hi,
>> 
>> I read the term "RMON" in a marketing paper from cabletron. 
>> 
>> Somebody told me, it should be something new on top of SNMP .  Programming
>> interface , or so.
>> 
>> Could somebody explain it in more detail ?
>> Please, email to me, too. My access to this news group will be a little bit
>> difficult in the next weeks.
>> Or any pointers to other information would be great.
>>
>
>My knowledge is also sketchy but I recall that it is something like providing
>almost a sniffer type capability to snmp. 
>
>You might try comp.protocols.snmp
>
>I looked through Marshall T. Rose "The Simple Book" from Prentice Hall and 
>the index was down right annoying. I did not see any reference to it.
>
>The only other thing is the gurus have an electronic magazine you can
>get for free by emailing to
>To: st_subscriptions@simple_times.org
>Subject: help
>Add me to the mailing list.
>
>There is also an snmp discussion group: send a note to
>snmp_request@uu.psi.com
>and asked to be added to the snmp@uu.psi.com  list
>
>Also look at the rfc's.
>
>         Mike Sontum
>
>"SNMP:That Dog'll Hunt" -Dr.Jeffrey D. Case       
>
>

Current Internet Draft documents concerning RMON may be obtained as
follows:

	System:		ftp.nisc.sri.com
	Directory:	internet-drafts
	Files:		draft-ietf-rmon-mib-01.txt
			draft-ietf-rmon-trap-00.txt

For some reason, rollout and standardization seem to going very slowly.
This has not stopped a number of manufacturers (Hewlett-Packard, Novell, and
TTC come to mind) from introducing "RMON-compliant" monitors, even though
there is NO standard yet!

Of course, there always comes a time when you have to stop studying and
start implementing - fish or cut bait...  I am planning on buying 25 or 30
RMON segment monitors this spring for our network.

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Nov 1992 22:09:22 GMT
From:      dlucy@sandr.COM (Doug Lucy)
To:        biz.sco.general,comp.sys.mac.hardware,comp.sys.mac.misc,comp.sys.mac.system,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Macintosh/Localtalk to SCO/Ethernet


I've got to set up a Macintosh to connect to our net and I need some
help pointing me to the right hardware and software.

What we've got now is a small network (8 users) on PC's running DOS,
Desqview/X, and FTP's PC/TCP all connected to a SCO Unix 3.2.4
(actually OpenDesktop 2.0) running SCO TCP/IP and NFS and X.

We need to add a Macintosh to this network. The Macintosh needs to run
X sessions and some kind of NFS.

What kind of hardware does a Macintosh (let's say a new IIvx) need to
connect to the TCP/IP Ether? What kinds of cards are available? What's
the MOST COMPATIBLE?

More importantly, what kinds os software exist for running TCP/IP,
NFS, telnet, and X windows server under System 6 and/or 7? Does the
Macintosh ethernet hardware suffer from the same problems as the IBM
PC (i.e. you buy a piece of software for your SPECIFIC ethernet
card)?

My first need is to do all this via Ethernet. However, I want to
eventaully also test the possibility of doing a telnet across
AppleTalk (or LocalTallk, whatever) to some sort of LocalTalk/Ethernet
bridge/gateway.

For now:

	+-----+
	|     |         |
	| Mac |  Ether  |
	|     +---------+
	+-----+         |
	                |
	                |
	+-----+         |
	|     |         |
	| PC  |  Ether  |
	|     +---------+
	+-----+         |
	                |
	                |
	+-----+         |
	|     |         |
	| SCO |  Ether  |
	|     +---------+
	+-----+         |


Later:

	+-----+
	|     |             +--------+
	| Mac | LocalTalk   |        | Ether  |
	|     +-------------+ Bridge +--------+
	+-----+             |        |        |
			    +--------+        |
	                                      |
	                                      |
	                      +-----+         |
	                      |     |         |
	                      | PC  |  Ether  |
	                      |     +---------+
	                      +-----+         |
	                                      |
	                                      |
	                      +-----+         |
	                      |     |         |
	                      | SCO |  Ether  |
	                      |     +---------+
	                      +-----+         |

Any and all help is greatly appreciated.

-- 
| Doug Lucy             | Xenus(tm)                                   |
| VP Technical Services | Total Security Automation for the           |
| S&R Software, Inc     | protection of Classified, Proprietary, and  |
| dlucy@sandr.com       | Sensitive information 804.320.4057          |

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Nov 1992 01:21:15 GMT
From:      Richard.Kooijman@dnpap.et.tudelft.nl (Richard Kooijman)
To:        comp.protocols.tcp-ip
Subject:   Re: What is "RMON" ? Please explain .

scoggin@snow-white.ee.udel.edu (John K Scoggin) writes:

>	System:		ftp.nisc.sri.com
>	Directory:	internet-drafts
>	Files:		draft-ietf-rmon-mib-01.txt
>			draft-ietf-rmon-trap-00.txt
 
>For some reason, rollout and standardization seem to going very slowly.
>This has not stopped a number of manufacturers (Hewlett-Packard, Novell, and
>TTC come to mind) from introducing "RMON-compliant" monitors, even though
>there is NO standard yet!

RFC 1271 is the official name for the Ethernet RMON MIB.

>Of course, there always comes a time when you have to stop studying and
>start implementing - fish or cut bait...  I am planning on buying 25 or 30
>RMON segment monitors this spring for our network.

May I state here that our group has a freely available RMON monitor
for OS/2 machines? You only need a PC with enough RAM, OS/2, an Ethernet
card and our software.



Richard.

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Nov 1992 07:03:53 GMT
From:      cyberchrist@wam.umd.edu(X)
To:        comp.protocols.tcp-ip
Subject:   etherfind-type program for the Mac


I'm currently working on a SUN SPARC, running the program
etherfind to debug a local network, and need to have the
same capabilities on a mac.  Is there anything out there?
please mail me  bluefish@wam.umd.edu

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 92 16:50:49 GMT
From:      jessea@vpmeu015.me.vp.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Checking for valid ip address (in ascii form).

Does anyone have any suggestions on how to check for a valid IP address
that is in ascii from (not in network byte order)?  What I'm doing is
reading in a string that should be made up of a dot notation IP address
and I want to validate it.  Unfortunately, inet_addr takes a whole lot
of numbers as valid - even if it isn't in dot notation.  It will take
"10000" as a valid ip address, for example.  It may be, but it really
isn't in my case because I want to enforce dot notation.  Is there a
function I'm not aware of that will do this level of checking?  Will I
just have to do it myself?

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Nov 1992 17:18:10 GMT
From:      davecb@nexus.yorku.ca (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Balkanization of the InterNet inevitable?

In article <141672@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes:
|   Are network security firewalls between organizations and the InterNet
| going to be the norm in the future? 
 [...]
|   If the Balkanization of the InterNet is inevitable, I feel it will be a
| great loss.  It will be an acknowledgement that irresponsible criminal
| hackers have won from us our freedom of open inter-operation.  What a
| sad thought.  Are there no other realistic options for providing security?
| Is it impossible to conceive of effective authentication methods?

smb@ulysses.att.com (Steven Bellovin) writes:
|For the most part, authentication isn't the issue.


  Well, the cracker density is the real consideration (:-)) We're
**very fortunate** in the Internet: commercial firms using X.25
services like the Canadian ``datapac'' find that instead of gaining
security (a vendor promise), they get a very large number of failed
connection attempts.

  These attempts stem from hobbyist crackers working their way through
a universally-acessable, low cost, **receiver pays** service that can
be dialed into from almost every major city in the country, with a
dense set of ``phone numbers'' each of which connects to a known
computer.

   Of course, most sites using this service don't pay attention to the
failures.  Occasionally they discover their monthly bill has leaped up
and that most of the calls are from Brazil, where the traceback
information is unavailable.
   They get little help from the service provider at this point: obviously
its the customer's fault for having bad security on their side of the
PAD, and they can pay the bill, please, forthwith!


  Balkanization? Yes, to a degree, as we strive to learn from our
mistakes.  Of course, if we fail to learn from our governmental
colleagues' mistakes, we deserve to be balkanized (:-))

--dave
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional email consultant.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Nov 1992 19:21:30 GMT
From:      root@mjbtn.jobsoft.com (Mark J. Bailey [ADMIN])
To:        comp.unix.ultrix,comp.unix.bsd,comp.protocols.tcp-ip,comp.sys.dec
Subject:   SL/IP and routing under Ultrix 4.2 on VaxStation 3100

Hello,

We are trying to figure out a problem and maybe some of you can help us.

what we are trying to do is use SL/IP on a VaxStation 3100 running Ultrix
4.2 to connect a 286-AT running an amateur radio tcp/ip software package
called (KA9Q).  Getting the link up is no problem.  The 286-AT machine is
then linked on the radio interface (ax0) to a wireless TCP/IP network around
our region on the amateur radio bands.  The VaxStation is called 'turing'
and its IP address is 161.45.1.14.  It is on a LAN of other Ultrix 4.2
workstations connected via thinnet ethernet.  There are no subnets present.
The entire ethernet is one network.  The 286-AT is called 'w4efq' and has
an IP address of '161.45.63.4'.  The wireless network is '44.34'.  It is
not so much involved with the problem we are currently trying to figure out
so I will not really explain it further.

As I mentioned, the slip link is working fine between w4efq (286-at) and 
turing (vaxtstation).  From either end, you can telnet the other.  Turing
is the SLAVE and w4efq is the MASTER in this arrangement (ie, w4efq logs
into turing and runs '/usr/new/slattach' as its login shell).  W4efq has
all '44.34' addresses going out interface ax0 (radio) and all '161.45'
addresses going down sli0 (slip link to turing).  Turing's route table
shows w4efq.  If you run ifconfig (no args) it shows ln0 (the ethernet
with dynamic routing, and so on) and sl0 (slip to w4efq) as being POINT-TO-
POINT.  We have the /etc/sliphosts file setup fine as best we can tell.

What our problem is, is that we cannot seem to get other workstations
on the ethernet to be able to access w4efq via the slip interface on turing
*UNLESS* we specifically add a route to the workstation in particular
that says
route add 161.45.63.4 161.45.1.14 1
ie, w4efq is via gateway turing.  Then it works great!?!?  w4efq has no 
problem replying to say, 161.45.1.1, and 161.45.1.1 will reach w4efq as long as we manually add the route above.  what we want it to somehow have turing
be "listening" for w4efq's address and say "ah, i know what to do with
this one" and send it up the sl/ip line.  We don't want to have to go to 
each and every workstation and add routes by hand.  likewise, it seems to
me that one should not have to update every node in a network if you use
sl/ip to "bridge" another network in (as in my case); attaching it to just
one node in the main network (in my case, turing).  Maybe I am wrong.  :-)
I know I am confused!  :-)

we played around with ARP on turing (no luck so far), and some other stuff.  

So, bascially can what I have described be done the way I want it to?  If
not, why?  If so, how (from the beginning if necessary!  :-)) ????  
Ultimately, we would like any node in our 161.45 network to be able to 
telnet 161.45.63.4 (w4efq) and get a prompt.  Conversely, from w4efq,
we would like to telnet any of the other 161.45 nodes and get to them as
well.  It is almost like some sort of subnet must be established on 
turing, but I am really not sure how it would be done.  Turing somehow
has to be listening and when it hears a request for w4efq, do something
about it (send it up the sl/ip).  

Well, that is roughly what we are confronted with.  Any help whatsoever
would be MOST appreciated!!!  We have been trying to figure this for a week
or so and haven't gotten anywhere.  

Thanks in advance!

Mark

P.S.  email replies if you like (would), this really doesn't need to waste
      anymore net bandwidth.
-- 
Mark J. Bailey, N4XHX                              _______/====X11====\_______
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 |         JobSoft         |
VOICE:  +1 615 893 0098                            | Design & Development Co.|
UUCP:   ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb  |  Murfreesboro, TN  USA  |
DOMAIN: mjb@mjbtn.JOBSOFT.COM      CIS: 76314,160  ---------------------------
<KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Nov 92 21:45:57 GMT
From:      rmaszkow@nyx.cs.du.edu (Rafal Maszkowski)
To:        comp.protocols.tcp-ip
Subject:   how to restart broken file transmission in ftp?


How can restart file transfer when I lost connection and I have, say, 20 MB
transmitted and 10 still not?

Rafal


-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Nov 1992 22:46:43 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: how to restart broken file transmission in ftp?

In article <1992Nov22.214557.26023@mnemosyne.cs.du.edu>, rmaszkow@nyx.cs.du.edu (Rafal Maszkowski) writes:
> 
> How can restart file transfer when I lost connection and I have, say, 20 MB
> transmitted and 10 still not?
> 
> Rafal


% ftp blah
% !!

? 
-- 

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

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 1992 00:17:29 GMT
From:      sommerfeld@apollo.hp.com (Bill Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: how to restart broken file transmission in ftp?

In article <1992Nov22.214557.26023@mnemosyne.cs.du.edu> rmaszkow@nyx.cs.du.edu (Rafal Maszkowski) writes:

   How can restart file transfer when I lost connection and I have, say, 20 MB
   transmitted and 10 still not?

The answer to this is specific to your FTP implementation.

Recent versions of the BSD ftp and ftpd support a restart option,
which can be accessed using the "restart" and "reget" commands to the
FTP client; if your FTP client supports these commands, and the server
does as well, you're in business.

This code comes from Berkeley, and is in at least 386BSD and HPUX
8.07; I'm not sure when it was introduced.

Check your vendor and/or on-line documentation; if the support isn't
available, you may also be able to pick up the sources to the berkeley
FTP by anonymous FTP and port and build them yourself..

					- Bill






-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 92 09:05:30 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet firewall help?

In article <1992Nov23.130546.7563@atlastele.com>, brians@atlastele.com (Brian Sheets) writes:

| Well here I sit with this new neato kean network stuff but, do to the nature
| of our company I cannot hook it up until I can assure that nobody will be 
| able to telnet or make other unauthorized entries into our system.
| 
| So other that turning off telnetd does anyone have any suggestions??

Well there's a couple of ways of doing what you want to do.  If your
gateway to the Internet is a router that can handle per-port filtering
(e.g. a cisco), then you can disallow packets coming into TCP port 23
(TELNET) or 513 (rlogin) (you might want to filter out 514 [rsh], 21
[FTP] and who knows what.)

If you don't have that capability, you can put the filtering burden
on all your hosts.  Get a TCP/UDP master server that's capable of
disallowing connects on a per-IP-address basis, such as TGV's
MultiNet (VMS only) or the TCP_WRAPPER program on cert.sei.cmu.edu
in pub/network_tools/tcp_wrapper.

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

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 1992 05:34:00 +0000
From:      rmt@cix.compulink.co.uk (Richard Thomas)
To:        comp.protocols.tcp-ip
Subject:   No subject

Apologies folks: this is just a test transmission

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 92 05:36:49 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Balkanization of the InterNet inevitable?


  Well, I've received several replies regarding my unhappiness with
network firewalls.  They fall into the following categories:

    1.	I'd rather protect one machine than the ten-thousand behind it.

    2.	So what are the [lauded] services are you missing?

    3.	Don't worry.  Firewalls aren't as bad in general as the one you're
	living behind.

  The third item answers the second to some extent.  The firewall I have
to deal with only supports outgoing telnet and ftp sessions via a set of
utilities apparently fronted by Sun: itelnet and iftp.  These work by
routing their outgoing connections through proxy servers on a machine
which is allowed to access the outside world and is also exposed to it.
The only incoming connection arrangement is via a separate machine which
only allows telnet connections.  Mail is MX'ed up the wazoo.  I'm not
sure how News is handled.  (I don't know because I don't use the systems
behind the firewall.  I maintain my home on GAUSS.LLNL.GOV and do all my
outside communication from here because I can avoid the firewall and it's
hassles.)  One of my biggest gripes is that we only have itelnet and iftp
clients for Suns.  This leads to seemingly endless multi-hop store and
forward ftp acts guaranteed to try your patience.

  I suppose I should subscribe to the firewalls mailing list suggested by
Robert K. Stodola in order to determine just how bad the situation is in
general.  So I'll study up on what the ``state-of-the-art'' is and return
to flame later ... :-)

Casey

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1992 05:40:48 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP & Duplicate IP addresses

In article <1992Nov20.202906.9279@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>- Is it a good idea to ARP your own IP address on startup? A returning
>  ARP would tell you that the address was a duplicate.
>  - if so is it a good idea to automatically shut your interface down 
>    if a duplicate IP address is detected on startup? Are there any
>    situations where false returns might be reported? 

There are two situations where you're likely to get a response.  One is
when two machines are configured with the same IP address.  The other is
when you're configured for the wrong subnet and there's a router that
implements proxy ARP.  Either way, there's a serious configuration problem
and the user should be informed.

> -  What about detecting one after startup? Should you advise the user
>    and gently start terminating connections? Could be real annoying.

I think you should advise the user, but not terminate connections.
However, if packets reach the other host, it may terminate your
connections.

>- If you receive an incoming ARP request and the sender IP address matches
>  yours should you reply to it? Doing so would advice the other node that
>  a duplicate exists (assuming it checks) but also could hopelessly confuse
>  a host that doesn't.  All of the implementations that I have tested do not
>  reply - but I have not tried all that many.

Either you or the other host is hopelessly confused already, so it's not
clear that replying would make things too much worse.

>- What are the consequenses of staying up with a duplicate IP address?

Some packets that are intended for you will be sent to the other host, and
vice versa.  Confusion will reign.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1992 09:22:55 GMT
From:      dclunie@pax.tpa.com.au (David Clunie)
To:        alt.sys.sun,comp.sys.sun.misc,comp.sys.sun.admin,comp.sys.sun.wanted,comp.unix.solaris,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Packet filtering for Sun needed

I have a server based on a sparc running 4.1.2 connected to the outside
world via a slip connection.

I have a need to be selective about the packets that come in and go out
both in terms of what they are, where they are from and who they are to.
I don't have anything like a cisco router to put in between unfortunately,
I want the sun to do it itself. I am aware of inetd replacements like
log-tcp but that doesn't help with outgoing connections.

Has anyone seen or hacked up anything that will do this ? Seems like a
common enough need, but I don't know how to go about doing it myself.

david



-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 1992 13:05:46 GMT
From:      brians@atlastele.com (Brian Sheets)
To:        comp.protocols.tcp-ip
Subject:   Telnet firewall help?

Well here I sit with this new neato kean network stuff but, do to the nature
of our company I cannot hook it up until I can assure that nobody will be 
able to telnet or make other unauthorized entries into our system.

So other that turning off telnetd does anyone have any suggestions??

brians
-- 
Brian Sheets		    _   /|  	"TRUCK?! What truck?"
153 N. Hayden Bay Dr.	    \`o_O'    	 
Portland, Or 97217	      ( ) 	   -Raiders of the Lost Ark
brians@atlastele.com           U

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1992 16:53:10 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        alt.sys.sun,comp.sys.sun.misc,comp.sys.sun.admin,comp.sys.sun.wanted,comp.unix.solaris,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Packet filtering for Sun needed

David Clunie (dclunie@pax.tpa.com.au) wrote:
: 
: I have a need to be selective about the packets that come in and go out
: both in terms of what they are, where they are from and who they are to.
: I don't have anything like a cisco router to put in between unfortunately,
: I want the sun to do it itself. I am aware of inetd replacements like
: log-tcp but that doesn't help with outgoing connections.

The Morning Star PPP software (which also speaks SLIP) has a complete
set of packet filtering tools which would let you selectively block
traffic over the line based on ports.  I'm quite sure that it would
meet your requirements as described.

I've attached contact information below.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB

Symbol: morningstar
Name:   Morning Star Technologies, Inc.
	1760 Zollinger Road
	Columbus, OH 43221

Voice: +1 614 451 1883
Sales: +1 800 558 7827
FAX:   +1 614 459 5054
Email: sales@morningstar.com

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 92 18:14:14 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.wintcp
Subject:   Re: WIN-TCP/DECwindows device conflict. Whats's up with that?????


In article <1992Nov20.194054.1499@alw.nih.gov>, ramon@helix.nih.gov (Ramon J. Hontanon) writes:
|>In upgrading our trusty VAXstationII GPX from VMS 5.0 to VMS 5.4 we
|>found out that our version of The Wollongong Groups's TCP/IP allocates
|>three devices (GAA0: GAA1: GAA2:) that will need to be used by
|>DECwindows.
|>The result: DECwindows refuses to install. The DEC people found this
|>out, and it seems true, 'cause DECwindows starts fine if I don't run
|>WIN/TCP. I guess my question is:
|>
|>What version of WIN/TCP do I need to go to in order to fix this bug?
|>
|>Will we be required to buy the product again, or do we just simply
|>upgrade? 
|>
|>The e-mail address of The Wollongong Group would also be appreciated.

This is being investigated off-line, but I thought I'd post an initial
response for everyone else.

To my knowlege, we do not allocate GAA devices. We're running VMS versions
ranging from V5.1 through V5.5 with DECwindows or Motif and there should
be no conflicts.

Here are a couple of email addresses for customer use:

	support@twg.com	- Support requests
	sales@twg.com	- Sales and product info requests

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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 1992 19:29:37 GMT
From:      huntting@advtech.uswest.com (Brad Huntting)
To:        comp.dcom.lans.ethernet,comp.dcom.isdn,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: remote tcp/ip LAN access ideas

In article <722011367snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes:
 
>   Watch out.  Telecommuting may be just around the bend for your
>   company.  Don't let it catch you asleep at the wheel.
 
>Holy shit, Steve, is NYNEX just figuring this out?!?!???
 
>Sorry for the gratuitious flamage, but maybe that's what the baby
>bells need?

Yup.  Until just a few months ago my supervisor (at U S WEST) was
unable to fathom telecomuting.  He used a Mac, and might have been able
to login to a unix machine if he had a system administrator on the
phone with him.  When I brought up the subject of working at home with
him, I got a vacant stare as if I had just asked him "I'm going to die
tomarrow and was wondering if I could keep working from beyond the
grave".

I'm fortunate now to have a new supervisor who understands that I dont
have to be in the building to work.  (Of course she lives several miles
up Boulder canyon and is probably snowed in herself today).

There is hope though...  At least there is a concensis (now that ATT is
out of the picture) that UUCP is not the ultimate answer to the worlds
networking needs.  :-)


brad

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 92 19:59:56 GMT
From:      feoh@hal.gnu.ai.mit.edu (Chris Patti)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   RAW SPEED numbers for various TCP-IP implementations


Hello.

Does anyone have any raw numbers on how fast various TCP-IP implementations 
perform (memory to memory, not disk to disk, etc) and various platforms?

Any help in this matter would be appreciated..

P.S. How would you rate 500KB/sec?

-Chris Patti
feoh@gnu.ai.mit.edu
chrisp@ncm.interlan.com

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 1992 20:12:08 GMT
From:      rsivaram@vela.acs.oakland.edu (Siva)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Dos Equivalent for gethostbyname()...

Dear Netters,
	I have written some building blocks for developing an NFS
client. They are on UNIX system. I want to port them to DOS
preferably using Turbo C because my ultimate objective is to build
the client on DOS.  Is there any library function
equivalent to gethostbyname() available on DOS ? Any pointers
will be greatly appreciated.
Thanks
-Siva
-- 



-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 92 21:51:57 GMT
From:      terry@cs.weber.edu (A Wizard of Earth C)
To:        comp.unix.ultrix,comp.unix.bsd,comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: SL/IP and routing under Ultrix 4.2 on VaxStation 3100

In article <1992Nov22.192130.1720@mjbtn.jobsoft.com> root@mjbtn.jobsoft.com (Mark J. Bailey [ADMIN]) writes:
>Hello,
>
>We are trying to figure out a problem and maybe some of you can help us.
>
>what we are trying to do is use SL/IP on a VaxStation 3100 running Ultrix
>4.2 to connect a 286-AT running an amateur radio tcp/ip software package
>called (KA9Q).  Getting the link up is no problem.  The 286-AT machine is
>then linked on the radio interface (ax0) to a wireless TCP/IP network around
>our region on the amateur radio bands.  The VaxStation is called 'turing'
>and its IP address is 161.45.1.14.  It is on a LAN of other Ultrix 4.2
>workstations connected via thinnet ethernet.  There are no subnets present.
>The entire ethernet is one network.  The 286-AT is called 'w4efq' and has
>an IP address of '161.45.63.4'.

[ ... ]

>What our problem is, is that we cannot seem to get other workstations
>on the ethernet to be able to access w4efq via the slip interface on turing
>*UNLESS* we specifically add a route to the workstation in particular
>that says
>route add 161.45.63.4 161.45.1.14 1
>ie, w4efq is via gateway turing.  Then it works great!?!?  w4efq has no 
>problem replying to say, 161.45.1.1, and 161.45.1.1 will reach w4efq as long as we manually add the route above.  what we want it to somehow have turing
>be "listening" for w4efq's address and say "ah, i know what to do with
>this one" and send it up the sl/ip line.  We don't want to have to go to 
>each and every workstation and add routes by hand.  likewise, it seems to
>me that one should not have to update every node in a network if you use
>sl/ip to "bridge" another network in (as in my case); attaching it to just
>one node in the main network (in my case, turing).  Maybe I am wrong.  :-)
>I know I am confused!  :-)

1)	a)	"OPTION GATEWAY" in your 3100's config file (don't know
		if Ultrix supports this) and rebuild the kernel to allow
		routing between subnets.
	-OR-
	b)	Get (and run) gated (from gatekeeper.dec.com, etc.).

2)	a)	Subnet your wires to give a netmask of 255.255.255.0 (or
		anything else you choose to get 161.45.63.x and 
		161.45.1.x off the same wire.

3)	a)	There is a default host doing the routing for 161.45.x.x;
		tell IT the route to 161.45.63.x is through 161.45.1.14.
		This will make the other hosts send packets to the
		"unknown" 63 wire to the default hosts, which will
		forward them to 161.45.1.14, which is your gateway to
		the 161.45.63.x subnet.

4)	a)	Default the routing for the NET 161.45.63.x to the slip
		link; this will avoid a routing loop which you might
		otherwise have if someone tries to talk to 161.45.63.9
		(or some other nonexistant host) on the 63 net; you
		don't want these packets going back to your default router
		for the 161.45.x.x wire.  Alternately, self designate as
		the 161.45.63.x router and specify a single host entry
		for the SL/IP.

Topologically:

	161.45.x.x ----+------------------------+-------------
	domain	       |			|
		       |			|
		    default		   161.45.1.x
		    domain		     subnet (OPTIONAL)
		    router		     router
						|
						|
	161.45.1.x -----+-----------------------+-----
	subnet		|
			|
		161.45.1.14 host /
		161.45.63.x gateway
			|
			|
	161.45.63.x ----+---------------+-----------------
	gated				|
	subnet			161.45.63.4
	(SINGLE ADDR)		SL/IP host

This basically works for us (with gated) using a MVAX II w/Ultrix.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 00:13:51 GMT
From:      karl@empirical.com (Karl Auerbach)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Domain Name Service Deficiencies

In article <4285@bcstec.ca.boeing.com> tld5032@bcstec.ca.boeing.com (Terry Davis) writes:
>From: tld5032@bcstec.ca.boeing.com (Terry Davis)
>Subject: Domain Name Service Deficiencies
 
>        11) In addition to  DNS, the  resolver  routines  "gethostbyname"
>        and "gethostbyaddr" need  some extensive enhancements for life in
>        the network environment.  Some form of short lived caching  needs
>        to be provided, probably a most recent "10" lookups would be more
>        than adequate for anything except servers.

My PC-based DNS resolver implements a local name cache which it uses
before ever hitting the disk or the network.  Seems to work OK for my PC 
applications.

			--karl--

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 03:21:04 GMT
From:      davis@unidata.ucar.edu (Glenn P. Davis)
To:        comp.protocols.tcp-ip
Subject:   Network Time Protocol on on SunOS 5.0 ?

Yo. I have been trying to bring up xntp3 on SunOS 5.0 aka
Solaris 2.0. The main problem is the server, xntpd.
I have been moderately successful using /usr/ucb/cc and -DNOKMEM. 
At this point it runs but doesn't hear other guys.

Sigh. Has anyone out there gotten any form of Network Time Protocol
service running on SunOS 5.0?

-glenn

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 03:56:08 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <1992Nov23.195956.10971@mintaka.lcs.mit.edu>, feoh@hal.gnu.ai.mit.edu (Chris Patti) writes:
> 
> Hello.
> 
> Does anyone have any raw numbers on how fast various TCP-IP implementations 
> perform (memory to memory, not disk to disk, etc) and various platforms?
> 
> Any help in this matter would be appreciated..
> 
> P.S. How would you rate 500KB/sec?


That depends on the medium.
Over a modem 500KByte/sec would be amazing.
On an idle FDDI ring, it would be ridiculous.


Vernon Schryver,  vjs@sgi.com


P.S.  Over ethernet 500KB/s would be poor for a modern workstation, but
    common for a PC.  As measured by `ttcp`.  Ftp ttcp source from
    brl.mil or sgi.com

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 04:42:07 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   looking for Daniel D. Lanciani

I need to talk to Daniel Lanciani about his odipkt.com driver and the 
copyright on it.  I have modifyed it and renamed it but have kept his
copyright notices intact.  I would also like to know if my modifications
are covered under his copyright or if I need to add one of my own.

This is all new to me and any advice would be helpful.

Ben James
ben@datacomm.ucc.okstate.edu

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1992 17:10 MST
From:      jms@carat.arizona.edu (A virtually vegetal non-entity)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for multicast mailing lists

In article <142229@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes...
> 
>  I'm looking for mailing lists dealing with multicast topics.  

Multicast@Arizona.EDU

The multicast mailing list has been set up for discussion of multicast
and broadcast issues in an OSI network environment.  In the current
CCITT recommendations and ISO standards, there is little or no mention
of multicast capability.  However, there is work in this area in
other environments.

The goal of this mailing list is to facilitate discussion on the
following topics:

- what can we learn from existing multicast and broadcast work in other
environments (local area networks, TCP/IP Internets, XTP, ST-II, etc.)

- what can we do to facilitate quality international standards (ISO and
CCITT, especially) for multicast data transmission

- what can we say about the issues listed below?
        - application level interfaces and requirements
        - management
        - security
        - transport level
        - network level
        - network/transport interworking
        - connection-oriented/connection-less interworking
        - LAN/WAN interworking

To subscribe to the multicast mailing list, send a message to
Multicast-Request@Arizona.EDU with your full name and preferred
electronic mail address.

Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data)
BITNET: jms@Arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms
Yow!  Are we laid back yet?

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 17:29:42 EST
From:      esiewick@pbs.org
To:        comp.protocols.tcp-ip
Subject:   Terminal Server Recommendations?

Hello,

This is a solicitation for opinions concerning TCP/IP-capable terminal
servers  (It could also be a sad story about vendor vaporware).  

PBS is attempting to connect a large number (several thousand) sites on
one data network via VSAT satellite.  At the satellite-remote site (300+)
level we need to connect modems to terminal servers to data servers to 
satellite communications equipment.  All is going fine except the terminal 
server we've begun the project with cannot/does not perform SLIP and UUCP 
properly, at least not concurrently.  Yes, these would seem to be very 
simple, common tasks expected of any such product in the marketplace.  The 
vendor, not to be named publicly here, has rewritten their operating system 
several times for us.  Today's offering was even worse than the last.  And 
yes, we THOUGHT we'd provided an adequately exhaustive test of the product.
So we now possess a few of these dogs.  We don't need any more of them. 

Enough of the crying.  We need sound technical opinions on terminal 
servers.  Of particular interest are:

1:	the ease with which a single line can be used to configure itself 
	for SLIP or PPP; 

2:	robustness & technical accuracy of its implementation of SLIP, PPP
	and UUCP;

3:	remote management capabilities;

4:	cost-effectiveness;

Suggestions for sound alternatives to terminal servers are also requested.

Please respond via mail.  I'll summarize and post.  

Thank you for any and all help.


Edward Siewick

Public Broadcasting Service
1320 Braddock Place
Alexandria, VA  22314

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 17:34:15 EST
From:      esiewick@pbs.org
To:        comp.protocols.tcp-ip
Subject:   Terminal Server Recommendations?

Hello,

This is a solicitation for opinions concerning TCP/IP-capable terminal
servers  (It could also be a sad story about vendor vaporware).  

PBS is attempting to connect a large number (several thousand) sites on
one data network via VSAT satellite.  At the satellite-remote site (300+)
level we need to connect modems to terminal servers to data servers to 
satellite communications equipment.  All is going fine except the terminal 
server we've begun the project with cannot/does not perform SLIP and Telnet 
properly, at least not concurrently.  Yes, these would seem to be very 
simple, common tasks expected of any such product in the marketplace.  The 
vendor, not to be named publicly here, has rewritten their operating system 
several times for us.  Today's offering was even worse than the last.  And 
yes, we THOUGHT we'd provided an adequately exhaustive test of the product.
So we now possess a few of these dogs.  We don't need any more of them. 

Enough of the crying.  We need sound technical opinions on terminal 
servers.  Of particular interest are:

1:	the ease with which a single line can be used to configure itself 
	for SLIP or PPP; 

2:	robustness & technical accuracy of its implementation of SLIP, PPP
	and Telnet;

3:	remote management capabilities;

4:	cost-effectiveness;

Suggestions for sound alternatives to terminal servers are also requested.

Please respond via mail.  I'll summarize and post.  

Thank you for any and all help.


Edward Siewick

Public Broadcasting Service
1320 Braddock Place
Alexandria, VA  22314

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 12:55:58 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   NSFNet goes to hell..

After watching the NSFnet almost goto pieces in the last hour
or so, I'd like to know if there is any way 'outsiders' can get
info on when upgrades/maintainence is planned or even fault reports
are sent.  Someone suggested "nsr" to me but that seems to be an
"in-house" list only.  Are there any other offerings or are those
who use/rely on the network expected to put up with the route
between A and B changing every 5 minutes ?  (Surprisingly not all
network kernels/programs can handle what goes on and this results
in interruptions for almost anything which uses TCP).

This is a sample traceroute from not long ago:

 5  arc2.nsn.nasa.gov (132.160.240.1)  592 ms  576 ms  597 ms
 6  ARC1.NSN.NASA.GOV (192.100.12.1)  597 ms  599 ms  599 ms
 7  Palo_Alto.CA.NSS.NSF.NET (192.52.195.254)  741 ms  710 ms  721 ms
 8  Palo_Alto.CA.NSS.NSF.NET (129.140.13.129)  797 ms  737 ms  722 ms
 9  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  710 ms  768 ms  740 ms
10  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15)  751 ms  706 ms  748 ms
11  Ann_Arbor.MI.NSS.NSF.NET (129.140.17.78)  732 ms Ann_Arbor.MI.NSS.NSF.NET (1
29.140.17.14)  707 ms Ann_Arbor.MI.NSS.NSF.NET (129.140.17.78)  726 ms
12  t3-2.cnss41.t3.nsf.net (140.222.41.3)  745 ms  761 ms  762 ms
13  t3-3.cnss40.t3.nsf.net (140.222.40.4)  798 ms  779 ms  822 ms
14  t3-2.cnss24.t3.nsf.net (140.222.24.3)  789 ms  814 ms  830 ms
15  t3-0.cnss80.t3.nsf.net (140.222.80.1)  727 ms  762 ms  737 ms

Usually its cnss8-cnss24-cnss80...%-/

darren

p.s. This isnt as rare as some people would have others belive, just
     mostly seems to happen when most of the USA is asleep and the
     rest of us are awake....well most of the time anyway...

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 14:35:34 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Maximum ports on a Router?

I am working on a strategy for developing a multiprorocol router network
for a large client in the healthcare sector.  (Protocols to be routed
include IP, DECnet Ph IV and IPX (with some ISO 8473 at some future point)).

The outline design looks like approx. 15 main nodes, connected in a route-
diverse "cartwheel" resilient network.  However, we will need at least one
link from each node to come into the central node (i.e the hub of the 
cartwheel).  We are planning to start with RIP and move to IntIS-IS at some 
future point).

The question is  -  does it make sense to have one big router with 14 or 15
WAN ports at the centre, or to split the load and have two 8-port routers
side-by-side, connected by an Ethernet segment? (or three 6-port routers...).

We are evaluating all main routers (inc. ACC, Cisco, Wellfleet, 3Com etc.).
It appears that most makes only support up to 8 ports (WAN+LAN).

What are the pros & cons of each approach?  Is there any alternative?

Will the two-routers side-by-side be more difficult to manage?

Will the routing tables cause us a problem?

What is the realistic maximum number of WAN ports for a router?

Does the protocol make a difference (ie 14 ports OK for IP, but not for IPX?)

TIA

Phil Royse

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

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 14:43:02 GMT
From:      billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

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

>After watching the NSFnet almost goto pieces in the last hour
>or so, I'd like to know if there is any way 'outsiders' can get
>info on when upgrades/maintainence is planned or even fault reports
>are sent.  Someone suggested "nsr" to me but that seems to be an
>"in-house" list only.  Are there any other offerings or are those
>who use/rely on the network expected to put up with the route
>between A and B changing every 5 minutes ?  (Surprisingly not all
>network kernels/programs can handle what goes on and this results
>in interruptions for almost anything which uses TCP).

It's called Dynamic Routing and this is the way it is supposed to work.
This is a design feature (and I don't mean bug).  The NSFnet backbone
load balances the traffic.  The switching does not necessarily mean
there has been an outage.

It isn't a matter of kernels/program can handling it or not handling.
IP software only receives packets with an original source address and
has no idea of how the packet got there.  So if your kernels/programs
can tell, they are VERY, VERY, VERY broken.   Traceroute does some pretty
strange things to figure out the route that involves many packets being
sent.

There is nothing wrong with the NSFNET.  It's operating as planned.  If
you think dynamic routing is causing you a problem, I highly suggest that
you start by taking a look at IP packet definitions and realize the route
taken is not part of the information being carried in the packet.


Billy Barron, VAX/UNIX Systems Manager, University of North Texas
billy@unt.edu, billy@untvax.bitnet, THENET: NTVAX::BILLY

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 15:34:15 GMT
From:      bob1@cos.com (Bob Blackshaw)
To:        comp.dcom.lans.ethernet,comp.dcom.isdn,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: remote tcp/ip LAN access ideas

In <1992Nov23.192937.23672@advtech.uswest.com> huntting@advtech.uswest.com (Brad Huntting) writes:

>In article <722011367snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>>In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes:
 
>>   Watch out.  Telecommuting may be just around the bend for your
>>   company.  Don't let it catch you asleep at the wheel.
 
>>Holy shit, Steve, is NYNEX just figuring this out?!?!???
 
>>Sorry for the gratuitious flamage, but maybe that's what the baby
>>bells need?
 
>Yup.  Until just a few months ago my supervisor (at U S WEST) was
>unable to fathom telecomuting.  He used a Mac, and might have been able
>to login to a unix machine if he had a system administrator on the
>phone with him.  When I brought up the subject of working at home with
>him, I got a vacant stare as if I had just asked him "I'm going to die
>tomarrow and was wondering if I could keep working from beyond the
>grave".
 
>I'm fortunate now to have a new supervisor who understands that I dont
>have to be in the building to work.  (Of course she lives several miles
>up Boulder canyon and is probably snowed in herself today).
 
>There is hope though...  At least there is a concensis (now that ATT is
>out of the picture) that UUCP is not the ultimate answer to the worlds
>networking needs.  :-)


>brad

Telecommuting got a big play at TRIP '92, in fact there was a
delightful exchange during the Golden Splice ceremony. The
moderator, Dr. Robert Metcalfe was in a video conference with
some school children out in Los Angeles. One of the ISDN
applications she and her schoolmates had suggested was the
idea of work-at-home, i.e., telecommuting. Dr. Metcalfe asked
her how she would like having her parents at home all the time.
Her response was that it would be neat and would bring families
closer together. The audience of sophisticated executives and
media people simply burst into applause. As they say "Out of
the mouths of babes..."

The second day had several speakers who have already implemented
telecommuting to good effect. It seems to be an idea whose time
has come, at last.

Bob.


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 15:38:17 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc
Subject:   Looking for multicast mailing lists

NOTE:
    Please send all replies directly to me.  I'll summarize the results
    back to these groups.  Please indicate if you don't want your name
    or comments used in my summary.

  I'm looking for mailing lists dealing with multicast topics.  I'm
interested in TCP/IP in particular, but am interested in multicasting
issues in general.  I know about the ISIS news group and am following
that already.

  Thanks for your time and attention!

Casey

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 18:09:08 GMT
From:      ldh@svl.cdc.com (Lawrence D. Hare)
To:        comp.protocols.tcp-ip
Subject:   Connection comes up halfway and drives me nuts,

This one is driving me nuts.. If anyone has any idea as to what is going
on I would be really happy. This is the set up.

A Mac application that talks to a specific server on a variety of Unix
platforms. It works fine on everything. Part of this application's
function is to perform file transfers, it uses ftp. This works on ALL
configurations except ONE! What happens on this one is as follows:

The application is connected and happy. It wants to perform a file
transfer so it establishes a connection to the FTP well-known-port using
MacTCP. The connection is created and I go for an ActiveOpen. This
returns mac error -23015 which, translated, means: The connection came up
halfway and then failed.

Why why why WHY!!!!!!!!! If I run other mac applications that use ftp
protocols it works all right. Is there some negotiation going on between
the TCP peers that is failing? Is there something at the UNIX end? Is
there something I should tell someone?

Aaaaaarrrrrgh.

I am posting this to comp.sys.mac.comm, comp.unix.programmer,
comp.unix.admin and comp.unix.bsd. Any and all help is greatly
appreciated.

Thanks

--
Lawrence D. Hare       Control Data - Silicon Valley Operations
Consultant             Voice: (408) 496 4339 - C/N [234] 4339
ldh@svl.cdc.com        Mail: SVLa60  FAX: (408) 496-4106

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 18:40:30 GMT
From:      stewart@daffy.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet firewall help?

In article <1992Nov23.130546.7563@atlastele.com>, brians@atlastele.com (Brian Sheets) writes:
>
>Well here I sit with this new neato kean network stuff but, do to the nature
>of our company I cannot hook it up until I can assure that nobody will be 
>able to telnet or make other unauthorized entries into our system.
>
>So other that turning off telnetd does anyone have any suggestions??

There are commercially available firewalls providing rather
sophisticated mechanisms for access to various services
depending on source, destination, service, time, etc.  One
such product, Raptor Systems' Eagle Gateway, has a mailing
list at raptor@delmarva.com; subscription requests should be
sent to raptor-request@delmarva.com.  There are also various
documents on the Eagle Gateway in particular, and network
security in general, at ftp.delmarva.com (138.39.7.10) in
pub/raptor.

Good luck.

/jws

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 18:56:55 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Network print spoolers? Parallel ports?

We have a network of Sun workstations that we want to stick a parallel
port dot matrix printer on for draft quality screen dumps. Because it's
such a high data volume, we don't want to mess with a serial printer.

Sun's parallel port is O($1000)!

Next solution is to use a standalone printer server or terminal server
with a parallel port. This would simplify administration and dependence
on some particular workstation, too. What sort of products should we be
looking at, and what sort of prices?
-- 
 Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 18:57:22 GMT
From:      msp@mbunix.mitre.org (Panock)
To:        comp.protocols.tcp-ip
Subject:   secure OSPF


I am interested in OSPF, in particular implementations that implement 
IP security option(CIPSO and/or RIPSO). Please send email replies to 
at this address

msp@mbunix.mitre.org

                            thanks

                           Marybeth Panock
                           MITRE Corp.
                           617-271-8567



-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 18:59:36 GMT
From:      srao@hpindda.cup.hp.com (Srinivasa Rao)
To:        comp.protocols.tcp-ip
Subject:   Standard reply string for 'PWD' command in ftp protocol



Dear netters

I am writing a new ftp client. In my ftp client, I need to know
the present working directory which I use it for further processing in the
program.

What string does the ftpd returns for the command 'PWD'?

At present I assumed that all ftpd's return the following reply
for the command 'PWD'

<Three digit code><space>"<dirname>"<space>commentary

Is above code is valid always in all implementations?

I have gone through the RFC959 and I did not get any standard reply for 'PWD'.

For MKD comands, the above reply seems to be standardised.

Any help on above problem is greatly appreciated.

Thankyou



-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 20:37:46 GMT
From:      madhu@cbnewsf.cb.att.com (madhu.shekhar)
To:        comp.protocols.tcp-ip
Subject:   Where are TCP/IP sources with MIB-II ?


Please help me with site info on where I could 
find public domain TCP/IP source with MIB-II.

Please e'mail to
     madhu@mt747.att.com

Thanks in advance

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 20:47:45 GMT
From:      stewart@daffy.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPAnet means?

In article <rhughes.1.0@UCSD> rhughes@UCSD (Richard J. Hughes) writes:
>The title says it all.  What does the "ARPA" in ARPAnet stand for?  Would 
>some kind soul please let me know.

Advanced Research Projects Agency.  Actually, the name comes
from an agency of the Department of Defense -- the Defense
Advanced Research Projects Agency.  I believe its network was
called ARPANET (rather than DARPANET) purely for reasons of
political-correctness.

/jws

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 20:55:21 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   anyone using tcpmux?

Is anyone using the tcpmux protocol?  Do any vendors rely on it for
their own standard applications?

Reply by mail, please.

		--Steve Bellovin

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 92 21:59:04 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPAnet means?

ARPA stands for Advanced Research Projects Agency.  This is an agency
set up within the US Department of Defense after the USSR launched
Sputnik (ca 1956); its mission was to make sure the USA was not
technologically surprised again.  ARPA funded a great deal of basic and
applied research in many fields, including computation.  In the late 70s
or early 80s the agency was renamed DARPA (Defense Advanced Research
Projects Agency).

    __   
   /  | /\                  Alex McKenzie
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1992 22:43:16 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPAnet means?

In article <rhughes.1.0@UCSD> rhughes@UCSD (Richard J. Hughes) writes:
>The title says it all.  What does the "ARPA" in ARPAnet stand for?  Would 
>some kind soul please let me know.

Advanced Research Projects Agency, the previous name of DARPA (the D stands
for Defense -- the name was changed to emphasize that the agency is a part
of the DOD and should be stressing military applications rather than pure
research).  DARPA provided most of the original funding for the original
ARPAnet.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 1992 22:54:40 GMT
From:      gdo@aloft.att.com (Glenn O'Donnell)
To:        comp.protocols.tcp-ip
Subject:   How do I Monitor Sun Outgoing Packets?

When monitoring packets using etherfind, NetMetrix, etc., I can't see traffic
leaving the Sun doing the monitoring.  I've been told it's a bug in Sun's NIT
interface.  Can anybody shed light on this?  Is there a patch/workaround?

Thanks in advance.

Glenn O'Donnell
AT&T Bell Laboratories
Allentown, PA

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 00:23:38 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager) writes:

>avalon@coombs.anu.edu.au (Darren Reed) writes:
 
>>After watching the NSFnet almost goto pieces in the last hour
>>or so, I'd like to know if there is any way 'outsiders' can get
>>info on when upgrades/maintainence is planned or even fault reports
>>are sent.  Someone suggested "nsr" to me but that seems to be an
>>"in-house" list only.  Are there any other offerings or are those
>>who use/rely on the network expected to put up with the route
>>between A and B changing every 5 minutes ?  (Surprisingly not all
>>network kernels/programs can handle what goes on and this results
>>in interruptions for almost anything which uses TCP).
 
>It's called Dynamic Routing and this is the way it is supposed to work.
>This is a design feature (and I don't mean bug).  The NSFnet backbone
>load balances the traffic.  The switching does not necessarily mean
>there has been an outage.
 
>It isn't a matter of kernels/program can handling it or not handling.
>IP software only receives packets with an original source address and
>has no idea of how the packet got there.  So if your kernels/programs
>can tell, they are VERY, VERY, VERY broken.   Traceroute does some pretty
>strange things to figure out the route that involves many packets being
>sent.

Yes, I know how/why traceroute works and how dynamic routing with IP
is supposed to work, but why then, does a route change always spell
death for most TCP connections that are running over the changing
route ?

My guess is that somewhere, "unreachable" packets are being sent
back to hosts by some router while the route is changing - does
anyone have any evidence of the what goes on during a route change
or why connections always seem to die ?

Darren.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 01:23:40 GMT
From:      Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
To:        comp.protocols.tcp-ip, Darren Reed <avalon@coombs.anu.edu.au>
Subject:   Re: NSFNet goes to hell..

Darren -

     If your TCP applications break because you get an ICMP Network
(or Host) Unreachable then they are very very broken.  Unfortunately,
this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several
years ago thought this would be a useful `feature.'  A lot of people
have been nagging various vendors to get this fixed (I take credit for
getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this
bug seems to have been squished in the US.

     A fix is below.  Of course, neither I nor UW NDC take any
responsibility for its accuracy or validity on your system, so be sure
to verify that it is valid before applying it.

Mark Crispin
University of Washington
Networks and Distributed Computing


If you don't have sources, use adb to patch /vmunix to set the 8th and
9th offset of the u_char array inetctlerrmap to 0.

inetctlerrmap (defined in ip_input.c) maps the generic error types
from protosw.h to error numbers from errno.h.  Offsets 8 and 9 are
(protosw.h):

#define	PRC_UNREACH_NET		8	/* no route to network */
#define	PRC_UNREACH_HOST	9	/* no route to host */

which are mapped repsectively to (errno.h):

#define	ENETUNREACH	51		/* Network is unreachable */
#define	EHOSTUNREACH	65		/* No route to host */

Entries in that array which are 0 do not cause user errors.  So, this
effectively deletes those errors.

If you have sources, you can do better.  The patch causes 4.3 to
ignore ICMP unreachable errors in all cases, something that one
probably does not want to do.  For instance, you probably *much*
prefer to have telnet attempts abort quickly with a "network
unreachable" than with a "connection timed out" some 60 seconds later.
On the other hand, once a connection has been established, you prefer
that stray ICMP errors not break a connection.  Moreover, nuking ICMP
unreachable errors weakens utilities like ping that understand such
messages.  One of ping's useful features is the printing of ICMP
errors it receives.

The following patch to tcp_notify() treats ICMP unreachable errors as
before, except that they won't break established connections.

*** /tmp/,RCSt1025442	Sat Feb 25 13:46:58 1989
--- /tmp/,RCSt2025442	Sat Feb 25 13:46:59 1989
***************
*** 258,264 ****
  tcp_notify(inp)
  	register struct inpcb *inp;
  {
!
  	wakeup((caddr_t) &inp->inp_socket->so_timeo);
  	sorwakeup(inp->inp_socket);
  	sowwakeup(inp->inp_socket);
--- 258,271 ----
  tcp_notify(inp)
  	register struct inpcb *inp;
  {
! 	if (inp->inp_socket->so_state != SS_ISCONNECTING) {
! 	        register int error = inp->inp_socket->so_error;
! 	        if ((error == EHOSTUNREACH) || (error == ENETUNREACH)
! 		     || (error == EHOSTDOWN)) {
! 		        inp->inp_socket->so_error = 0; /* clear error */
! 			return;
! 		}
! 	}
  	wakeup((caddr_t) &inp->inp_socket->so_timeo);
  	sorwakeup(inp->inp_socket);
  	sowwakeup(inp->inp_socket);


-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 02:15:34 GMT
From:      hsu@cs.hut.fi (Heikki Suonsivu)
To:        comp.compression,comp.protocols.tcp-ip
Subject:   Wanted: Fast compression routine for PC


I would like to add compression to a ppp (or slip) packet driver.  Maybe
someone has done this already (freely available code), if yes, I would like
to know about it?

I would like to get a fast compression routine for a pc, something like

compress(char *input, int size, char *output, int *out_size);
uncompress(char *input, int buffer_size, char *output, int *out_size);

- I would prefer optimized assembly, but simple C code is ok.  I'm ready to
do some work myself, just checking out if there would be something I could
drop in easily.
- The level of compression is not very important, as long as it does
something reasonable.
- The routine should be simple and take little memory.
- Speed is an issue.  >10k a second on an 286@8MHz would be nice, but I
could settle for 386@16MHz if this cannot be achieved.
- The code should be good in handling corrupted data, it must not crash if
it gets trash as input, but getting corrupted output from corrupted input
is ok.

Any code I use or write for this will be freely available (probably GPL).

-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi  +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 02:30:30 GMT
From:      rale1@cs.aukuni.ac.nz (Ross4Douglas        Alexander      )
To:        comp.protocols.tcp-ip
Subject:   ARPAnet meaning

ARPAnet is the acronym for Advanced Research Project Acency Network.

ARPA was (is?) one of the agencies within the DoD which dealing with
funding reseach for the military.

NB:  ARPANet doesn't actually exist any longer.  It was originally a set
of 56Kbps leased lines.  It has been replaced by NREN, the NSF backbone
and MILnet.

Ross Alexander
Computer Science
Auckland University
New Zealand

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 03:32:20 GMT
From:      johnmac@fawlty.towers.oz.au (John MacLean)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP, Windows 3.1, and Mounted File Systems

What options are available to have file systems mounted under MS-Windows 3.1,
from a UNIX box, and having TCP/IP active simultaneously?

I know this can be done using Novell, but are there any NFS options, or
anything else?

John MacLean.
-- 
This net: johnmac@fawlty.towers.oz.au                   Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac             Fax:   +61 2 427 7072
Snail:    Tower Technology, 1 Apollo Pl,                Home:  +61 2 449 5930
          Lane Cove, NSW 2066, Australia.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 04:06:31 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.protocols.tcp-ip
Subject:   How do you request that new Telnet option numbers be assigned?

What is the method for requesting a new Telnet option number be assigned?  I
know that RFCs are collected somewhere, and made available to the Internet
community, and after the comments are submitted the option number is then
"assigned".  But where does one submit an RFC, and are there guidelines
available anywhere specifying the form and method of this submission?

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@isca.uiowa.edu       |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 04:13:50 GMT
From:      alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Need help with TCP/IP on ISC 3.0

Hi there!  I have ISC 3.0 (with the first patch disk) running on
an InfoPro 486/33 motherboard (OPTi chipset) with 16MB of RAM and
an Adaptec 1542B.  I installed the TCP/IP package, with all prereqs
and configured the kernel for a Novell NE2000 ethernet board.  The
config does not conflict with anything else in the kernel.

When the machine boots, I can see that the NE2000 is recognized
because a line is printed showing the board's Ethernet ID, etc.
However, I subsequently get the following messages:

	cp: bad copy to /dev/netsched
	tcp timer failed

I then login and try to finger one of my hosts, slave.rct.com.  I
get:

	[slave.rct.com]connect: Protocol driver not attached

I'd appreciate it if somebody could tell me what the heck is going
on, and how to fix it.

Thanks!

alan l. batongbacal
frustrated tcp/ip'er

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 05:30:40 GMT
From:      panos@burton.cs.colorado.edu (Panos Tsirigotis)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

In article <MS-C.722654620.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>Darren -
>
>     If your TCP applications break because you get an ICMP Network
>(or Host) Unreachable then they are very very broken.  Unfortunately,
>this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several
>years ago thought this would be a useful `feature.'  A lot of people
>have been nagging various vendors to get this fixed (I take credit for
>getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this
>bug seems to have been squished in the US.
>
>     A fix is below.  Of course, neither I nor UW NDC take any
>responsibility for its accuracy or validity on your system, so be sure
>to verify that it is valid before applying it.
>
>Mark Crispin
>University of Washington
>Networks and Distributed Computing
>
>
>If you don't have sources, use adb to patch /vmunix to set the 8th and
>9th offset of the u_char array inetctlerrmap to 0.
>
>inetctlerrmap (defined in ip_input.c) maps the generic error types
>from protosw.h to error numbers from errno.h.  Offsets 8 and 9 are
>(protosw.h):
>
>#define	PRC_UNREACH_NET		8	/* no route to network */
>#define	PRC_UNREACH_HOST	9	/* no route to host */
>
>which are mapped repsectively to (errno.h):
>
>#define	ENETUNREACH	51		/* Network is unreachable */
>#define	EHOSTUNREACH	65		/* No route to host */
>
>Entries in that array which are 0 do not cause user errors.  So, this
>effectively deletes those errors.
>
>If you have sources, you can do better.  The patch causes 4.3 to
>ignore ICMP unreachable errors in all cases, something that one
>probably does not want to do.  For instance, you probably *much*
>prefer to have telnet attempts abort quickly with a "network
>unreachable" than with a "connection timed out" some 60 seconds later.
>On the other hand, once a connection has been established, you prefer
>that stray ICMP errors not break a connection.  Moreover, nuking ICMP
>unreachable errors weakens utilities like ping that understand such
>messages.  One of ping's useful features is the printing of ICMP
>errors it receives.
>
>The following patch to tcp_notify() treats ICMP unreachable errors as
>before, except that they won't break established connections.
>
>*** /tmp/,RCSt1025442	Sat Feb 25 13:46:58 1989
>--- /tmp/,RCSt2025442	Sat Feb 25 13:46:59 1989
>***************
>*** 258,264 ****
>  tcp_notify(inp)
>  	register struct inpcb *inp;
>  {
>!
>  	wakeup((caddr_t) &inp->inp_socket->so_timeo);
>  	sorwakeup(inp->inp_socket);
>  	sowwakeup(inp->inp_socket);
>--- 258,271 ----
>  tcp_notify(inp)
>  	register struct inpcb *inp;
>  {
>! 	if (inp->inp_socket->so_state != SS_ISCONNECTING) {
>! 	        register int error = inp->inp_socket->so_error;
>! 	        if ((error == EHOSTUNREACH) || (error == ENETUNREACH)
>! 		     || (error == EHOSTDOWN)) {
>! 		        inp->inp_socket->so_error = 0; /* clear error */
>! 			return;
>! 		}
>! 	}
>  	wakeup((caddr_t) &inp->inp_socket->so_timeo);
>  	sorwakeup(inp->inp_socket);
>  	sowwakeup(inp->inp_socket);

The next thing to do is to replace the line
	if (inp->inp_socket->so_state != SS_ISCONNECTING) {
with
	if ( ! ( inp->inp_socket->so_state & SS_ISCONNECTING ) ) {

(hint: think about a socket with the non-blocking I/O flag set)

Panos

-- 
Panos Tsirigotis, CS grad                        
Pmail: Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309-0430
Email: panos@cs.colorado.edu

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 1992 14:01:09 -0500
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip,comp.sys.sun.hardware
Subject:   Finding a machine's ethernet hardware

(I need an answer for SunOS 4.1.x, but it would be nice if the answer
was portable to other brands of Unix.)

I'm writing a program in C that needs to find all the internet
addresses the current machine has.

I know the IOCTLs I have to use on the interface (through NIT) to get
the answer, but I don't know how to find out what interfaces the
machine has.  (i.e. le0 vs. ie0, etc.)

All the example programs in AnswerBook and SunSolve have the user
specify the interface on the command line.

Any tips will be appreciated,

Tom

P.S.  I can't open a pipe to "ifconfig -a", sorry!
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
Reality is stranger than fiction #943247:  The IRS granted
ANS approval as a 501c3 "charity" on September 14, 1992.

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 09:58:25 GMT
From:      mazzucch@ghost.dsi.unimi.it (massimo mazzucchi)
To:        comp.protocols.tcp-ip
Subject:   setup SLIP: info


Hi

I am Max from Milan Italy


I use to communication UNIXtoDOS 

FTP Software PC/TCP version 1.16pl4

i will know:

- exist a new version and it is a commercial program?  $? 

- for example if i have connect my pc with a serial port of 

 a modem in which way i can use command ftp correctly?( there

 are 2 file *.sys that i have place in Config.sys)

 - there 2 file IPCONFIG and IFCONFIG 
   
    in which way i must use them?

- in which way i must setup my modem?


    Thanks for your help

    Bye
--------------------------------------------------------------------------------
!  Massimo Mazzucchi                         address    e-mail                !
!  University of State                       mazzucch@ghost.dsi.unimi.it      !
!  Departement of Computer Science            149.132.2.1                     ! 
!  Via Comelico, 41 -  20133 MILAN ITALY                                      !
 -------------------------------------------------------------------------------

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 12:02:22 GMT
From:      steve@terminus.ericsson.se (Steve Reynolds)
To:        comp.protocols.tcp-ip
Subject:   header compression algorithms


I am interested in the Van Jacobsen header compression algorithm, but I am worried
about it's application over an unreliable medium.

I understand it to be a differences algorithm.

If this it the case, then how is recovery from a lost packet accomplished?

Does a lost packet imply that a TCP connection must be lost or time out before 
another may be established? ,or are certain TCP control packets sent uncompressed
to allow for resynchronisation?

If there are problems on unreliable networks - does anyone know of any other 
header compression algorithm (preferably code) which is applicable to this 
environment?


Thanks in advance

Steve



---------------------------------------------------
| Steve Reynolds                                  |
| Ericsson                                        |
| Leicester                                       |
| UK                                              |
| TEL:    +44 533 537534                          |
| EMAIL:  steve@terminus.ericsson.se              |
---------------------------------------------------

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 13:50:26 GMT
From:      luigi@iet.unipi.it
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   BOOTP ROM problem

We are having problems with a BOOTP prom for WD8003 cards. The BOOTP
PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an
Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with
a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It
appears that the PC sends the bootp request, the host replies, the PC
receives the reply and then simply asks "Enter boot volume name: "
instead of getting the file via tftp. tftp seems to work on all of the
machines, without special configurations or permissions.
So which one of these is true ?

1) I didn't do something I should have on the host.
2) Ultrix 4.1 bootp replies differ from the ones produced by CMU bootpd
   (which is likely to be the source of AIX bootpd), and the latter
   are either buggy or non-recognized by B&W BOOTP ROM
3) there is some bug in the ROM code 

Of course I hope 1) is the right explaination. Any help from the net ?

	Thanks
	Luigi Rizzo
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56124 PISA (Italy)
fax: +39-50-568522
====================================================================

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 15:32:52 GMT
From:      sulistio@sutro.SFSU.EDU (Sulistio Muljadi)
To:        comp.protocols.tcp-ip
Subject:   Looking for networking tools...

I am not sure if this is the right newsgroup to post.. if not please let me
know..
I am looking for network tools (UNIX) to debug networking problem that
we have.  Preferable in the public domain area.   I heard sometihing about
traceroute...  is this a public domain tools ?
Thanks...
-- 
Mul			    |  Alt. address: sulistio@sutro.sfsu.edu
sulistio@futon.sfsu.edu	    |		     sulistio@sfsuvax1.sfsu.edu
#include "std/disclaimer.h" | NeXTmail ->    sarong!sulistio@cs.sfsu.edu 
>Genius is one per cent inspiration and ninety-nine per cent perspiration.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 16:28:19 GMT
From:      yppawlus@cyf-kr.edu.pl (Jerzy Pawlus)
To:        comp.protocols.tcp-ip
Subject:   3270 emulator under Unix?

Hi,

  Does anybody know the ftp location where I can find Emulator of IBM 3270
terminal running under Unix (preferably SunOS 4.1.1)

Jerzy Pawlus                      ACK CYFRONET, Krakow, Poland
Internet: yppawlus@cyf-kr.edu.pl

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 16:55:16 GMT
From:      rm72@prism.gatech.EDU (Bruce McCullough)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for networking tools...

>I am looking for network tools (UNIX) to debug networking problem that
>we have.  Preferable in the public domain area.   
I am also looking for the same but need any other kind of info on
TCP/IP as possible.  We have a new computer services specialist at work
who wants to learn about TCP/IP ( I'm new to the area myself).  



-- 
Robert B. McCullough-Computer Operations Tech.
Registrar Data Systems
Georgia Institute of Technology
Internet: rm72@prism.gatech.edu

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 18:08:30 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   FTP: Send 8 1K packets, then wait.....

I am analyzing some medical networks, and I see a common pattern in
large file transfers using FTP. Could someone tell me if this sounds
like a bsd4.2, or bsd4.3 implementation of TCP.

The sending system sends 8 1K packets. The delay is about 2
milliseconds between packets. The last packet has a "Push"
flag. An ack comes back. Then the sender waits a while, typically
40-100 milliseconds, and sends out 8 more packets. 

The outgoing WIN size is 8K. The receiving window is 24K. The network
is not causing a bottleneck.  The system is not using IP fragments,
nor large window sizes on the sends. This sounds like an early
implementation of TCP, on a slow CPU. Typically 84KB/sec over
ethernet. Any guesses on why it is so slow?
It might be a Sun 3 running SunOS 3.5. 

(This system is on the other coast. I'm analyzing the output of a
tcpdump file that was mailed to me.)


--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 18:17:17 GMT
From:      fred@maccs.dcss.mcmaster.ca (Fred Whiteside)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: BOOTP ROM problem

In <1992Nov25.135026.18329@cli.di.unipi.it>, luigi@iet.unipi.it writes:
>We are having problems with a BOOTP prom for WD8003 cards. The BOOTP
>PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an
>Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with
>a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It
>appears that the PC sends the bootp request, the host replies, the PC
>receives the reply and then simply asks "Enter boot volume name: "
>instead of getting the file via tftp. tftp seems to work on all of the
>machines, without special configurations or permissions.

	The error message that you are getting indicates that the BOOTP
code attempted to get the boot file, and was either given a "File not
Found" or an "Access denied" response.  You should check the permissions
on the file; tftp requires that the files be world-writable.  You
should also check to ensure that the file that you think is being
requested is in fact the file that is being requested.  The BOOTP code
asks for the file /bwboot/default.wd8003.  The actual location of this
file depends on whether the tftp daemon is being run in a chroot()ed
environment, in which case the actual location of the file will be
/xxx/bwboot/default.wd8003 where /xxx is the location that the tftp
server was chroot()ed from (likely run from).

	If you continue to have trouble, please feel free to send email
to tech@bws.com or support@bws.com.

Fred Whiteside
-- 
Fred Whiteside   Beame & Whiteside Software Ltd., Caledonia, Ontario
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 18:17:58 GMT
From:      luigi@iet.unipi.it
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: BOOTP ROM problem: SOLVED

In article <1992Nov25.135026.18329@cli.di.unipi.it> luigi@iet.unipi.it writes:

>We are having problems with a BOOTP prom for WD8003 cards. The BOOTP
>PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an
>Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with
>a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It

Well, the problem has been solved now, at least with 386bsd (and thus I
think it will work with AIX as well, given the symptoms). But a few words of
explaination might help other people with the same problem:

>appears that the PC sends the bootp request, the host replies, the PC
>receives the reply and then simply asks "Enter boot volume name: "
>instead of getting the file via tftp. tftp seems to work on all of the
>machines, without special configurations or permissions.
>So which one of these is true ?
>
>1) I didn't do something I should have on the host.
>2) Ultrix 4.1 bootp replies differ from the ones produced by CMU bootpd
>   (which is likely to be the source of AIX bootpd), and the latter
>   are either buggy or non-recognized by B&W BOOTP ROM
>3) there is some bug in the ROM code 
>
>Of course I hope 1) is the right explaination. Any help from the net ?

1) is true, 2) is (more or less) false,  3) is (more or less) false. To
be precise, the problem has nothing to do with bootpd, but with tftpd.
The version of tftpd on 386bsd (and probably on AIX 3.2) will not
prepend anything to the pathnames of the requested files. Thus, even if
I specify something like 

		tftpd /mytftpdirectory

in /etc/inetd.conf or its equivalent for AIX, requests for
/bwboot/default.wd8003 will look for the absolute pathname. BTW, this
tftpd will not send files which are not in the trees specified as
parameters to tftpd.

On Ultrix 4.1 instead, the above situation would cause tftpd to look for
/mytftpdirectory/bwboot/default.wd8003 and to send the file as
requested. This is also what B&W documentation says:

	The file "default.wd8003" must be created in the directory "bwboot"
	which is a subdirectory of the tftpd's working directory.  See the file
	"default.set" about the make up of the "default.wd8003" file. For 3C501
	cards substitute "default.3c501" for "default.

and is the reason why things did work fine on Ultrix 4.1 but not on the
other, newer machines. So, the bug is mainly in the documentation.
Oh well, as a fallout of all this, now at least I have a working bootpd
under 386bsd...

	Thanks for the interest
	Luigi Rizzo
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56124 PISA (Italy)
fax: +39-50-568522
====================================================================

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 19:02:48 GMT
From:      Scott Brim <swb1@cornell.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast Routers (was Re: NIS broadcasts over IP subnets)

In article <sii7sjk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

   Do Wellfleet, Cisco, or others now do the right things when they see a
   class D address?  Do they forward such IP packets?

As far as I know only Proteon and SGI (a good router company) do the
right thing with class D packets.  What could the others do?  They don't
have a routing protocol.

   As far as I can tell, the router vendors have been dragging their feet
   vigorously on any kind of multicast routing for at least 4 years.  The
   router vendors have shown more enthusiasm for PPP, despite the danger
   PPP represents to their locked-in customer bases.

Right.  It's a chicken and egg problem, since router vendors are
demand-driven.  I believe this is going to change now relatively rapidly
since the workstation vendors are boosting multimedia and multicasting
is the natural extension.  We've distributed prototypes of our Mac
videoconferencing software with hardly any features at all, for example,
and we get impassioned pleas for multicast versions all the time.

							Scott
							

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 21:19:26 GMT
From:      wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   faster SLIP/PPP

It appears from my experimentation and from what I have seen here on
the net that one significant component of SLIP/PPP packet delays is
the delay caused by the v.42/v.42bis packetization.  The modems appear
to have to accumulate and "bless" the whole v.42/v.42bis packet before
the packet is sent on.  This adds another delay into the SLIP cycle.

Has anyone experimented with using a synchronous link between the
modems?  What sort of delays can one expect between the sync rs-232
data at one modems end and the sync data at the other?  Will the delay
be on the order of bit-times (eg. 1-2 milliseconds) or will the modems
impose a much larger delay, but buffering/delaying the bits anyway?

I am told that there is a bucket-brigade "data scrambler" that some
protocols use to randomize the data.  How long is this shifter?  Is it
possible to disable it (at both ends, of course) to get lower delays?

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 21:28:11 GMT
From:      alten@novell.com (Alex Alten)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting the ethernet address off (SMC)WD8003E Lan Cards

In article <1992Nov16.032841.7572@csc.canberra.edu.au> act@softserver.canberra.edu.au (Andrew Turner) writes:

>Would someone please e-mail(I'll on-forward if you too want same - e-mail
>requests) a code fragment assembler/pascal/C that will return the ethernet
>address from an WD8003E card.
 ..
>Renrut Werdna			Probable-Possible, my black hen,

You need the Packet Driver specs and the drivers (plus source).  
The specs should be available from FTP Software (anon.ftp.com?).
Version 1.09 is the latest, although I've only seen source for 1.08.
If you want to do a more in depth search for source archives, telnet 
into an Arhie server as user archie.  

Try 128.6.18.15 archie.rutgers.edu, 129.93.1.14 archie.unl.edu, 
132.206.2.3 archie.mcgill.ca (original), 139.130.4.6 archie.au, 
128.214.6.100 archie.funet.fi, 146.169.11.3 archie.doc.ic.ac.uk.

After you are in type:
set mailto <your domain or ip address here>
set sortby hostname
set search subcase
prog packet

You will get a long listing...

Then type:
mail

You will then receive several mail messages with your long listing
inside them.

Don't forget to logoff when you are done.

--

- Alex  (alten@na.novell.com)

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 21:34:30 GMT
From:      hole@cs.UAlberta.CA (Steve Hole)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need help on Tn3270 key sequences

Can anyone tell me the TN3270 key sequences for :
  SYSREQUEST, ATTENTION, CURSOR SELECT and ERASE INPUT.

I am trying to add these keys to the Tn3270 emulator of Beamme and Whiteside .
Please reply to 
            airon@ed.isac.ca

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 21:38:58 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

Mark Crispin (mrc@Tomobiki-Cho.CAC.Washington.EDU) wrote:
: Darren -
: 
:      If your TCP applications break because you get an ICMP Network
: (or Host) Unreachable then they are very very broken.  Unfortunately,
: this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several
: years ago thought this would be a useful `feature.'  A lot of people
: have been nagging various vendors to get this fixed (I take credit for
: getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this
: bug seems to have been squished in the US.
: 
It also has the problem that it enables a cracker to use this "feature"
to kill tcp connections.


-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 21:41:58 GMT
From:      jcobban@bnr.ca (Jim Cobban)
To:        comp.protocols.tcp-ip
Subject:   TN3101 or TN3151

Right next to my Sparc UNIX management workstation with all of its motif
windows, I have an IBM 3101.  That terminal is rarely used, but when it is
it is absolutely necessary, because it is the management console for the
CMOSS function on our 3745s.  The CMOSS ports on the 3745s are themselves
actually plugged into our network, as is the 3101, so we use the switching
capability of the network to connect the two.  I would just like to reclaim
the desk space which the 3101 is occupying, and integrate that function into
the management workstation software.  However to do so I need the ability to
emulate a block mode 3101.  Since aside from the 3745 and some protocol
converters there is no host support for block mode 3101 (for example UNIX
only has termcap support for character mode 3101), I have not been able to
lay my hands on any code to do this emulation.

Is there anybody out there who could point me at any product or code or
anything which does this function?


-- 
-------------------------------------------------------------------------------
Jim Cobban   |  jcobban@bnr.ca                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars5!jcobban         |  FAX:   (613) 763-2626

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 21:51:46 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPAnet means?

In article <1992Nov24.204745.2524@udel.edu> 
	stewart@daffy.cis.udel.edu (John Stewart) writes:

>Advanced Research Projects Agency.  Actually, the name comes
>from an agency of the Department of Defense -- the Defense
>Advanced Research Projects Agency.  I believe its network was
>called ARPANET (rather than DARPANET) purely for reasons of
>political-correctness.

Nope. Went through a name change, had 'DEE-FENSE' prepended.
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 22:49:56 GMT
From:      peter@palin.cc.monash.edu.au (Peter Hawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Pascal Waterloo TCP/IP library

jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) writes:

>In article <peter.722065275@palin.cc.monash.edu.au> peter@palin.cc.monash.edu.au (Peter Hawkins) writes:
 [...]
>>I got a copy of wattcp - a mixture of asm & C, and compiled it with
>>BCC, but unfortunately I couldn't link the C & pascal object files
>>without leaving unresolved externals - Borland's advice was that
[...]

>First get the Waterloo TCP/IP manual and make identical functions in
>C itself like psock_init(), psock_read() which calls sock_init()
>and sock_read() respectively. Declare psock_init() in the waterloo
>as 
>pascal psock_init()
>This directive is for linking your pascal routines correctly with
>the C function with correct function parameters. You have do the
>pascal psock_init()
>in one of the Waterloo TCP/IP source files itself. Build the Waterloo
>TCP/IP library. Now make a small pascal routine which calls psock_init()
>or psock_read() and compile and link it with the new library and all
>the support pascal and c libraries like cs.lib + maths.lib etc.,
>Wild guess - Might work ...

Thanks for the advice, however this is exactly what I had attempted
to do without success. The unresolved externals (etc) come from C
intrinsics etc and Borland says there is no way around this. The
Pascal prefix swaps the stack ordering of parameters to be consistent
with Pascal, and you can define psock_init() (etc) to be external, but
for some reason you can't define the contents of the bcc libraries
to be external - or at least, some parts of them remain unresolved.

Peter

PS - I have now got an alternative - someone suggested I get hold of
the PC Gopher source.
-- 
Peter Hawkins,
Assistant Lecturer, Computer Centre
Monash University, Australia
peter@palin.cc.monash.edu.au

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 92 23:16:10 GMT
From:      nevries@accucx.cc.ruu.nl (Nico E de Vries)
To:        comp.compression,comp.protocols.tcp-ip
Subject:   Re: Wanted: Fast compression routine for PC

In <HSU.92Nov25041528@cardhu.cs.hut.fi> hsu@cs.hut.fi (Heikki Suonsivu) writes:

>I would like to get a fast compression routine for a pc, something like
>compress(char *input, int size, char *output, int *out_size);
>uncompress(char *input, int buffer_size, char *output, int *out_size);

Look for the LZRW and the "Finish" compressor in my LDS_10 package.

>- I would prefer optimized assembly, but simple C code is ok.  I'm ready to
>do some work myself, just checking out if there would be something I could
>drop in easily.

The Finish compressor comes in both Intel machine code and C.

>- The routine should be simple and take little memory.

If the Finish compressor uses too much memory look for the included LZRW
compressor.

>- Speed is an issue.  >10k a second on an 286@8MHz would be nice, but I
>could settle for 386@16MHz if this cannot be achieved.

I suppose you mean >10k/second. Both Finish and LZRW should be able
to do this.

>- The code should be good in handling corrupted data, it must not crash if
>it gets trash as input, but getting corrupted output from corrupted input
>is ok.

Crashing is not likely. Some extra checks might be usefull.

>Any code I use or write for this will be freely available (probably GPL).

Both LZRW and Finish are free to use I believe. I don't know about
pattents etc. I believe someone patented LZRW. Look in the FAQ for
more info on that subject.

Locating the comp.compression ==> FAQ <== :
 * The FAQ is posted often to comp.compression and should also be available
   on news.answers as "comp.compression Frequently Asked Questions".
 * The FAQ is also available by anonymous ftp on rtfm.mit.edu [18.72.1.58]
   in directory /pub/usenet/news.answers/compression-faq, files part1 and part2.
 * If you don't have FTP access, you can get the FAQ by a mail
   server.  Send an email message to mail-server@pit-manager.mit.edu
   containing the command "help" (no quotes) for more information.
 * If all above REALLY fails, request the files from nevries@cc.ruu.nl
Locating lossless data compression ==> SOURCES <== :
  garbo.uwasa.fi /pc/programming/lds_10.zip contains most known sources
  for lossless data compression.

>Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at 
garbo.uwasa.fi /pc/programming. Make files for Borland C are included. 

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 1992 23:44:59 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP, Windows 3.1, and Mounted File Systems

In article <1992Nov25.033220.9842@fawlty.towers.oz.au> johnmac@fawlty.towers.oz.au (John MacLean) writes:
>What options are available to have file systems mounted under MS-Windows 3.1,
>from a UNIX box, and having TCP/IP active simultaneously?
>
>I know this can be done using Novell, but are there any NFS options, or
>anything else?

	Novell has an NFS Client for LanWorkPlace as an add on option.
Also, most TCP/IP companies can provide the NFS and TCP/IP under windows.
A short list includes:

	Beame & Whitesode Software Ltd.
	FTP Software
	Wolongong
	Sun  
	...
>
>John MacLean.
>-- 
>This net: johnmac@fawlty.towers.oz.au                   Phone: +61 2 427 2999
>That net: uunet!fawlty.towers.oz.au!johnmac             Fax:   +61 2 427 7072
>Snail:    Tower Technology, 1 Apollo Pl,                Home:  +61 2 449 5930
>          Lane Cove, NSW 2066, Australia.

Carl Beame
Beame & Whiteside Software Ltd.

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Nov 1992 00:06:27 GMT
From:      mobrien@telesciences.com (Mark W O'Brien)
To:        comp.protocols.tcp-ip
Subject:   Need root privelidges to open RAW socket?


Is it necessary to have root privelidges in order to open
a RAW socket?

This seems to be the case when running the 'ping' implementation
from Steven's book on Unix network programming. If so, is there
a way to make this run without being a superuser?

			   Mark O'Brien
               mobrien@telesciences.com
-- 
 _______________________________________________________________________
								
                       "I never liked Star Trek"
 _______________________________________________________________________

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Nov 92 09:35:23 GMT
From:      eks@daimi.aau.dk (Eigil Krogh S|rensen)
To:        comp.protocols.tcp-ip
Subject:   Is there a "something"-ware tcp/ip package for UNIX ?

s there "something"-ware package(s) for unix which has/have

tcp/ip
rlogin, rcp remsh/rsh or something like it.
nfs.


Thank you in advance !


--- Eigil


-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 92 09:44:00 GMT
From:      smee@bristol.ac.uk (Paul Smee)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPAnet means?

In article <rhughes.1.0@UCSD> rhughes@UCSD (Richard J. Hughes) writes:
>The title says it all.  What does the "ARPA" in ARPAnet stand for?  Would 
>some kind soul please let me know.

Advanced Research Projects Agency.  Part of the US Department of Defense,
or at least was originally.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 92 17:32:19 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP, Windows 3.1, and Mounted File Systems

John MacLean (johnmac@fawlty.towers.oz.au) wrote:
: What options are available to have file systems mounted under MS-Windows 3.1,
: from a UNIX box, and having TCP/IP active simultaneously?

We have this scenario.  I use FTP's PCTCP and InterDrive.  Works fine.

Chris
--
            VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Nov 1992 22:08:26 GMT
From:      aaraya@tolten.puc.cl (Arnoldo Araya Flores)
To:        comp.protocols.tcp-ip
Subject:   TRouter in CISCO 500-CS !!


I would like to have some help with a routing problem with slip
connections in our network.

We have a CISCO 500-CS Slip Gateway. We are using it for a  remote
connection to proffesors of our university. In order to achieve this, we
have only one phone number that connects through three lines to our
CISCO. Then you can dial to  this number and go in one of those three
lines (the Telephone Company manage the line the call goes).

This CISCO is used like a router. Then I put the next adresses in the
dial in ports:
146.155.30.1
146.155.30.2
146.155.30.3

And the ethernet interface has the next IP number

146.155.1.1

It doesn't work. You can go to the slip gateway, enter the slip mode,
but when you try to do telnet from your computer it doesn't work (only
5% of the trys). I suspect that it is a routing problem, because what I
have is to have one network routed through three differents lines.
My interest is to have one network for all the slip connections.

I will thanks any help to solve this problem

Arnoldo Araya 
aaraya@tolten.puc.cl
Support Manager
SECICO
PONTIFICIA UNIVERSIDAD CATOLICA DE CHILE
CHILE



-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 92 02:03:38 GMT
From:      bmw@isgtec.com (Bruce M. Walker)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: BOOTP ROM problem

In article <1992Nov25.135026.18329@cli.di.unipi.it> luigi@iet.unipi.it writes:
> We are having problems with a BOOTP prom for WD8003 cards. The BOOTP
> PROM is Beame & Whiteside v.1.1a for WD8003, and works perfectly with an
> Ultrix 4.1 server. But when trying to make it work with AIX 3.2, or with
> a port of CMU bootpd we made to 386bsd, it doesn't work anymore. It
> appears that the PC sends the bootp request, the host replies, the PC
> receives the reply and then simply asks "Enter boot volume name: "

Beame & Whiteside's BOOTP ignores "directed" BOOTP replies, they have to
be broadcast to be recognized.  This drove me crazy until I accidentally
discovered that fact with an HP implementation of bootpd that has a flag
to do broadcasting instead of the more standard directed reply.

I figure it can't be that hard to modify CMU bootpd, but I haven't got the
time myself.

--
"Eventually, I decided that thinking was not getting me very far and it
 was time to try building."           -- Rob Pike, The Text Editor sam
      bmw@isgtec.com   [ ...!uunet.ca!isgtec!bmw ]  Bruce Walker

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 92 16:03:58 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:

>Darren -
 
>     If your TCP applications break because you get an ICMP Network
>(or Host) Unreachable then they are very very broken.  Unfortunately,
>this is the behavior of vanilla 4.2bsd and 4.3bsd; some cretin several
>years ago thought this would be a useful `feature.'  A lot of people
>have been nagging various vendors to get this fixed (I take credit for
>getting NeXT to fix it in 2.0 of NeXTSTEP) and for the most part this
>bug seems to have been squished in the US.

The ICMP unreachable is only a guess at what the network is sending...
but why should it send these back when it should be sending redirects
to notify someone or something that the route has changed ?

Or does a route have to become unreachable before an alternative is found ?

Darren

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Nov 1992 20:59:50 GMT
From:      jones@bernie.sal.wisc.edu (Tom Jones)
To:        comp.protocols.tcp-ip
Subject:   ENOTTY from getsockopt

One of our programmers is getting the error return ENOTTY from
a getsockopt call.  I don't have the source code, but here is
the situation.  He is trying to set the tcp-level option
TCP_NODELAY using setsockopt, so before and after that call he
uses getsockopt to return the option setting.  Each getsockopt
call returns the error code ENOTTY.

I know this isn't much to go on, but if anyone has seen this
behavior and knows what is happening, I would appreciate
hearing from them.

-- 
Thomas E. Jones               | internet:  jones@sal.wisc.edu
UW Space Astronomy Laboratory | DECNET:    UWSAL::JONES
1150 University Avenue        |
Madison, WI 53706             | Ma Bell:    (608)263-4683

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 92 01:34:52
From:      jraja@vipunen.hut.fi (Jarno Tapio Rajahalme)
To:        comp.protocols.tcp-ip
Subject:   Re: header compression algorithms

In article <719@quirm.terminus.ericsson.se> steve@terminus.ericsson.se (Steve Reynolds) writes:

   I am interested in the Van Jacobsen header compression algorithm, but I am worried
   about it's application over an unreliable medium.


The RCF1144 ("Compressing TCP/IP Headers for Low-Speed Serial Links")
describes the algorithm in detail (including sample code). It (and
other RFCs) can be ftpd from nic.ddn.mil.


   I understand it to be a differences algorithm.

   If this it the case, then how is recovery from a lost packet accomplished?


Since TCP provides Reliable transfer on top of _unreliable_ media, the
problem is solved by TCP discarding incoming packets (which have, for
example, sequence number out of sync.). Main point here is that the
TCP Checksum is _never_ compressed. When TCP does error recovery the
compression algorithm gets in to sync again.


   Does a lost packet imply that a TCP connection must be lost or time out before 
   another may be established? ,or are certain TCP control packets sent uncompressed
   to allow for resynchronisation?


No, yes (see above).


   If there are problems on unreliable networks - does anyone know of any other 
   header compression algorithm (preferably code) which is applicable to this 
   environment?


   Thanks in advance


You're welcome.

   Steve


	Jarno
-- 
-----------------------------------------------------------------------------
| Address: Jarno Rajahalme            | EMail:                              |
|          Servin Maijan tie 12 H 111 |   Jarno.Rajahalme@hut.fi            |
|          02150  ESPOO, FINLAND      | tel: +358 0 468 2891                |
-----------------------------------------------------------------------------

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 92 01:04:51 GMT
From:      mrc@Ikkoku-Kan.Panda.COM (Mark Crispin)
To:        comp.protocols.tcp-ip, Darren Reed <avalon@coombs.anu.edu.au>
Subject:   Re: NSFNet goes to hell..

The only thing that an ICMP Unreachable means is that a particular packet got
dropped because the route switched.  Your TCP is supposed to retransmit.  That
is, after all, the whole point of the TCP transition nearly 10 years ago
(somewhere I have my I Survived the TCP Transition button) was to run on
networks that did not guarantee reliable delivery.  NCP was otherwise a
perfectly good and useful protocol and a helluva lot easier to implement.

Furthermore, your question about a redirect makes no sense.  A redirect isn't
terribly useful if the routing change is further down the pipe from your local
gateway.  You have no knowledge or control over what gateways are used other
than your local gateway; so a redirect wouldn't do you a bit of good.

What you're essentially asking is shouldn't the gateway deliver your packet
anyway, even though the route switched while your packet was in transit.  That
requires quite a bit of hair in the routing infrastructure; probably more than
can be reasonably expected since the new route may be several routers back.
That is, if the packet took a wrong turn 5 routers back, for the router to get
it back on track it would have to backtrack it 5 routers.

It is a lot easier -- and probably a lot more reliable given the possibility
of routing loops -- for the packet to be dropped and let the originator's TCP
retransmit.  The ICMP Unreachable is simply a courtesy.

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 92 06:19:36 GMT
From:      bj@steele.ohsu.edu (Bill Jackson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Does Ethernet into Token Ring go?

I am looking for experiences in, or references to information on, moving a
large Ethernet installation onto a 16M Token Ring backbone.  The TR is already
supporting approx 800 PC's running NetWare and TCP/IP, and the Ethernet has
about the same number of various workstations running almost everything you can
think of, including OSI protocols.

The Ethernet needs to be upgraded, as it is currently all bridged and the
bridges are becoming a throughput bottleneck, not to mention too much chatty
traffic going too far!  I am looking at the possibility of joining onto an
existing 16M TR and cutting down the number of protocols to NetWare, TCP/IP,
EtherTalk and some DECNET.  I will keep the Ethernet hardware at the
stations, and use either NetWare or other (better!) routers to handle traffic
onto the TR backbone.

I have a few questions about this strategy:
Will it WORK?
Is the Ethernet traffic going to create any problems? 
Is there any way to predict the resultant loading on the TR?  
When subnetting, what is the recommended # of devices (ie subnet mask) on the
token ring (4M) and Ethernet (10M) subnets?

Sorry if this is a frequent question - I don't get much time to read the News!
If anyone has any advice or observations, I would like to hear from them,
prferably by mail.  I will be gald to post or mail responses to others
interested.

Thanks.

-- 
---
William Jackson                     Manager, Network Services, Gaines Hall #113
Oregon Health Sciences University (OHSU), 840 SW Gaines Road, Portland,OR 97201
(503) 494 4535          Internet: bj@ohsu.edu     AT&T Mail: attmail!ohsu3b2!bj

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Nov 92 06:31:10 GMT
From:      bernie@metapro.DIALix.oz.au (Bernd Felsche)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Network print spoolers? Parallel ports?

In <id.629V.9W1@ferranti.com> peter@ferranti.com (peter da silva) writes:

>We have a network of Sun workstations that we want to stick a parallel
>port dot matrix printer on for draft quality screen dumps. Because it's
>such a high data volume, we don't want to mess with a serial printer.
 
>Sun's parallel port is O($1000)! 
 
>Next solution is to use a standalone printer server or terminal server
>with a parallel port. This would simplify administration and dependence
>on some particular workstation, too. What sort of products should we be
>looking at, and what sort of prices?

Don't forget about SCSI-based systems. There's a Central
Data widget that connects to SCSI and will give you
paralized ports. They start at about $700, list. Phone
800-482-0315

As far as networks are concerned, there's a Milan (don't you
hate puns in names?) printserver. It costs about $900 and
will drive one printer. Contact fpinfo@milan.com.

If you need another termserver anyway, then the cost of an
extra paralysed port is minimal.

I am not associated in any way with any of the above
companies, nor do I have any experience with their products.
I just saw the ad's in UNIX REVIEW and thought I might give
a couple of alternatives.

You're wise enough to make your own choice.
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Nov 1992 03:27:24 GMT
From:      an318@anon.penet.fi (Knauerhase's friend)
To:        comp.protocols.tcp-ip
Subject:   To Rob Knauerhase...

Were you saying something about trying to post anonymously to this
group?
--------------------------------------------------------------------------
To use this service, send mail to:
Anonymous posting:		<name.of.news.group>@anon.penet.fi
Anonymous mail:			<user's alias>@anon.penet.fi
				<user%host>@anon.penet.fi
Test path/get alias:		ping@anon.penet.fi
Assign nickname:		nick@anon.penet.fi	(in Subject:)
Anon administrator:		an0@anon.penet.fi	(anonymously)
				admin@anon.penet.fi	(non-anon)
Or mail to anon@anon.penet.fi with an X-Anon-To: header line.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 92 16:28:06 GMT
From:      paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
To:        comp.protocols.tcp-ip
Subject:   Re: To Rob Knauerhase...

an318@anon.penet.fi (Knauerhase's friend) writes:

>Were you saying something about trying to post anonymously to this
>group?

I apologize for this posting.  Comments may be sent to the originator,
Michael David Adams, aka StarOwl, at mda46419@uxa.cso.uiuc.edu.

Nov 28 21:29:28 ux1 sendmail[19646]: AA19646: message-id=<9211290327.AA17120@ eng-nxt10.cso.uiuc.edu >
Nov 28 21:29:28 ux1 sendmail[19646]: AA19646: from=<mda46419@eng-nxt10>, size=485, class=0
Nov 28 21:29:28 ux1 sendmail[19646]: AA19646: received from eng-nxt10.cso.uiuc.edu (128.174.2.30)
Nov 28 21:29:33 ux1 sendmail[19648]: AA19646: to=<comp.protocols.tcp-ip@anon.penet.fi>, delay=00:00:05, stat=Sent, mailer=TCP, relay=fuug.fi

/pbp
-- 
Necessity is the argument of tyrants, it is the creed of slaves.
	--William Pitt (1783)

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 92 16:28:49 GMT
From:      ksh@powell.cs.jt.dk (Kurt Sejr Hansen)
To:        comp.protocols.tcp-ip
Subject:   D-link 600 adapter and PC-NFS


	Hi' there ........
	
	Has anyone  used a D-link adapter with PC-NFS on two
        ethernet segments ?.
	We are trying to establish a ftp or telnet connection from
	one ethernet segment to a host on another segment. But both
	ftp an telnet hangs .....
	Please give me a hint' if possible.

	Used drivers :

	DE600PD.sys  from  27/3 1992 size is 7848 bytes
	PDNFS.SYS    from  3/12 1991 size is 4160 bytes

	The pocket adapter is a DE-600AUI-E, PC-NFS version is 3.5c



 CONFIG.SYS file


device=a:\dos\himem.sys
buffers = 40
BREAK=ON
COUNTRY=045,,a:\DOS\COUNTRY.SYS
DEVICE=a:\DOS\DISPLAY.SYS CON:=(EGA,,1)
INSTALL=a:\DOS\SHARE.EXE
shell =command.com /p /e:800
DEVICE=a:\NFS\PCNFS.SYS  /m
DEVICE=a:\NFS\SOCKDRV.SYS
device=a:\nfs\de600pd.sys 98                                        
device=a:\nfs\pdnfs.sys
LASTDRIVE=V



AUTOEXEC.BAT file :


@ECHO OFF
PROMPT $p$g
PATH A:;A:\NFS;A:\DOS;
MODE CON CODEPAGE PREPARE=((850) A:\DOS\EGA.CPI)
MODE CON CODEPAGE SELECT=850
KEYB DK,,A:\DOS\KEYBOARD.SYS
set nfsdrive=a
set TZ=WET0WDT
prt *
nfsrun


a:\nfs\drives.bat file :


NET USE    G: kepler:/home/pc/gdos  /ms


a:\nfs\hosts file :


192.66.17.90	nfs_test
192.66.17.1	bacon
192.66.17.70	jt


The network.bat file :


NET NISDOMAIN Sysnet
NET START RDR nfs_test *
NET ROUTE jt
NET NISSET bacon
NET NAME *




                                         Router
	Problem :                        ______
                         Segment #1      |    |   Segment #2
	---------------------------------|    |--------------------	
         |               |               ------       |
         |               |                            |
       fileserver #1    D-link                      fileserver #2


	If i try to ftp or telnet from D-link to filserver #1 it's
	ok, but it i try to telnet/ftp to filserver #2 i never get a
	connection. If i use telnet it displays "Trying ....." and
	the connected messages, but i never see the username and 
	password messages. We have other PC's connected to
	segment #1 with 3COM adapters, and it works fine.

	Fileserver #1 is a SUN 4/390, fileserver #2 is a SUN 4/470
	the D-link adapter is connected to a Toshiba T3100SX.



	Kurt Sejr Hansen
	ksh@cs.jt.dk
 
--
   J TTTTT AAAA    SS      JYDSK TELEFON
   J   T   A  A   S        Kurt Sejr Hansen   ksh@cs.jt.dk
   J   T   AAAA    S       Sletvej 30 8310
 JJ    T   A  A  SS        DK  Denmark

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 92 01:50:27 GMT
From:      parson@coulomb.pcc.oz.au (Brenda Parsons - x2403)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: BOOTP ROM problem

Bruce M. Walker (bmw@isgtec.com) wrote:
: Beame & Whiteside's BOOTP ignores "directed" BOOTP replies, they have to
: be broadcast to be recognized.  This drove me crazy until I accidentally
: discovered that fact with an HP implementation of bootpd that has a flag
: to do broadcasting instead of the more standard directed reply.
: 
Is this also a problem with the FTP PC/TCP's bootpd?  It seems that
the bootp requests are being broadcast instead of directed.

-- 
% Brenda Parsons                  
% Currently at Prospect Electricity
% 10 Smith Street, Parramatta 2150, Australia
% +61 2 635 0300              e-mail:   parson@coulomb.pcc.oz.au        

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 92 11:09:11 CST
From:      robert@cpvax.cpses.tu.com
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Does Ethernet into Token Ring go?

In article <1992Nov28.061936.14440@ohsu.edu>, bj@steele.ohsu.edu (Bill Jackson) writes:
> I am looking for experiences in, or references to information on, moving a
> large Ethernet installation onto a 16M Token Ring backbone.  The TR is already
> supporting approx 800 PC's running NetWare and TCP/IP, and the Ethernet has
> about the same number of various workstations running almost everything you can
> think of, including OSI protocols.
> 

At CPSES we are sucessfully bridging Ethernets using a site Token Ring
backbone.  If you want to bridge, remember that non 802.3 packets (Ethernet
frame format) will need to be "translated" before it gets put on the 
token ring.  This is done by creating a fake 802.3 header and using a 
special DDAP and SSAP field.  The bridge on the other side of the link
recognizes the special fields and strips them off for transmission on the
remote Ethernet.

This translation activity is not standardized.  We use IBM 8209 bridges for
all our Ethernet-TR bridging.  We have CISCOs routing routable protocols
between Ethernet and TR on a couple of segments, but still need an 8209 for the
non-routable protocols.  (The routable protocols are filtered out on these
8209s.)  Cisco's tranlation bridging (if available) is not compatable with
IBM's.

We use TR to link campus Ethernets because it doesn't have the collision
domain (distance) restrictions and because it was installed for another 
project.  We are very happy with our configuration.

-- 
-------------------------------------------------------------------------
Robert Eden    817-897-0491                                 Glen Rose, TX
Comanche Peak Steam Electric Station            robert@cpvax.cpses.tu.com
               ^^^^^^^^^^^^^^^^^^^^^ politicese for a nuke plant
-------------------------------------------------------------------------


-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 1992 06:03:19 GMT
From:      root@candle.uucp (Bruce Momjian)
To:        comp.protocols.tcp-ip
Subject:   Rlogin vs. Telnet


Having read Steven's "Unix Network Programming", what is the major
difference between rlogin and telnet.  Here are the differences I see:

	1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
	computer

	2) rlogin assumes there is a tty terminal discipline on each
	side of the connection, telnet does not
	
Are there any other major differences, either in function or features?
-- 
Bruce Momjian                          |  830 Blythe Avenue
root%candle.uucp@bts.com               |  Drexel Hill, Pennsylvania 19026 
  +  If your life is a hard drive,     |  (215) 353-9879(w) 
  +  Christ can be your backup.        |  (215) 853-3000(h)

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 1992 11:29:02 GMT
From:      tkevans@fallst (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

root@candle.uucp (Bruce Momjian) writes:


>	1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
>	computer

rlogin is for "something-to-unix" logins.  Some (all?) of the PC
TCP/IP packages have an "rlogin" application.

>	2) rlogin assumes there is a tty terminal discipline on each
>	side of the connection, telnet does not
>	
rlogin can carry your local user environment--terminal type being
only one of what can be carried over to the remote.  Also, assuming
proper security equivalences are set up, you can use rlogin to 
access a remote host without a password.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 92 15:02:59 GMT
From:      hwstock@snll-arpagw.llnl.gov (stockman harlan w)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

>> P.S. How would you rate 500KB/sec?
>
>
>That depends on the medium.
 [...]
>
>P.S.  Over ethernet 500KB/s would be poor for a modern workstation, but
>    common for a PC.  As measured by `ttcp`.  Ftp ttcp source from
>    brl.mil or sgi.com

It may be possible to get >> 500 kB/sec in a "modern" network, with a
moderate amount of traffic and direct connections, but in many older
buildings retrofitted for ethernet, it is hard to be guaranteed > 100
kB/sec. I'm hooked up through a tranceiver in a building with about 200
users. I've monitored PC-workstation, workstation workstation, etc
transfer rates, and find we rarely get above 100 kB/sec on a busy day.
Many people leave long postscript print jobs for the wee hours, so it is
hard to find any optimum time. Rates between two SGI workstations are no
different than the rates (on average) between a workstation and a PC
with an 8-bit, 8 MHz wd8003 card. That's life.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 1992 12:17:10 IST
From:      Hank Nussbacher <HANK@BARILVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

In article <1992Nov30.060319.17880@candle.uucp>, root@candle.uucp (Bruce
Momjian) says:
>
>Having read Steven's "Unix Network Programming", what is the major
>difference between rlogin and telnet.  Here are the differences I see:
>
>        1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
>        computer
>
>        2) rlogin assumes there is a tty terminal discipline on each
>        side of the connection, telnet does not
>
>Are there any other major differences, either in function or features?

From a document I once wrote up serving as a tutorial for terminal
servers:

    The Rlogin  command enables  a user  to log  into a  remote host
system  by  specifying  the  host  system  and  a  username  that is
recognized by the host.   There are advantages and  disadvantages to
using RLOGIN rather Telnet to make a connection.  At some hosts, the
RLOGIN implementation can be  more efficient at terminating  display
output from a  program (i.e when  you issue a  <CTL C> command,  the
user prompt  is displayed  faster with  an RLOGIN  connection than a
Telnet connection).   However, since  the RLOGIN  protocol is  not a
TCP/IP standard, RLOGIN is less widely available and is usually  not
as well  implemented as  Telnet.  For  example, the  RLOGIN protocol
does not typically support  binary session modes, local  echoing, or
features  that  are  standard  Telnet  such  as "Are You There?" and
"Synchronize".

>--
>Bruce Momjian                          |  830 Blythe Avenue
>root%candle.uucp@bts.com               |  Drexel Hill, Pennsylvania 19026

Hank Nussbacher
Israel

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 92 17:48:28 GMT
From:      sgriffee@nynexst.com (Steve Griffee)
To:        comp.protocols.tcp-ip
Subject:   responses: remote TCP/IP LAN ideas

ORIGINAL MESSAGE:

>> I'm looking for ideas for connecting remote PC and MAC workstations
>> to our TCP/IP LAN using regular dial-up phone lines.  I've seen all
>> the usual asynch access devices.  I'm looking at the relatively hi
>> bandwidth facilities such as ISDN.  For example, so far I have
>> found out about the IMAC ISDN bridge made by DigiBoard and the RLN
>> asynch bridge (using hi speed modems and regular phone lines) made
>> by DCA which uses the PPP protocol.  Has anyone else found any
>> interesting means of connecting remote offices or workstations to
>> the LAN?  Let's swap discoveries.  Can We Talk?  Please respond
>> directly to my email address below.  I will summarize all submitted
>> responses if requested.
>> 
>> Watch out.  Telecommuting may be just around the bend for your
>> company.  Don't let it catch you asleep at the wheel.
>> 
>> Thanks
>> Steve
>> 

SUMMARIZED RESPONCES:

>From chrisv@cmc.com Sun Nov 22 14:08:20 1992
>Return-Path: <chrisv@cmc.com>
>
>Steve,
>You're exactly right about telecommuting begin right around the corner.
>But, from where we are today, we see that the remote branch office, typically
>occupied by sales or admin personnel, still need to connect in and
>they can't justify a cisco for $10K, a DDS circuit and all the other
>headaches of an enterprise routing solution. At the other side you have people
>who have been using SMARTCOM and all the other terminal emulation packages 
>that are a pain in the neck when you try and do REAL network comuting such as
>native mail, file transfer and, heaven forbid, client server computing.
>This problem is eactly the reason why we have released our NetHopper product
>line which is uses V.32bis/V.42bis dialup now, and will use ISDN BRI in the
>***VERY*** near future as well. PLus, with V.FAST coming to a head in the
>standards process by the middle of 93 we can be getting 100 kbps over a phone
>line.
 
>Cheers,
>Chris VandenBerg
>Product Line Manager
>Rockwell International CMC Network Products
>125 Cremona Dr. Goleta, CA. 93117
>805-562-3127 fax - 805-968-6478
>email - vandenberg@cmc.com
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From cmkilli@ns.PacBell.COM Thu Nov 19 22:16:00 1992
>Return-Path: <cmkilli@ns.PacBell.COM>
>
>Steve,
>I work for Pacific Bell on a project called Knowledge Network, where we are 
>connecting K-14 Schools through our cisco System Hubs to the Internet.  As 
>part of the project I am also going to supply dial access using either SLIP
>or PPP protocol.  I am currently working with a Telebit NetBlazer for SLIP/PPP
>over analog dial (up to 9600 v32bis, v42bis, & MNP5).  For ISDN access I am 
>working with Commdial boxes that provide a remote mac bridge function over 2
>ISDN B channels on an instant/on demand call set-up system (128Kb) and also 
>a product called CommServer that provides 23 B channels to Ethernet mac bridge
>functionality.  I am still in the lab test phases for a lot of this and would
>be glad to correspond with you on this.
>
>Buster Killion,
>Voicemail: (510) 823-6290
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From johnb@kalpana.com Thu Nov 19 00:04:32 1992
>
>Steve,
>
>       You might want to look at Telebit's NetBlazer line 
>of dailup IP routers. When I worked there they were shipping
>dialup routers for standard lines (9600 baud-ish speeds), sync
>lines, and were working on ISDN. One the local side, they supported
>ethernet & token ring. They supported SLIP, PPP, and
>a plain raw mode you could kermit into. You can call them at (408) 
>745-3200, or try email to fmueller@ telebit.com (fritz mueller)
>The Netblazers marketing guy. He should be able to help you out.
>
>They are in Sunnyvale California, USA, but I forget the exact 
>street address.
>
>DISCLAIMER: I used to work on the NetBlazer. (but it seems to work
>anyway :-)
>
>====================================================================
>==
>John Bartas                     | Disclaimer - I don't speak for Kalpana
>Pricipal Software Engineer      | in any official capacity. I'm just
>Kalpana, Inc. (408)988-1600x141 | an employee who reads the net.
>
>"We have met the enemy, and he is us." -Pogo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From dcarr@donut.gandalf.ca Tue Nov 17 09:29:10 1992
>Return-Path: <dcarr@donut.gandalf.ca>
>
>We make 2 products in this category.  At the low end, our 5510 is
>an ethernet/ISDN bridge.  The 5510 can handle only 1 B-channel.
>At the high end, our 5220 ethernet bridge (which requires an external
>ISDN terminal adapter) offers dual B-channels with DATA COMPRESSION.
>A software upgrade is in progress to add V.25 bis dialing capabilities
>to the 5220 and bandwidth on demand.  That is, we'll bring up the
>first B-channel only when there's packets to bridge, and the second
>link when there is sufficient load, etc.
>
>Also in the works is a remote ISDN access system.  At the central site
>you have one "pizza box" with up to 4 T1 inputs, and an ethernet out.
>Or, up to 128 B-channels with stackable expansion.  
>
>>Watch out.  Telecommuting may be just around the bend for your
>>company.  Don't let it catch you asleep at the wheel.
>
>We were actually ISDN ready a couple of years ago.  Boy the money we 
>could have made had ISDN been deployed.
>-- 
>Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
>Principal Designer      | TEL (613) 723-6500     | after you know it all,
>Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 
>
>From emv@garnet.msen.com Tue Nov 17 01:06:32 1992
>Return-Path: <emv@garnet.msen.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>Steve,
>
>Msen offers a number of these services to our customers; if you send
>mail to 'info@msen.com' we'll ship you the current list of services etc.
>
>I'm waiting for a call back from Mi Bell about ISDN, but for the moment
>we tend to use dialup PPP stuff.
>
>
>  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
>        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From ss@panix.com Mon Nov 16 23:35:22 1992
>Return-Path: <ss@panix.com>
>
>I'm no expert on the topic and I'm not familiar with the above mentioned 
>ISDN hardware but here are my thoughts:
>
>If we're talking telecomputing,shouldn't the discussion lean towards
>leased lines?  Wouldn't it be cheaper then a 8 hour dialup connection?
>I would guess that PPP at 64k would handle most applications on a 
>single PC.   I think Morningstar has some hardware to do this.
>
>Does the user really need a PC?  How about leaving the PC at the office
>running PCAnywhere and give the user a vt100 ?
>
>>Watch out.  Telecommuting may be just around the bend for your
>>company.  Don't let it catch you asleep at the wheel.
>
>Don't forget: 186,000 miles/second isn't just a good idea, it's the law!
>
>-- 
>====================================================================
 =
>=== Steve Steinberg   ==  ss@panix.com  == {cmcl2,apple}!panix!ss ===
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From w8hd!w8hd!kimc@vela.acs.oakland.edu Mon Nov 16 20:00:18 1992
>Return-Path: <w8hd!w8hd!kimc@vela.acs.oakland.edu>
>
>I have just installed Morningstar PPP on a Sun Sparc and according
>to the docs it should do exactly what you want to connect the
>tcp-ip lan to async. It can do this with a machine's native serial ports
>so 'nothing more to buy.' If you need more/faster ports on a Sun, they work
>closely with Magma, which produces S-Bus expansion boards at low cost.
>They also have really excellent support if you should need it.
>Morningstar: 800-558-7827
>Contact: Dean Schell
>regards
>kim culhan
>------
>kimc@w8hd.org
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From LEONARD@Arizona.edu Mon Nov 16 19:51:18 1992
>Return-Path: <LEONARD@Arizona.edu>
>
>Hi Steve,
>
>Well, I don't work for the phone company, so please forgive me if
>I'm skeptical about ISDN.  (At any rate, I'm *extremely* skeptical
>that USWest will be able to deliver ISDN to a significant fraction of
>the walljacks in Tucson, with a reasonable tariff, within the next
>five  years; it may well be that NYNEX will do better.)
>
>So my view is that Plain Old Analog voice lines is the best we'll be
>able to use, in the next several years, as far as delivering dynamic
>network connectivity to the rank and file of telecommuters.
>
>My experience is that the best bet for right now and the next year
>or two is to use commodity V.32bis/V.42bis modems, such as 
>MultiTech MT1432s.  Our testing shows that these can deliver
>13-32Kbps in real world applications.  In the future, V.fast/V.42bis
>modems should be able to deliver 24-70Kbps of real throughput,
>which should to a large extent obviate the need for ISDN.  (I don't
>deny that ISDN would be *better*; I simply don't see it happening
>in the local loop real soon.)
>
>On the backbone side, our plan is to plug the modems into serial ports
>on comm servers, with the RS232 port set to 38.4Kbps.  (57.6Kbps or
>faster would be nice, especially when V.fast becomes an economic
>reality, but the comm servers we have [Xylogics Annex 3's] will only 
>do 38.4.)
>
>The idea is to have the comm servers do dynamic dialup SLIP (or, in
>the future, PPP), by letting the user enter a hostname/password 
>combination.  It is important that the IP address assigned to the modem
>connection NOT be tied to the serial port, because that would cause the
>user to get a different IP address each time he connects.  We prefer
>to give our users a "real host name", so that they can use things like
>rlogin, to pick up mail, etc.
>
>On the PC side, the user can use a script to handle the dialing, issuing
>the hostname/password, and switching into SLIP mode.
>
>We find that this works well for TELNET (wow!) and FTP.  Using X11 is
>something of an issue... this speed is just NOT really fast enough.
>It would seem that NCD's Xremote protocol is the champion here.
>Some people (e.g. cisco) are putting Xremote on their comm servers.
>(A software engineer from cisco told me that he was using an X terminal
>over a 9.6Kbps modem link into a comm server, running Xremote, and 
>that it worked well enough to keep him happy, which impressed me 
>quite a bit.)  Others are recommending running the Xremote server
>on a host on the backbone side, which may make more sense.
>
>I'm interested in seeing your summary ... good luck,
>
>Aaron
>
>Aaron Leonard (AL104), <Leonard@Arizona.EDU>
>University of Arizona Network Operations, Tucson AZ 85721
>  "It's not a bug, it's a form of flow control."
>  - Jerry Leichter on why crash-prone Unix is a suitable
>    platform for NSFNET core routers
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From ittai@ans.net Mon Nov 16 18:17:46 1992
>Return-Path: <ittai@ans.net>
>
>Steve,
>
>ANS has recently announced ANSremote service so that our leased-line
>attachment customers (such as NYNEX S&T) can dial-in to their home
>system from anywhere in the continental US with a convenient 1-800
>number.  Initially, we are only supporting virtual terminal services
>(i.e. telnet and rlogin) but plan to introduce full SLIP/PPP services
>in early 1993.
>
>I would also be interested in offering an ANRemote-ISDN service in
>the NY area when/if NY Tel will deploy 2B+D at a reasonable tariff.
>
>-Ittai
>---------------
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From bair@america.Telebit.COM Mon Nov 16 18:14:56 1992
>Return-Path: <bair@america.Telebit.COM>
>
>Hello Steve,
>  If your running an IP based network, the NetBlazer is probobly the answer
>your looking for. It is the 1st dialup router and can work with a variety
>of topologies and access methods. 
>  By that, I mean it can be on a thick, thin, or twisted pair ethernets or
>shielded or unshielded 4/16 mbit token rings. Access can be had via dial up
>modems, T/As for ISDN, or switched 56 services and provide either terminal
>services or routing services. It supports SLIP or PPP on its async ports
>and on the the sync port, PPP. Telebit has also announced that in January,
>Novell and Appletalk routing will also be supported as well as multiple sync
>ports for speeds to T1/E1!
>   Your local Telebit office is in Melville, NY. They can be reached by 
>calling them at 1 516 420 0560.
>
>I hope that this has been helpful.
>
>Sincerely:
>
>Scott Bair
>Systems Engineer
>Telebit Corporation
>bair@telebit.com
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>From pollard@vtserf.cc.vt.edu Mon Nov 16 16:40:29 1992
>Return-Path: <pollard@vtserf.cc.vt.edu>
>
>Steve,
>
>I haven't tried it myself, but I have a spec sheet here on the "Combinet
>INTERCHANGE ISDN LAN adapter" that sounds like what you're looking for.
>I don't have much detail on the above, but you can try contacting the
>sales guy who sent me the info: Ray Thompson @ CLC Associates.  800 394-CLCA
>or at his desk @ 804 922-7601, or 7784.
>
>John Pollard
>Virginia Tech
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
>nelson Mon Nov 23 10:01:04 1992
>From: nelson@crynwr.com (Russell Nelson)
>
>In article <1992Nov16.191510.474@nynexst.com> sgriffee@nynexst.com writes:
>
>   Watch out.  Telecommuting may be just around the bend for your
>   company.  Don't let it catch you asleep at the wheel.
>
>Holy shit, Steve, is NYNEX just figuring this out?!?!???
>
>No wonder It Still Does Nothing in New York.
>
>Sorry for the gratuitious flamage, but maybe that's what the baby
>bells need?
>
>-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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Thank you to all those who responded to my request for ideas.  For the most 
part the responses were constructive and very helpful.  I hope that sharing 
the results will be useful to others who are engaged in similar ongoing 
quests like mine.   1993 should be a very interesting year in the northeast, 
especially for those waiting patiently for ISDN.  I expect to be ready for 
it.  

Happy Holidays.
Steve
-- 
The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 92 17:57:37 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP: Send 8 1K packets, then wait.....

In article <BARNETT.92Nov25130830@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
|> I am analyzing some medical networks, and I see a common pattern in
|> large file transfers using FTP. Could someone tell me if this sounds
|> like a bsd4.2, or bsd4.3 implementation of TCP.
|> 
|> The sending system sends 8 1K packets. The delay is about 2
|> milliseconds between packets. The last packet has a "Push"
|> flag. An ack comes back. Then the sender waits a while, typically
|> 40-100 milliseconds, and sends out 8 more packets.

You don't say how much the ACK acknowledges.  I suspect not all of the
8k is acknowledged.  Is there another ACK from the receiver before
the sender transmits any more packets.
 
|> 
|> The outgoing WIN size is 8K. The receiving window is 24K. The network
|> is not causing a bottleneck.  The system is not using IP fragments,
|> nor large window sizes on the sends. This sounds like an early
|> implementation of TCP, on a slow CPU. Typically 84KB/sec over
|> ethernet. Any guesses on why it is so slow?
|> It might be a Sun 3 running SunOS 3.5. 

I have experimented with data throughput between our AViiON systems and
SUN 3/50s running some version of SunOS (sorry don't remember the revision).
I found that when the receive buffer was much larger than the transmit buffer
(in my case 8k receiver and 4k transmitter), the BSD acknowledgement algorythm
together with the SunOS write flowcontrol scheme would catch the SUN 3/50
transmitter in such a way as to have an open window but have no new data to
send.  As soon as the receiver sent a delayed acknowledgement for the rest
of the data, the SUN was able to unblock the socket and get more data from
the application.

If you have the application source, you could use setsockopt() to resize the
send buffer to match that of the peer's receive buffer (or vice versa).  Another
method you might try is patching the kernel to use a larger default socket buffer
size.

Hope this helps.

|> 
|> (This system is on the other coast. I'm analyzing the output of a
|> tcpdump file that was mailed to me.)
|> 
|> 
|> --
|> Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

--
+------------------------------------------------------------------+
| John A. Scott                       | Phone: +1 919 248 5995     |
| Data General                        | Email: scott@dg-rtp.dg.com |
| 62 TW Alexander Drive               |                            |
| Research Triangle Park, NC 27709    |                            |
+------------------------------------------------------------------+
                                                       


-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 1992 18:31:27 GMT
From:      spexet@math.lsa.umich.edu (D. Robert Spexet II)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

In article <avalon.722609758@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes:
>After watching the NSFnet almost goto pieces in the last hour
>or so, I'd like to know if there is any way 'outsiders' can get
>info on when upgrades/maintainence is planned or even fault reports
>are sent.  Someone suggested "nsr" to me but that seems to be an
>"in-house" list only.  Are there any other offerings or are those
>who use/rely on the network expected to put up with the route
>between A and B changing every 5 minutes ?  (Surprisingly not all
>network kernels/programs can handle what goes on and this results
>in interruptions for almost anything which uses TCP).
 
>p.s. This isnt as rare as some people would have others belive, just
>     mostly seems to happen when most of the USA is asleep and the
>     rest of us are awake....well most of the time anyway...

It also happens a lot on Saturdays.


-- 
D. Robert Spexet II, N0OKR   Internet:  spexet@umich.edu
Department of Mathematics    BITnet:    user68xr@umichum.bitnet
The University of Michigan   UUCP:      uunet!mailrus!math.lsa.umich.edu!spexet
Ann Arbor, Michigan 48109

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Nov 1992 19:09:04 GMT
From:      mitton@dave.lkg.dec.com (Dave Mitton)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Does Ethernet into Token Ring go?


>In article <1992Nov28.061936.14440@ohsu.edu>, bj@steele.ohsu.edu (Bill Jackson) writes:
>From: bj@steele.ohsu.edu (Bill Jackson)
>Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
>Subject: Does Ethernet into Token Ring go?
>Date: 28 Nov 92 06:19:36 GMT
>
>I am looking for experiences in, or references to information on, moving a
>large Ethernet installation onto a 16M Token Ring backbone.  The TR is already
>supporting approx 800 PC's running NetWare and TCP/IP, and the Ethernet has
>about the same number of various workstations running almost everything you can
>think of, including OSI protocols.
>
>The Ethernet needs to be upgraded, as it is currently all bridged and the
>bridges are becoming a throughput bottleneck, not to mention too much chatty
>traffic going too far!  I am looking at the possibility of joining onto an
>existing 16M TR and cutting down the number of protocols to NetWare, TCP/IP,
>EtherTalk and some DECNET.  I will keep the Ethernet hardware at the
>stations, and use either NetWare or other (better!) routers to handle traffic
>onto the TR backbone.
>
>I have a few questions about this strategy:
>Will it WORK?
>Is the Ethernet traffic going to create any problems? 
>Is there any way to predict the resultant loading on the TR?  
>When subnetting, what is the recommended # of devices (ie subnet mask) on the
>token ring (4M) and Ethernet (10M) subnets?

	Bill, simply changing technology is not going to make your loading
problem go away.  It may just compound them.  Packets are packets.

	If your Ethernet bridges are becoming the bottleneck, you better
look out for the performance of Token Ring bridges! The TR bridge products
are a bit less mature than Ethernet bridges and tend to under-perform
the media.  (probably mostly due to the nature of the current TR media
chips)
  I suggest you review Scott Bradner's test results on routing and hunt
up copies of the following Data Communications magazine articles:
- "Remote Token Ring Bridges: Plug and Play or Plug and Pay?" Aug 1991
- "Remote Token Ring Bridges: DATA COMM Defuses Vendor Performance Claims"
	Sept 21 1991
- "Bridge Vendors Would Rather Fight than Fix"  Jan 1992

	My recommendation would not be to migrate your network, but attempt
to divide it up into managable pieces.  Multiprotocol Routers would help
this task immensely.   While a Novell NetWare Server can route IPX traffic
expecting it to do that while being a file server is a bit much.  A dedicated
router box provides a more reliable and dependable infrastructure.
Multiprotocol Routers are availible from a number of vendors these days.
We support the Proteon products for DECnet connection to Token Ring.
Other popular vendors are Cisco, Wellfleet, and Novell entering the market.

	Multiprotocol Routers will contain broadcast and multicast "chatter"
to the routed areas of the network, and only forward packets in the proper
direction.  They also provide an administrative point-of-control.

	Dave Mitton
	Token Ring Program
	Networks and Communications 
	Digital Equipment Corp.

Disclaimer: my opinions are not necessarily those of Digital's and 
	may be a bit biased.  ;-)


-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 1992 21:27:58 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Connection comes up halfway and drives me nuts,

"Connection came up half-way and then closed" is MacTCP's user-friendly
error, meaning the same as the ever-so-much-more-confusing BSDish
"Connection refused".

As to what specifically is going wrong, I can't tell.  You didn't post
enough specifics.  Make sure the Unix host accepts FTPs, make sure you
are using the right ports, and try FTPing in from another system to make
sure everything works.  Try watching everything on a network analysis
program to see how the connection opening dialog is working as well as
to make sure you are opening it to the correct FTP port (port 21).

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 92 22:19:42 GMT
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   PPP on MAC? Also FTP sites for RFCs.


Fellow Netters,
	Couple of questions,

1. Is there a PPP package available on a MAC? (PD or commercial)

2. Is there a FTP site from where RFCs can be downloaded? I believe
there is an address also where mail can be sent and RFCs returned.

Any and all responses appreciated, Thanx,

Raj.
-- 
===============================================================================
  __  __     .
 /   __/    /                               Raj Malhotra.
/   ( /_   /                                voice : (908)613 4313. 
        __/                                 email : manmetha@gauss.rutgers.edu

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

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 92 22:32:36 GMT
From:      chris@suite.sw.oz.au (Chris Maltby)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

In <MS-C.722912691.1103527590.mrc@Ikkoku-Kan.Panda.COM> mrc@Ikkoku-Kan.Panda.COM (Mark Crispin) writes:

>It is a lot easier -- and probably a lot more reliable given the possibility
>of routing loops -- for the packet to be dropped and let the originator's TCP
>retransmit.  The ICMP Unreachable is simply a courtesy.

So is there an ICMP return which means "absolutely no way to this destination"?
Or do you have to prod a few times and after enough Network Unreachables
you can safely give up? It seems to me that the gateways which can switch
routes to balance loads can also return the equivalent of EAGAIN, meaning
"I'm dropping this datagram because it's the best thing under the circumstances
but I'm not making any statement about the likelihood of sucess or failure if
you try again." If that is Network Unreachable, how are they to say
"forget it, I have no idea how to get there"? Is there an RFC which covers
this level of semantic detail?

Enquiring minds...

-- 
Chris Maltby - Softway Pty Ltd		Internet: chris@softway.sw.oz.au

PHONE:	+61-2-698-2322	"I'm waiting for X-Windows to become just that;
FAX:	+61-2-699-9174	 Ex-Windows" - A McGrath.

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 1992 22:54:22 GMT
From:      bansal@cis.ksu.edu (Vivek Bansal)
To:        comp.protocols.tcp-ip
Subject:   Server Port No....


I have written this client-server application in which basically the server
waits on a fixed port no (5000) waiting for requests from different clients.
Now, while the server was running I had to kill it by doing a Control-C, and
then when I tried to rerun the server I got the message that , 
Socket No 5000 already in use.

How do I get over this problem ??? I thought once a process was killed all
the ports used by it were immediately released ....

Thanks...

Vivek...

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 92 23:34:08 GMT
From:      bhoule@npg-sd.SanDiegoCA.NCR.COM (Bill Houle)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP, Windows 3.1, and Mounted File Systems

John MacLean (johnmac@fawlty.towers.oz.au) wrote:
> What options are available to have file systems mounted under MS-Windows 3.1,
> from a UNIX box, and having TCP/IP active simultaneously?

Wollongong Pathway Access + Pathway NFS gives you this capability.
I've also done the above + Novell with no problems.

--
Bill Houle                    bhoule@npg-sd.SanDiegoCA.NCR.COM
NCR NPD-San Diego             (619) 693-5593

END OF DOCUMENT