The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 93 07:27:30 GMT
From:      pug@cs.curtin.edu.au (Greg Barron)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.sun.admin
Subject:   Re: SUMMARY: Sniffer programs

kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes:

>It seems space.mit.edu has gotten rid of their copies of etherman, et al.
>Here's a place that works as of 930714 14:44 EST  ( ;-)
>  pprg.eece.unm.edu:/pub/X


They are always available from:

	ftp.cs.curtin.edu.au

in the directory

	/pub/netman/

Cheers...

>-- 
>Kevin Weinrich     Computer Sciences Corp.
>kbw@helios.ath.epa.gov
--
Greg

////////////////////////////////////////////////////////////////////////////////
"The ZZR-1100 remains the big, fast, versatile bike for the rider with a 
regular pillion passenger or the desire to humiliate just about every
other road user who attempted to match its straight line acceleration" - REVS
////////////////////////////////////////////////////////////////////////////////

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 93 07:34:51 GMT
From:      pug@cs.curtin.edu.au (Greg Barron)
To:        comp.protocols.tcp-ip
Subject:   Packetman...

G'day,

Those of you that read the posting regarding the 'sniffer' programs would
have seen a reference to "packetman", which was written (predominantly) by
George Benko.

Anyway, He's got himself a job (god help us !) and it has been left to me
to attempt to finish off the project. So... If anyone out there has wish
lists, spitefull comments or just plain anything to say about packetman,
especially in relation to tcpview and other tools available, then please
drop me a line.

Thanks heaps,

Greg
pug@cs.curtin.edu.au

PS. Comments about packetman, etherman & interman wouls be gratefully
(no money though) received by netman@cs.curtin.edu.au.
--
Greg

////////////////////////////////////////////////////////////////////////////////
"The ZZR-1100 remains the big, fast, versatile bike for the rider with a 
regular pillion passenger or the desire to humiliate just about every
other road user who attempted to match its straight line acceleration" - REVS
////////////////////////////////////////////////////////////////////////////////

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 93 13:49:33
From:      ed@odi.com (Ed Schwalenberg)
To:        comp.unix.programmer,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: Asynchronous RPC library ?

In article <CB061M.10I@idacom.hp.com> janzen@idacom.hp.com (Martin Janzen) writes:
   ONC RPC is still pretty hard to beat, though.  It's very widely supported, 
   it's reasonably efficient and reliable, you can get the source code, and
   it's free!  What more can you want?

If your network isn't 100% reliable, one could want a library that permits
one's code to get at some description of the network error other than
RPC_TIMEOUT, RPC_CANTSEND and RPC_CANTRECV.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 93 10:03:08 GMT
From:      crawford@fido.econlab.arizona.edu (David W. Crawford)
To:        alt.unix.wizards,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Telnet re-routes?

In article <2393v5$eiu@agate.berkeley.edu> marco@remarque.berkeley.edu (Marco Nicosia) writes:

   Hi there --

	   I run a cluster primarily used by non-computer people. The cluster
   is called OCF, and we have different names for each of the machines. The
   problem is, so that the outside world can communicate with us, one of our
   machines is named, ``ocf.Berkeley.EDU''. 

	   What happens is that all of our newbies never read the instructions
   and simply say ``telnet ocf'' which of course, destroys that machine.
   So, right now we have a nologin with a message telling them to get a
   clue. However, this is not the best solution.

	   What I'd LIKE is for ocf to decide which computer is least
   loaded and shove the user's telnet over to that machine. However, I'd
   like to do this WITHOUT ocf becoming a big router for the entire
   cluster.

   (That'd be mis-using our resources, we have six ethernet connections.)

	   I don't know if ICMP re-directs are the right way to go, or if
   there is some way to build a reflector which will do it right, can
   somone tell me what to do/what to read in order to gain more info?

   -- 

   ______________________From the console of:______________________
   Marco E. Nicosia             marco@berkeley.edu
   marco@remarque.berkeley.edu  University of California @ Berkeley

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

So you disable direct connections to ocf and give users who attempt it
a message like I get when I try finger @ocf.

[ocf.berkeley.edu]

You have reached the University of California's Open Computing Facility (OCF)

This is Typhoon, otherwise known as OCF.Berkeley.EDU, an Apollo DN4500.
Typhoon cannot handle the amount of finger requests that the OCF receives.
Since we are a cluster of approximately 15 Apollo workstations, we ask
that you instead finger at one of our less loaded machines.
Some of those machines are:

Tornado, Sandstorm, Whirlwind, Tsunami, Avalanche, Planecrash,
Monsoon, Headcrash, Lightning, Bigbang, Whirlwind, Earthquake, and Locusts.

If you are trying to locate a user by Real Name instead of login,
finger no longer supports Last Name checks. Instead, try mailing
postmaster@OCF.Berkeley.EDU for name checks.

		Thank you for using the OCF. Have a nice day.

At the University of Arizona, we have three machines in the gas group.
Users can telnet to

	- argon.gas.uug.Arizona.EDU
	- helium.gas.uug.Arizona.EDU
	- neon.gas.uug.Arizona.EDU
	- gas.uug.Arizona.EDU

Since neon is a server for which login rights are not usually granted,
telnetting to neon won't be much use.  What's neat is that if I telnet to gas
I get sent to either helium or argon.   I know from experience that helium is 
a much busier machine than argon, so I always log into argon explicitly.

Hope this helps,

David Crawford
crawford@gas.uug.Arizona.EDU 

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 93 00:32:33 GMT
From:      sankar@ee.fit.edu (Sankar Ramalingam)
To:        comp.protocols.tcp-ip
Subject:   WILLING TO TAKE YOUR PROJECT AS MY THESIS




Hi Netters,
	

	I am a Graduate student at Florida Institute of Technology,
  Melbourne, Florida in the Department of Computer Science. I have good 
  exposure in X-Windows, MS-Windows, C++ and C. 


	I am planning to start my thesis by Fall '93 and finish 
  by Spring '94. I would like to do the thesis  wich involves
  Netwoking,Object Oriencted Programming, and X-Windows/MS Windows.
	I am also interested in Heterogenous Networks,Open Systems 
  and Client/Server Systems.

	If you have a project or if you know of any company which 
 has a project, which would involve one ore more of the above
 areas, I will be glad to do that project or be a part of the
 team wich does the project. 

	"I am not expecting any compensation". If the project requires
  new skills I will be glad to pick up.
	
  	My e-mail address is "sankar@ee.fit.edu", phone number is 
  (407) 984-2665.


Thanking You
(Sankaralingam. R)

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 02 Aug 93 03:43:41 GMT
From:      jbell@pdev.ga.oz.au (John Bell)
To:        comp.protocols.tcp-ip
Subject:   complex (to me) telnet query


Hi all,
	I need some advice re the behaviour of  telnet.  It appears to be
impossible to redirect  the standard input of a telnet session.

	ie.	telnet hostname < inputfile

	merely crashes with _Connection closed  by foreign host_.  This
presumably implies that one  cannot write a program that feeds input to
a telnet session launched by a daemon and captures its output (say via
pipes bound to the stdin/stdout of the telnet session)  Certainly, my efforts
to do so have come to nought.  I would dearly like 
to have a program which would allow my database software to engage in such
an "interactive" session.  Is this possible?  Is there something in the
public domain which can help me do this?

Thanks in Advance

John Bell
jbell@ga.oz.au

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 93 11:38:17 CST
From:      z_johnsta@ccsvax.sfasu.edu
To:        comp.sys.ibm.pc.programmer,comp.protocols.tcp-ip
Subject:   Telnet and Procomm

Here's the deal:

I am looking for a bit of software that (I know this sounds like a bit much)
replaces interrupt 14h with a program that either a.) sends/recieves TCP/IP
packets in such a manner that I can write a TELNET server on a UNIX box, or,
even better but much less likely, actually replaces the interrupt 14h with
a TELNET client, such that I can use Procomm Plus for Windows to access TELNET
services.

I am currently working on a special project here at the library that uses 
Procomm's scripting language (Aspect, take a look some time, it's extremely
powerful!) control/monitor access to various dial-up services.  Now that they
have the script, and I'm going to be leaving (and it would be a bad idea to
code something to replace what already worked), I need something that lets the
same Aspect script control/monitor TELNET sessions.  Currently, we use a
product by J&L that converts int 14h calls into IPX packets, which allows us to
use Procomm with the modem server on our network (Novell).   

If anyone has any idea as to where I can find such and animal, please let me
know!  Also, if I have to write the thing myself, the source to an already
existing TELNET client would be most helpful. If anyone knows where I can get
that source as well, please let me know.  

Please reply via E-Mail, as I only read a few of the groups to which I posted
this message.


                                    Thanks a bunch...
                                    -Timothy A. Johns

   

-------------------------------------------------------------------------------
:  Timothy A. Johns                 Z_JohnsTA@ccsvax.sfasu.edu                :
:  P.O. Box 16050 S.F.A.            Physics/Computer Science Undergraduate    :
:  Nacogdoches, TX  75962           Stephen F. Austin State University        :
:  Hm: (409) 560-1876               Wk: Yeah right...                         :
-------------------------------------------------------------------------------

-- 

-------------------------------------------------------------------------------
:  Timothy A. Johns                 Z_JohnsTA@ccsvax.sfasu.edu                :
:  P.O. Box 16050 S.F.A.            Physics/Computer Science Undergraduate    :
:  Nacogdoches, TX  75962           Stephen F. Austin State University        :
:  Hm: (409) 560-1876               Wk: S.F.A. Planetarium (409) 568-3009     :
-------------------------------------------------------------------------------

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1993 08:44:10 GMT
From:      asjl@cruskit.aarnet.edu.au (Andy Linton)
To:        comp.protocols.tcp-ip
Subject:   Re: rfc1475 - An argument for OSI ??

In article <1993Jul28.163012.41985@ucl.ac.uk> ccaajac@link-1.ts.bcc.ac.uk (Jon Crowcroft) writes:
>
>this is actively discussed on lots of lists, not the least
>big-internet@au.oz.munnari
>(send to big-internet-request@au.oz.munnari) and others specific to the various
>proposals
>

The Internet form of the list address is:

        big-internet@munnari.oz.au

and you'd be better sending requests to:

	big-internet-request@munnari.oz.au


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Aug 93 17:10:58 GMT
From:      bg54305@bgedu9.nho.hydro.com (Ola Hjollo)
To:        comp.protocols.tcp-ip
Subject:   SNMP - How should I remove hostname from return-address

In order to make things simpler, I am trying to remove the hostname
from the FROM part of a SNMP mail, like this:
	ola.hjollo@hosta.nho.hydro.com to
	ola.hjollo@nho.hydro.com (this should be the replay address
	known to the receiver).

I guess this could be done by use of a macro in the sendmail.cf, the
problem however is that I find the construction of macros a bit
hard to understand.  Any suggestions will be appreciated!! 

regards
ola hjollo

-- 



----------------------------------------------------------------------
Ola Hjollo
Communication Group
Norsk Hydro
E&P Operation, 5020 Bergen, NORWAY
Phone  : +47 55 996365 Fax: +47 55 996342 
P-Sok  : 096-71422
E-Mail : ola.hjollo@nho.hydro.com
----------------------------------------------------------------------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1993 14:54:47 +0200
From:      snoopy@munich.ixos.de (Snoopy)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Strange giant packets in a LAN


Hello dear Net,

I am encountering strange problems in my LAN (TCP/IP based, lots of
suns and NCD terminals).

I am getting lots of messages from the SUN consoles saying

"giant packet recived from <ethernet address>"

When I use arp -a etc. to find out who sends the packets, its very
strange: sometimes they emanate from a SUN, sometimes from an NCD X-Terminal
and sometimes from our Cisco-Router.

My question is: what is the most common cause for giant packets ?

The router does not seem to be the problem: non of our other subnets reports
these problems, so the router is obviously keeping things separate.

The giant packets seem to be bouncing around (why
should an X-terminal really ever generate one ??)

How can trace the REAL origins of such packets.

Sorry if I sound naive etc. but I am not really a LAN guru.

Any help is appreciated: please e-mail me, if there is enough
interest I will summarise.

Love,
Snoopy

-- 
uunet!unido!ixos!snoopy.schmitz -or- snoopy.schmitz@munich.ixos.de
"Every passing hour brings the solar system 43,000 miles closer to globular
cluster M13 in Hercules - and still there are some misfits who insist that
there is no such thing as progress." - Kurt Vonnegut Jr.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Aug 1993 19:46:02 GMT
From:      gerryw@hpwin052.uksr.hp.com (Gerry Winsor)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: SLIP or PPP for HP 9000 HP-UX?

jaakola@cc.helsinki.fi wrote:
: In article <CB06F6.r6@bunyip.cc.uq.oz.au>, sammut@durian.citr.uq.oz.au (David Sammut) writes:
: > jaakola@cc.helsinki.fi wrote:
: > : > Anyone know of a free compressed SLIP or PPP package for HP 9000 HP-UX?
: > : > 
: > : > I know, HP-UX has PPL, which is SLIP *without* compression.
: > : > 
: > : > Thanks.
 
: Anyone ever tried to port a free SLIP or PPP to HP-UX? Anyone know which
: package would be a suitable starting point?
: --
: Juhani Jaakola, jaakola@cc.helsinki.fi

Hi,  

I don't know of any FREE implementations ..... but in a reply to a similar
query to this, it was said that Morning Star Technologies were porting their
PPP product to HP-UX.  Contact Morning Star at sales@morningstar.com.  I don't
know the status of the port, nor the cost of the product, sorry.

Sorry I can't be of more help,
Gerry Winsor

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Aug 1993 20:35:35 GMT
From:      mchase@world.std.com (MICHAEL P CHASE)
To:        comp.protocols.tcp-ip
Subject:   PPP/SLIP FOR SYSV-4

 Hody Net,
  Could some kind soul(s) please tell me where I can find either PPP of SLIP
for SYSV-4, I would like for try both if someone knows where both could be
found..

Thanks In Advance

mchase@world.std.com



-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Aug 1993 23:46:39 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip
Subject:   Re: PPP/SLIP FOR SYSV-4

In <CB5FvE.7xF@world.std.com> mchase@world.std.com (MICHAEL P CHASE) writes:

>  Could some kind soul(s) please tell me where I can find either PPP of SLIP
>for SYSV-4, I would like for try both if someone knows where both could be
>found..

PPP does not appear to exist for Sys V r4. 

An adequate substitute for PPP on the UNIX box is to get a copy of 
KA9Q for DOS and use a PC as a router. KA9Q supports PPP. This 
solution works quite well, and offloads serial IO to another CPU.

SLIP is available from several archives. Check archie.

Dean
-- 
  /`-_                                 
 {     }/  Dean.Roth@MIXcom.com         
  \   */   Milwaukee, Wisconsin, U.S.A. 
   |___|                                

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 02:08:34 GMT
From:      pz@modtor.uucp (Peter Ziobrzynski)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP/SLIP FOR SYSV-4

mchase@world.std.com (MICHAEL P CHASE) writes:

> Hody Net,
>  Could some kind soul(s) please tell me where I can find either PPP of SLIP
>for SYSV-4, I would like for try both if someone knows where both could be
>found..

You can try is in ucsd.edu (128.54.16.1)

/hamradio/packet/tcpip/incoming/svr4-wampes-readme
/hamradio/packet/tcpip/incoming/svr4-wampes.tar.Z

it is ka9q port to HPUX then to SVR4.

There is also George Thomas,16/232,47106,5531 (thomas@itd.nrl.navy.mil)
PPP for esix 4.0. You can get it by:

echo help | mail mailserver@hawkmoon.mn.org
echo get unix/src/ppp-for-esix-4.0.cpio.Z | mail mailserver@hawkmoon.mn.org

>Thanks In Advance
 
>mchase@world.std.com

- peter

-- 
Peter Ziobrzynski, pz@modtor.uucp, pz@promis.com, Toronto, Ont. Canada

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 02:24:07 GMT
From:      harvey@vax.cns.muskingum.edu (Ryan Harvey)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Giant Packets?


I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
for our Macs and PCs on campus.  I am getting an error which I am not sure
what it means.  Below is the message I have in my error file:

Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared

where the xx-xx-xx-xx-xx-xx is a valid ethernet address.  It looks to me like
I have a board (actually multiple boards and quite often) which is sending
out "something" that the ethernet board in my sparcstation does not like.
Is anyone familiar with this error?  What causes it?  Any suggestions are
welcome!

Thanks,

Ryan Harvey
HARVEY@VAX.CNS.MUSKINGUM.EDU

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1993 02:32:12 GMT
From:      chitra@cs.sunysb.edu (Chitra Venkatramani)
To:        comp.protocols.tcp-ip
Subject:   IP error characteristics

Hi!

I'm looking for some program (ftp-able preferably) to measure the error
characteristics of IP. I want to use raw sockets, bypassing
TCP, exchange packets between machines on a lan and measure
the error characteristics. 

Or is such data already available some place ?

Any help will be appreciated.

Thanks in advance,
chitra@sbcs.sunysb.edu

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 93 04:11:34 GMT
From:      bhoule@npg-sd.SanDiegoCA.NCR.COM (Bill Houle)
To:        comp.protocols.tcp-ip
Subject:   RIP and Class B subnets


We have an 8-bit subnetted Class B remote site hanging off 
our Netblazer dialup router.  Meanwhile, the rest of this Class B
(and the rest of the "world", for that matter) is assumed to hang
off another router as part of our Internet connection and default
route:

 "Internet" -------------  Wellfleet --------  Netblazer  -+-+-  remote
 153.67.1.2         153.67.1.1  153.67.2.1     153.67.2.2        153.82.36.1

We assumed that the Netblazer RIP of 153.82.36 would route 153.82.36
traffic through the 'blazer, while other stuff (eg, 153.82.3) would
drop back to the default route thru the "Internet".  What we are
seeing instead is that the Wellfleet is turning the 153.82.36.0 RIP
into 153.82.0.0.  The end result is that 153.82.36 traffic is routed
correctly, but to any other 153.82 site it just bounces between the
Wellfleet and the Netblazer going nowhere.  There are no other
"conflicting" RIPs; the only RIPs we generate are the Netblazer's
remotes and our internal 153.67.x subnets.

We think this "mangling" of 153.82.36 RIP into 153.82 is incorrect.
Wellfleet says it is normal behavior.  Who's right?  (BTW, what RFC
describes proper RIP behavior?)

--
Bill Houle                    bhoule@npg-sd.ScrippsRanchCA.NCR.COM
NCR NPD-San Diego             (619) 693-5593

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1993 14:06:38 +1000
From:      panissec@nms.otc.com.au (Colin Panisset)
To:        alt.unix.wizards,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Telnet re-routes?

marco@remarque.berkeley.edu (Marco Nicosia) writes:

}Hi there --
 
}	I run a cluster primarily used by non-computer people. The cluster
}is called OCF, and we have different names for each of the machines. The
}problem is, so that the outside world can communicate with us, one of our
}machines is named, ``ocf.Berkeley.EDU''. 
 
}	What happens is that all of our newbies never read the instructions
}and simply say ``telnet ocf'' which of course, destroys that machine.
}So, right now we have a nologin with a message telling them to get a
}clue. However, this is not the best solution.

One extremely simple (and portable) solution is to rewrite the instructions
so that newbies realise to use different machines. This has the
added advantage of providing an introduction (if an extremely basic one)
to the concept of networked machines. 

I'm aware that this isn't what you're looking for, but from the sounds of
it, the fault is in the instructions rather than in the cluster setup. 

--
  Colin Panisset *:^) +61 2 339 3938 | "It is important to keep an open 
       panissec@nms.otc.com.au       |  mind, but not so open that your 
  So There.      Fax: +61 2 339 3818 |  brains fall out." 
  ------------------ PGP 2.3 key available on request. ----------------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 93 07:26:13 GMT
From:      claude@bauv.unibw-muenchen.de (Claude Frantz)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:

>I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
>for our Macs and PCs on campus.  I am getting an error which I am not sure
>what it means.  Below is the message I have in my error file:
 
>Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
>Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
 
>where the xx-xx-xx-xx-xx-xx is a valid ethernet address.  It looks to me like
>I have a board (actually multiple boards and quite often) which is sending
>out "something" that the ethernet board in my sparcstation does not like.
>Is anyone familiar with this error?  What causes it?  Any suggestions are
>welcome!

Some diagnose programs send such packets. Perhaps it is the case at your
site.

--
Claude F.

This message may contain opinions which are not shared by my employer.
The facts can speak for themselves.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1993 07:40:13 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: RIP and Class B subnets

In article <6364@npg-sd.SanDiegoCA.NCR.COM>
bhoule@npg-sd.SanDiegoCA.NCR.COM (Bill Houle) writes: 
    
    We have an 8-bit subnetted Class B remote site hanging off 
    our Netblazer dialup router.  Meanwhile, the rest of this Class B
    (and the rest of the "world", for that matter) is assumed to hang
    off another router as part of our Internet connection and default
    route:
    
     "Internet" -------------  Wellfleet --------  Netblazer  -+-+-  remote
     153.67.1.2         153.67.1.1  153.67.2.1     153.67.2.2        153.82.36.1
    
    We assumed that the Netblazer RIP of 153.82.36 would route 153.82.36
    traffic through the 'blazer, while other stuff (eg, 153.82.3) would
    drop back to the default route thru the "Internet".  What we are
    seeing instead is that the Wellfleet is turning the 153.82.36.0 RIP
    into 153.82.0.0.  The end result is that 153.82.36 traffic is routed
    correctly, but to any other 153.82 site it just bounces between the
    Wellfleet and the Netblazer going nowhere.  There are no other
    "conflicting" RIPs; the only RIPs we generate are the Netblazer's
    remotes and our internal 153.67.x subnets.
    
    We think this "mangling" of 153.82.36 RIP into 153.82 is incorrect.
    Wellfleet says it is normal behavior.  Who's right?  (BTW, what RFC
    describes proper RIP behavior?)
    
Assuming the above is complete and correct, Wellfleet is correct.  The
Netblazer is broken.  RIP does not allow you to advertise a subnet across
another network.  RIP is described in RFC1058.  The relevant text:

   "In order to avoid this sort of
   ambiguity, hosts must not send subnet routes to hosts that cannot be
   expected to know the appropriate subnet mask.  Normally hosts only
   know the subnet masks for directly-connected networks.  Therefore,
   unless special provisions have been made, routes to a subnet must not
   be sent outside the network of which the subnet is a part."

Tony



-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 93 12:37:20 GMT
From:      jah@Materna.DE (Joerg Hattenhauer)
To:        comp.protocols.tcp-ip
Subject:   Problems with LANWorkPlace 4.1


We need some help with some strange problems running novells 
LANWorkPlace 4.01/4.1 in a Windows 3.x environement. If a
tcp connection is closed with a RESET by the foreign host
the socket is closed imideatly by the protocol-stack and
occures as a "bad filedescriptor" to the application. Now if
this RESET to one connection is followed by a new SYN the
socket will be released and reused for a new connection.
Just because this application uses the synchronous interface
it will never see the "old" socket closed and will use the
socketdescriptor two times.
This happens very often in our environement cause of the host
operating-system SINIX 5.4 which often closes a connection just
by RESET.

We think the descriptor should not be released but kept in the
state "connection reset by peer" until the application closes 
the socket.

Does anyone know a solution or just a workaround for this
Problem?

Thank you,


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1993 12:21:47 +0100
From:      mathew@mantis.co.uk (mathew)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:
>I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
>for our Macs and PCs on campus.  I am getting an error which I am not sure
>what it means.  Below is the message I have in my error file:
 
>Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
>Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
 
>where the xx-xx-xx-xx-xx-xx is a valid ethernet address.  It looks to me like
>I have a board (actually multiple boards and quite often) which is sending
>out "something" that the ethernet board in my sparcstation does not like.
>Is anyone familiar with this error?  What causes it?  Any suggestions are
>welcome!

I have exactly the same problem.  Only one of the machines in the office
produces these "giant packet" warnings, and it only does it when it
boots up in the morning.  The Ethernet card is an NE2000 clone, just
like in all the other machines, but from a different manufacturer to all
the others as it was supplied with the machine.

I have no idea what exactly is going on, but it seems to have no ill
effects whatsoever, so I just ignore it.


mathew

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1993 14:22:16 GMT
From:      rocket@wam.umd.edu (Yellow Panther)
To:        comp.protocols.tcp-ip
Subject:   error control code


I would like to know what type error control code does the networks use, and
is there a better alternative code to use? I don't know if this question
belongs in this newsgroup, but I would appreciate it if anyone who knows
will mail me at rocket@wam.umd.edu. Thanks again.

chu (rocket@wam.umd.edu)



-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 14:43:04 GMT
From:      g88m0396@alpha.ru.ac.za (Jon-Dean Mountjoy)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

In <23lhob$ktp@news.mantis.co.uk> mathew@mantis.co.uk (mathew) writes:

>harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:
>>I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
>>for our Macs and PCs on campus.  I am getting an error which I am not sure
>>what it means.  Below is the message I have in my error file:
 
>>Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
>>Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
 
>>where the xx-xx-xx-xx-xx-xx is a valid ethernet address.  It looks to me like
>>I have a board (actually multiple boards and quite often) which is sending
>>out "something" that the ethernet board in my sparcstation does not like.
>>Is anyone familiar with this error?  What causes it?  Any suggestions are
>>welcome!
 
>I have exactly the same problem.  Only one of the machines in the office
>produces these "giant packet" warnings, and it only does it when it
>boots up in the morning.  The Ethernet card is an NE2000 clone, just
>like in all the other machines, but from a different manufacturer to all
>the others as it was supplied with the machine.
 
>I have no idea what exactly is going on, but it seems to have no ill
>effects whatsoever, so I just ignore it.

We get them here too, but they do seem to have an effect on our
386BSD boxes.  They terminate them!! (and we have to reboot afterwards)

J-D
--
-------------------------------------------------------------------------------
     Jon-Dean Mountjoy        csjm@beta.ru.ac.za         Rhodes University
			The views herein are my own
		      and not those of the institution

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 14:51:23 GMT
From:      mark@mark-one.inet-uk.co.uk (Mark Powell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.sys5.r4
Subject:   Can two class C networks have one primary DN server?

We have two class C networks. We'd like to set up our zone to encompass
both of these networks. I'd just like to know if this is possible, before
I start wasting time. I can't seem to find any examples of how to do this.
They all assume a class B network. 
Thanks in advance.

-- 
Mark Powell

mark@inet-uk.co.uk		uunet!ibmpcug!jshark!mark-one!mark
jshark!mark-one!mark@ibmpcug.co.uk	Work:	+44 61 745 3207

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1993 15:17:58 GMT
From:      edm@curly.coe.uga.edu (Ed Maioriello)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Does Novell IP do ARP different?

Hi,

I saw a funny thing the other day and I was hoping someone might know
what's going on.  We did a sniffer trace of some telnet sessions on both
the ethernet and Token-Ring sides of an IBM 8209 Lan Bridge.  Token-Ring
connected PC running CUTCP on one side, Sun 3/80 and Netware server
running IP on the ethernet side.  

When the PC arps for either the Sun or the NW server (to start an ftp
session) it uses a Token-Ring_snap frame on the TR side, this was being
repeated as both an ethernet v.2 and ethernet_snap frame on the other
side.  In both cases the source routing info appeared identical, and
both happily negotiated a maximum frame size of 1470 bytes in the RI
header. Both enet stations also responded to the arp with a version 2
frame, this is the only kind the NW server is configured to use for IP.

Now for the funny part, upon receiving the arp reply from the SUN the 8209
continued to use v.2 framing to talk to the sun, but it would use only
ethernet_snap frames to talk to the NW server, despite the fact that it
replied using v.2 framing as well.

The only difference I saw between the two arp replies was the SUN used
all zeros padding and the NW server used non-zeros padding.  The NW
server had an ethernet_snap board defined (for AppleTalk) but with no
protocol's bound to it.

Anyone got any ideas.

Thanks,

Ed Maioriello		       		            edm @ harpo.dev.uga.edu
University Computing & Networking Services   	    edm @ aisun1.ai.uga.edu
University of Georgia  ----------------------------------------------------
Athens, Ga. 30602      | First Rule of Troubleshooting: 
(706)-542-6462         |                     If it don't work - plug it in! 



-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 15:55:43 GMT
From:      aba@abacus.be (Tony Badcock)
To:        comp.protocols.tcp-ip
Subject:   Help! Telnetd problems

I have a SCO UNIX machine running version 3.2 2 (as reported by uname -a) and
I have installed SCO TCP/IP release 1.2.Oi along with a Dlink DE220 ethernet
card and driver.

I am able to telnet to other hosts but all hosts trying to telnet to me receive
the message:

    telnetd: All network ports in use.

The same occurs if I try telnet from my host back to itself. I have changed 
nothing in the /etc/services file and seems apparent from the message returned
that the telnetd daemon does start but gets no further.

Other tcp services into my host work without problems (ftp, finger, rsh, rcp,
etc.) but rlogin gives a similar error message.

Can anyone throw any light on this problem ?

Tony Badcock
aba@abacus.be

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 16:00:05 GMT
From:      hnatara@eng.clemson.edu (hari natarajan)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN as bridge? arpserve under solaris



I am looking for some info when a tcp_ip layer is on top of an atm layer. I want to know what is the standard length of a packet made up of recombination of atm cells.
Any info on this would be appriciated. 
 You could contact me at ; 
 -------------------------------------------  
        hnatara@eng.clemson.edu
-------------------------------------------------        




-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 16:15:56 GMT
From:      dayna@tigger.jvnc.net (Dave Scott)
To:        comp.sys.mac.comm,comp.sys.mac.hardware,comp.protocols.tcp-ip
Subject:   Re: Help! DaynaPORT SCSI/Link and NCSA Telnet

In Article <1993Jul29.183346.1@vax1.tcd.ie>, crtchlym@vax1.tcd.ie wrote:
>Re. DaynaPORT SCSI/Link ethernet adapter and NCSA Telnet
>
>I have just brought a DaynaPORT SCSI/Link ethenet adapter for a Powerbook
>170.  I have no problems using this with EtherTalk for connection to 
>a mac server, but I'm having problems with using NCSA TCP/IP program
>
>The NCSA (version 2.5.1) has a setting in it's configuration file for
>hardware type - i've set this to hardware=EtherSC for a SCSI ethernet 
>adapter.
>
>Starting NCSA Telnet the program attempts to connect to the ethernet, then
>crashes (Macsbug shows userbreak at 000F2442 drvrCtl+096E).
>
>Is the DaynaPORT SCSI/Link adapter compatible with NCSA Telnet, if so
>are there some other settings that should be changed in NCSA configuration
>file?
The SCSI/Link is compatible with Telnet.  You should verify the ROM version
you have in the SCSI/Link.  The current shipping version is 1.4.  If you
don't have this version, contact Dayna Technical Support for information on
how to upgrade your SCSI/Link.  You should also verify that you have the
latest driver software which is v7.5.2.  If you don't have the latest
driver, you can download it from Dayna's BBS at (801) 269-7398.
>
>If not comaptible, what other Telnet/FTP programs work with the DaynaPORT
>or      what other SCSI Ethernet adapters work with NCSA Telnet
>
We have also successfully tested TCP Connect from InterCon.  If you have any
other questions, feel free to contact myself or one of our Technical Support
reps at (801) 269-7200.

- Dave Scott
  Dayna Product Testing

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 93 17:54:22 GMT
From:      hartman@gradient.cis.upenn.edu (Michael S. Hartman)
To:        comp.protocols.tcp-ip
Subject:   [Q] Bootp: booting through gateways

Has anyone implemented (the optional) section 8 ``Booting Through Gateways''
of Bootp RFC 951 who would be willing to provide the source?


Thanks,

Mike Hartman			e-mail: hartman@gradient.cis.upenn.edu

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 18:00:12 GMT
From:      sxa6295@ucs.usl.edu (Abburi Srinivas)
To:        comp.protocols.tcp-ip
Subject:   Need info.

	I need some info. on sockest system calls. I have an user 
account (SUN work station) and trying to execute a sample program
based on client-server model. 

I am facing the problems with socket binding to server. When I called
bind system call with address set to INADDR_ANY, the system prints a
message " Can't bind to local address. ". I checked both the server and
client addresses and are correct. Your help in this is highly appreciated.
Please send responses to sxa6295@ucs.usl.edu

Thank you

sxa6295@ucs.usl.edu




-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 20:10:11 GMT
From:      dpm@wixer.bga.com (David Maynard)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:
>I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
>for our Macs and PCs on campus.  I am getting an error which I am not sure
>what it means.  Below is the message I have in my error file:
>Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
>Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared

I haven't seen this in awhile, but it used to be a fairly good indication
of either a cabling or a transceiver problem.  If the ether segment isn't
too big then it's probably worth checking all of the connections.  If all
of the PCs and Macs live on it then maybe it's being caused by one of them
rebooting as mentioned in another post.

-David

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

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 20:56:55 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

Could it be possible there is a mix of Ethernet and 802.3 frames out
there on the wire?  I understand the type and size fields are interchanged
between these.


-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 21:08:15 GMT
From:      pmfranc@afterlife.ncsc.mil. (Paul M. Franceus)
To:        comp.protocols.tcp-ip
Subject:   Help:  Has anyone gotten IP multicast routing working on an Auspex.

Hello all-

I am wondering if anybody has gotten multicast routing working on 
an Auspex file server?  Is is any different than on a normal Sun
due to the special hardware and OS on the Auspex?


Thanks,

Paul Franceus
pmfranc@afterlife.ncsc.mil

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 21:14:34 GMT
From:      shah@ct.picker.com (Nikhil Shah)
To:        comp.protocols.tcp-ip
Subject:   Multibus-II driver for TCP/IP n/w interface

I am trying to find out if someone has implemented
(or tried to implement) TCP/IP on Multibus-II. For
certain h/w and timing limitations, an extra Ethernet
bus on a system that already has Multibus-II, may
turn out to be expensive.
(Someone did suggest that broadcast may be a problem).
Thanks in advance...
-Nick Shah (shah@ct.picker.com)





-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 93 22:34:01 GMT
From:      kevin@execu.execu.com (Kevin English)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.programmer,comp.unix.questions,comp.unix.wizards
Subject:   Transport Independent Message API

Does anyone know of a commercial transport independent message api that
supports at the very least APPC, WinSock, BSD Sockets, and NetBIOS ?  We
have designed such a beast that sends variable length messages over a
perceived full duplex channel but would prefer to buy rather than build.
An application can Listen for a connection, Connect, Send and Receive, all
in an asynchronous fashion with callbacks registered to process the
completion of the events.  Support for LU2 and DECnet may also be required.

Please respond to me directly, as I don't currently read most of these 
news groups.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Aug 1993 23:43:51 GMT
From:      sundaram@suspicion (Subbiah Sundaram)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Sample programs  - NFS

Hi,
I want to write a test program which will read  a file from a 
NFS server directly. I require the directory handle and the file name
for that. As far I know I can get the file handle only by performing
the MOUNTPROC_MNT client rpc call. I have not been successful in 
making the call work. I have been getting errors like file or directory
not found and permission denied. It would be nice if some one could
send me a sample program using these functions.

Subbiah

-- 
ASDFASDFSFDASFD

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 00:14:58 GMT
From:      hashmi@netcom.com (Atiq Hashmi)
To:        comp.protocols.tcp-ip
Subject:   Can we send attachments over smtp ?



Hi netters,

We have IBX RS/6000 AIX 3.2
I am writing an email program(call it my_mail) in which I have to
generate email files in the smtp format. This email prog. is not
interactive i.e. nobody will not use it directly, rather the email msg.
contents are stored in files and I will use them to format my smtp
emails. The email will consist of both ascii text and attachments
(which could be binary).  The ascii text is stored in a file and the
attachments (1 or more ) are stored each in a different file.

If it was only ascii text, it was straight.
Now, how should a single email be prepared from these ascii and binary
files:

-should my_mail uuencode the attachment files (because email will
will pass through smtp-x400 gateway) and then just concatenate the text and 
all attachments and submit to sendmail.

- Or I don't need to uuencode and I should just concatenate all files 
and submit to sendmail.

- Or THere is some standard way of handling this.

Similarly, how will attachments arrive to my unix box
- in one big file with both ascii and attachment stuff ?. How can they
be seperated ?.
- in multiple files?. How is that handled ? 

Any pointers ?
Kindly reply directly and save net bandwidth. 

Atiq Hashmi
-- 
----------------
Atiq Hashmi
hashmi@netcom.com

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 02:15:24 GMT
From:      scottta@cray.com (Scott Taylor (X3743))
To:        comp.protocols.tcp-ip
Subject:   RFC 1323 Question (sequence space wrapping)


At the bottom of Page 5 in RFC 1323, in regards to sequence space wrapping
on high speed TCP networks, it says:


    More specifically, if the maximum effective bandwidth at which TCP
    is able to transmit over a particuliar path is B bytes per second,
    then the following constraint must be satisfied for error-free
    operation:

        2**31 / B  > MSL (secs)


My question is, why isn't it:

        2**32 / B  > MSL (secs)

which would represent the whole sequence space (2**32).  Why does it insist
that I cycle through *half* the sequence space no faster than one MSL?  Seems
to me as long as I dont cycle through the *entire* sequence space in less
than one MSL, everything would be cool.  What am I missing?

Thanks in advance.


Scott
-- 
You tried and tried                     |    Scott Taylor
But you're a flop                       |    Cray Research Superservers, Inc.
You're 35                               |    scottta@cray.com
Still pushin' a mop  - Ramones          |    (619) 625 3743 FAX (619) 625 0641

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 04 Aug 1993 03:41:44 GMT
From:      blane@c-mols.siu.edu (Brian Lane)
To:        comp.protocols.tcp-ip
Subject:   Trying to set up a SLIP server on dos/win.

I have a friend that is trying to setup a machine with SLIP dialin and pass
the info to token ring network.  We can get the machine to get out onto the
net from the token ring.. but he want sto be able to access the internet from
home using SLIP.  What software can do this if any? thanks a lot... he
really wants to get this going I am trying to help him out.. thanks again!


Brian


-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 93 03:55:04 GMT
From:      wessel@boer.ee.up.ac.za (Wessel du Preez)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:

> I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
> for our Macs and PCs on campus.  I am getting an error which I am not sure
> what it means.  Below is the message I have in my error file:
 
> Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
> Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
 
> where the xx-xx-xx-xx-xx-xx is a valid ethernet address.  It looks to me like
> I have a board (actually multiple boards and quite often) which is sending
> out "something" that the ethernet board in my sparcstation does not like.
> Is anyone familiar with this error?  What causes it?  Any suggestions are
> welcome!
 
We had the same thing on our Sparcs a while ago (when they were still
on our campus backbone).  The giant packets came from
ff:ff:ff:ff:ff:ff, though. Sometimes the send address would be
'almost' ff:ff:ff:ff:ff:ff, as in ff:ff:df:fa:ff:ff.  This would
happen during business hours only, never over weekends.  (This
supports the theory that broken Ethernet cards send these packets when
their host PC's are switched on--see include summary.)  I actually
caught some of these packets with a Sniffer, and their send address
was indeed ff:ff:ff:ff:ff:ff, and they were between about 1600 and
2200 bytes long.

Our problem was solved when we moved the machines off the backbone :-)

I have gathered some postings on the giant packet issue, but
unfortunately I have a very poor sense for stringing these together
into something sensible.  What I include here is (I think) a summary
posted by someone else a while ago (I might have edited it myself as
well.) Maybe someone with a bit more editing talent than I will make
us an entry for comp-sys-sun-faq?

======================================================================
       Start of many edited postings on giant Ethernet packets
======================================================================

From: swlodin@kocrsv01.delcoelect.com (Steve Lodin)
Subject: Re: giant packet
Date: 9 Oct 92 13:36:31 GMT


I'll take this one :-)

I'd like to think that every time we get one of those messages, it's
because an Intergraph workstation just rebooted.

Here are the results from the rest of the net...


[saved from a previous posting]


Thanks to everyone who responded on my question about giant packets.
It seems that the problem is most likely related to bad equipment on
the network.  We talked to Cabletron (our main network hardware
supplier), and they have loaned us a network monitoring package to help 
us track down the problem.

Here was the original question:

We keep geting this message on one of our sun4/330 server consoles:

        le0: Receive: giant packet from 8:0:20:0:f:3c
        le0: Receive: STP in rmd cleared

The ethernet address varies.

What does this mean, and what can we do about it?  We have been experiencing
severe network problems (timeouts, etc).  Is this related and/or the cause?

And the responses:

------------------------
From:   Andrew Luebker <asuvax.eas.asu.edu!eye.psych.umn.edu!aahvdl>

Do you have any micros on your network?

I sometimes see those messages when micro users run the
test programs on the diagnostics floppy shipped with
3com 3c501/3c503 boards for the IBM's and clones...

[Yes, we do and we are looking into this. - Rod]
-----------------------------
>From asuvax.eas.asu.edu!csis.dit.csiro.au!geoff 

        I would be very interested to get a summary of responses to your request as I have the same problem here!

        It has of late "gone away", this has been since we put a bridge in 
the network. Our scenerio was poor network performance, lots of NFS not 
responding messages high Input/Output error rates a network average collision 
rate of 3-4% but some hosts up to 12%.

        Since I put the bridge in it has essentially reduced all of the above.
I'm sure that there is a physical problem on the net causing all of the above 
but finding out where it is, is turning out to be a real battle.

        Anyway I still have no idea what causes the messages you described 
(but would like to as it may point to our problem).

----------------------------
From:   asuvax.eas.asu.edu!spdev.East.Sun.COM!tgsmith (Timothy G. Smith - Special Projects)

TFM [ le(4s) ] says:

     le%d: Receive: STP in rmd cleared
               The driver has received a  packet  that  straddles
               multiple  receive  buffers  and therefore consumes
               more than one of the LANCE chip's receive descrip-
               tors.   Provided that all stations on the Ethernet
               are operating according to the Ethernet specifica-
               tion,  this error "should never happen," since the
               driver allocates its receive buffers to  be  large
               enough  to  hold  packets of the largest permitted
               size.  Most likely, some other station on the  net
               is  transmitting  packets whose lengths exceed the
               maximum permitted for Ethernet.


The first message means that a packet came in that was over 1588 bytes
long.  (1588 = 1536 Ethernet MTU + 4 CRC + 48 overrun space) This
shouldn't happen on an Ethernet.

The second message is a result of the first.  A "rmd" is a Recieve
Message Descriptor.  STP is the Start of Packet bit.  The second
message means that the chip returned a buffer that didn't have the STP
bit set.  The lance chip will automatically chain buffers together if
neccessary.  It should never be necessary to chain buffers since the
driver always allocates 1588 byte buffers.  The buffers were chained
because the frame coming in was over 1588 bytes so the chip started
stuffing data into the next buffer.

What all of this really means is that the machine is seeing long
frames.  Your network is broken.  Might be a broken host, xcvr,
repeater, sun spots, or whatever.  Break out the sniffers.

---------------------------
From:   asuvax.eas.asu.edu!sunne.East.Sun.COM!stern (Hal Stern - Consultant)

the sun ethernet drivers (ie and le) use a fixed-size buffer
for receiving packets.   the buffer is big enough to hold a
single maximum sized packet.   if the chip receives a packet
that is larger than the maximum defined for the ethernet, it
copies it into two buffers -- the packet sort of "hangs over"
the edge of the first buffer.

the "giant packet" received message indicates that a packet
larger than the buffer was received.  the STP message (you
may also get ENP messages) is a side-effect of the buffer
overflow.  each packet has a start and end of packet bit.
normally, they should both be set.  but when a packet overflows
into the next buffer, that bit gets a random value -- whatever
bit from the giant packet happens to fall on it.  so sometimes
the STP bit will be set to 0 - a "can't happen" with a legal
ethernet packet.

the ethernet address 8:0:20 belongs to a sun.  could be that
(a) your ethernet is too long
(b) you have a branch, T- Y- or other illegal topology in
        your network, particularly if you're using thinnet
(c) you have a bad transceiver

you might want to put a sniffer on the wire to see what
the giant packets look like -- are they noise or two
valid packets that got glommed together

---------------------------
From:   asuvax.eas.asu.edu!NMSU.Edu!jeff (Jeff Harris)

Another place to watch out for is at people with 3Com interface cards in 
their PC's.  When using the diagnostic disks that used to come with the 
cards (I haven't checked lately), one of the tests would cause giant 
packet errors.  The directions clearly state not to run that particular 
test on a running network, but how many people actually read docs :-)

The test generated packets that seemed to generate packets whose entire 
contents (including src and dest fields) alternated between a random 
value and 0, so packet contents loooked like 

AA-00-AA-00-AA-00-AA-00-AA...

When you start to parse the packet, and get to the length field, you can 
obviously get some really bizzare results.  And to make life more 
interesting, the packets do not have valid source addresses, so they are 
particularly fun to track down.

-------------------------------
From:   asuvax.eas.asu.edu!amil.co.il!leonid (Leonid Rosenboim)

This is a guess because I dont have a 330 nor have I ever seen such a
message but it might help:

The maximum Ethernet packet size (including header) is 1538 bytes, as
specified by the standard. Practically various Ethernet chips can be
programmed for a larger packet size which would be rejected by the
destination node if it was not midified accordingly, but I never heard
of enybody doing such bad things.

Since the Ethernet address changes, and they look like legitimate Sun
addresses (8:0:20:...), this is a different case. I think that you have
serious electrical problems on your Ethernet wire, or in your low-level
ethernet equipment (transceivers, repeaters, fan-outs etc.). But since
you did not elaborate on the type of media you are using, there is very
little I can add. You may howevery try to deduce the source of the
problem by either:

1. Gathering the different ethernet addresses and guessing the
particular area, 2. try to replace some of the low-level stuff that you
suspect 3. divide your network into subnetworks for testing ala binary
search 4. get a LAN analyzer and do it by the book.  5. call a
consulting company for help

I would like to hear about your progress however, because I like to
help people.


-- 
Steve Lodin     Internet: swlodin@kocrsv01.delcoelect.com  UUCP: deaes!swlodin


                "So much news, so little time."
From: andr@elvis.sovusa.com (Andrei Arkhipov)
Subject: Re: giant packet
Date: Fri, 9 Oct 92 18:45:19 GMT

In <KAM.92Oct8090407@moe.tulmath.math.uno.edu> kam@tulmath.math.uno.edu (Katherine Hosch) writes:
>
>>Sorry if this is a FAQ -- I'm sure I have seen reference to it in the past, 
>>but then I didn't have the problem!  I have a smallish network of (mostly)
>>Suns, and they are forever complaining that, e.g.:
 
>>Oct  6 14:42:22 moe vmunix: le0: Receive: giant packet from ff:ff:ff:ff:ff:ff
>>Oct  6 14:42:22 moe vmunix: le0: Receive: STP in rmd cleared
>>Oct  6 14:42:22 moe vmunix: le0: Receive: giant packet from ff:ff:ff:ff:ff:ff
>>Oct  6 14:42:22 moe vmunix: le0: Receive: STP in rmd cleared
 
>>Would someone please tell me the fix?
 
>>Thanks!
 
>>-- katherine hosch

Is Ethernet address really has all "ff"? I saw the same but there was real Ethernet address of
one of computers at network. 

And, yes, I'd want to know the origin of this message, too.

Andrei.

======================================================================
			End of edited postings
======================================================================

--
Wessel du Preez                    email:  wessel@boer.ee.up.ac.za
                                   Phone:  +27 12 841-2807 
                             	     FAX:  +27 12 868803 (for my attention)

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 93 04:36:40 GMT
From:      martind@nsg.nsg.com.au ( NSA)
To:        comp.protocols.tcp-ip
Subject:   TCP PUSH

I am presently hacking through a piece of code which prints to a terminal
server attached printer.
When we print graphics files,like those associated with HP laserjets, I need
to cater for the Telnet IAC option being in the data stream, and I do, by 
duplicating it into the output stream.

I now want to do a TCP PUSH of the stream, so that tcp forces whatever
it has in its buffers onto the other side.

How in an application program do I do a TCP PUSH. An example piece of code
would be kinder than a reference to RTFM, since I've already tried that..

Thank you
-- 
Martin P Drenovac             PHONE: (612) 415-0500
                              FAX:   (612) 417-8635
			      EMAIL: martind@nsg.oz.au
GEC Alsthom I.T. 	      UUNET: !uunet!munnari!nsg.oz.au!martind

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1993 14:59:31 -0500
From:      tumlin@cs.utexas.edu (Evelyn Tumlin)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   More troubles with UUCP over TCP/IP

I recently set up UUCP to operate over TCP/IP on my cluster of
AT&T workstations (two StarServers and two 386's).  The trouble
is that any attempt by either StarServer to contact either 386
fails with the message "Incorrect address format".  (I'm using
/usr/lib/uucp/Uutry, by the way.)

As per the instructions in the manual, I entered the output of
"rfsaddr -h <name>" in the address field of Systems.tcp.  There
is no question of a typo, and the format is the same as for
the addresses which are working.

Has anyone seen this problem before?

Thanks,
  -- Lyn Tumlin (tumlin@cs.utexas.edu)

[I know about .sigs, but I don't use 'em. ;-) ]

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1993 15:02:51 -0500
From:      tumlin@cs.utexas.edu (Evelyn Tumlin)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Two machines out of TCP/IP contact

Hi, it's me again, with the AT&T workstation cluster.  (Two 
StarServers, two 386's).  This problem is simple to state:
the two 386 machines won't talk to each other over TCP/IP.
The problem appeared recently, and has lasted through several
reboots.  Telnet, rlogin and ftp are all affected.

Both machines can talk to any other machine, and can be contacted
by any other machine.  They just aren't speaking to each other.

Help!!!!????!!!

Thanks,
  -- Lyn Tumlin (tumlin@cs.utexas.edu)


-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 09:58:38 GMT
From:      tomasz@maths.tcd.ie (Tomasz Wolniewicz - Visiting)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.sys5.r4
Subject:   Re: Can two class C networks have one primary DN server?

mark@mark-one.inet-uk.co.uk (Mark Powell) writes:

>We have two class C networks. We'd like to set up our zone to encompass
>both of these networks. I'd just like to know if this is possible, before
>I start wasting time. I can't seem to find any examples of how to do this.
>They all assume a class B network. 
>Thanks in advance.

As far as I can tell the domain to number mapping is very flexible.
All that needs to be done is setting up a domain (by a nameserver entry in
the domain above you) Then you just map individual names to numbers. They
can be anything. Having domains organized in single classes is easier for
routing and reverse mapping (numbers to names), but everything can be taken
care of withut too much trouble.

Tomasz

tomasz@maths.tcd.ie
-- 
Tomasz

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 14:08:07 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Timers

I have two question about TCP/IP timers.  These are as follows:

1.  During the connection phase, the timeout period can be be almost 4 minutes
before one gets a reply back indication the unavailability of the host machine.  
I was wondeering if there is a way to reduce this time without having to make a
kernel change.  I am currently working on Unix V.4.2.  I have found out that
there exists a time, called LINGER time, which is approximately 4 minutes, and
thus it takes so long for it to return if a host is unavailable?

2.  On a receive, or send, if there is a line failure, then I have seen that it takes about 9 or 10 minutes before the receive times out.  Is there anyway
to reduce this time period for the send or receive?


-- 

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 14:10:25 GMT
From:      farley@farley.orl.mmc.com
To:        comp.protocols.tcp-ip
Subject:   OPENCONNECT/MITEK

Does anyone have any knowledge of Openconnect acquiring Mitek Corporation ???
Also, does anyone have a phone number and/or contact at Openconnect available ???		

THANKS, GARY BURGER

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 14:18:31 GMT
From:      weber@world.std.com (Bob Weber)
To:        comp.protocols.tcp-ip
Subject:   OSPF Cost Metrics with Multiple IP service providers

Imagine an internet world in which OSPF was widely
implement by regional and national IP services providers.
(my question is not whether this is a good idea or not,
so please let's avoid religious wars about routing protocols.)

Imagine also that i'm running OSPF internally for my large
enterprise-wide company internet.

imagine that i buy external internet connectivity from two different
IP services providers, both of whom run OSPF.

questions:

1. will i be able to routinely access the cost metrics associated by
each of the IP services companies with routes to a given network
reachable through either service (i'm located in massachusetts
and want to get to a particular network in california reachable
through both services, for example).

2. If i can access their cost metrics, can i decide which service
to use based on lowest external cost?

3. If i can access their cost metrics, can i decide which
service to use based on the sum of the lowest external cost and
the internal cost of reaching a particular gateway (i might be
closer to one than the other).

4. if i can use their cost metrics, how do i know whether the
cost metrics were calculated the same way (or an equivalent
way) by each IP services provider and therefore are truely
comparable?

5. if users could access cost metrics for particular routes
as calculated by each service provider, what prevents IP providers in
a competitive world from choosing a method of calculation that
gives them an apparent competitive advantage (other than
word of mouth, etc.)?

Thanks
Bob Weber
--
Robert Weber                       Voice: 617/570-0791
Northeast Consulting Resources     Fax:   617/523-0150
85 Devonshire Street, 4th floor    Internet: weber@world.std.com

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 14:31:18 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.sys5.r4
Subject:   Re: Can two class C networks have one primary DN server?

In article <1993Aug4.095838.5552@maths.tcd.ie> tomasz@maths.tcd.ie (Tomasz Wolniewicz - Visiting) writes:
>mark@mark-one.inet-uk.co.uk (Mark Powell) writes:
>
>>We have two class C networks. We'd like to set up our zone to encompass
>>both of these networks. I'd just like to know if this is possible, before
>>I start wasting time. I can't seem to find any examples of how to do this.
>>They all assume a class B network. 
>As far as I can tell the domain to number mapping is very flexible.
>All that needs to be done is setting up a domain (by a nameserver entry in
>the domain above you) Then you just map individual names to numbers. They
>can be anything. Having domains organized in single classes is easier for
>routing and reverse mapping (numbers to names), but everything can be taken
>care of withut too much trouble.


	At Oklahoma State University, we are doing the exact thing you
describe.  Our "hosts" data base has all the A records from all our networks,
but there must be a separate reverse map for each network.  You simply need
to register as the primary name server for each of your networks and as the
primary name server for the reverse maps of each of your networks.

	We have a class B and four class C networks so our name server data
base contains the "hosts" data base with A records for all five networks,
one reverse map for our class B, and four other reverse maps for the class
C's.

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

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      04 Aug 1993 14:45:58 GMT
From:      jbh@aii.com (James B. Huber)
To:        comp.protocols.tcp-ip
Subject:   SLIP driver for SYSV

HELP,
  I've got an Interactive unix box their release 4.0 that I am trying to do
slip with. Bottom line, the slip driver supplied by ISC is giving me too much
trouble. I need a replacement driver, I've tried searching with archie for
SLIP etc. and can't find a driver package anywhere.
  Does anyone know of a SLIP package for System V boxes anywhere ? Sort of
like a slip version of FAS or something ?
  Any and ALL help or pointers would be greatly appreciated.


Thanks in advance,
Jim

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 15:04:07 +0000
From:      pete@smtl.demon.co.uk (Pete Phillips)
To:        demon.ip.support,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Looking for method of connecting laptop to Sparc.


Hi,

we use ppp on our Sun to connect to Demon Internet Services. In fact
we use the dp-2.2 dialup-ppp package.  I would like to be able to back
up our Wyse notebook onto our Sun, and transfer files across.  Could I
do this with a ppp package for the Wyse and no changes to our Sun ?
If so, what ppp packages are around on the net, and how would I
configure the Sun ?

Any pointers to what is probably an FAQ (or any other help) appreciated,
Pete

(I'd appreciate replies by mail - I will summarise the responses).
-- 
Pete Phillips, Deputy Director, Surgical Materials Testing Lab, 
Bridgend General Hospital, S. Wales. 0656-652166 pete@smtl.demon.co.uk   
--
"The Four Horse Oppressors of the Apocalypse were Nutritional
Deprivation, State of Belligerency, Widespread Transmittable Condition
and Terminal Inconvenience" - Official Politically Correct Dictionary

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 15:32:20 GMT
From:      hnatara@eng.clemson.edu (hari natarajan)
To:        comp.protocols.tcp-ip
Subject:   info on tcp-ip layer on atm layer


I am looking for some info when a tcp_ip layer is on top of an atm layer. I want to know what is the standard length of a packet made up of recombination of atm cells.
Any info on this would be appriciated. 
 You could contact me at ; 
 -------------------------------------------  
        hnatara@eng.clemson.edu
-------------------------------------------------        




-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 15:48:17 GMT
From:      hnatara@eng.clemson.edu (hari natarajan)
To:        comp.protocols.tcp-ip
Subject:   Re: info on tcp-ip layer on atm layer

I would like to know the standard size of a packet which is made up of a recombination 
of atm cells when a tcp-ip layer is on top of an atm layer.
Also is there a specific news group on atm?
 Any info on this would be appreciated
 
 You can send mail to  : hnatara@eng.clemson.edu



-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed,  4 Aug 93 12:33:00 +0200
From:      ronny.hatlemark@euronetis.no (Ronny Hatlemark)
To:        comp.protocols.tcp-ip
Subject:   WIN/OS2/TCPIP/UNIX-PROBLEM

A OS/2 2.1 computer communicates with UNIX (HP9000) through a TCP/IP
protocoll. This works fine, but when running a Windows-application under
OS/2 2.1 the Windows-application is not able to pick up the TCP/IP
support of OS/2 2.1

Is there any way of making both OS/2 2.1 and Windows-applications run
under OS/2 2.1, communicate with UNIX through TCP/IP?

Ronny Hatlemark
InterNet: ronny.hatlemark@euronetis.no

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 16:40:03 GMT
From:      lesv@ppvku.ericsson.se (Lennart Svensson,7120,000036)
To:        comp.protocols.tcp-ip
Subject:   Ftplib error ?

I have found a problem with Ftplib. The problem is that it will not change
the 'mode' local. It only send it to remote side.

It will be solved by one extra statement near the end in the file FtpCommand.c

----- End of FtpCommand.c

  
  sprintf(S1,command,param);

  if ( FtpSendMessage(con,S1) == QUIT )
    return EXIT(con,QUIT);
  
  if  ( (i=FtpGetMessage(con,S1)) == QUIT )
    return EXIT(con,QUIT);
  
  if ( ! FtpGood1 ( i , Answer ))
    return EXIT(con,-i);

  if (strncmp(command,"TYPE",4) == 0)		/* Added LeSve 930803 */
        con->mode = *param;

  return EXIT(con,i);
}

---------------
  
You can also solve this problem with this statement in your application.


			Regards
			Lennart S

=============================================================================
Lennart Svensson                    
Sr. Software Engineer		    | E-mail: lesv@ppvku.ericsson.se
Ericsson Programatic Sweden AB      | 
PO Box 1038                         | Voice: (46) - 054 - 19 32 36
651 15 Karlstad Sweden              | Fax:   (46) - 054 - 19 32 78
-----------------------------------------------------------------------------
My interest is in the future cause I`m gonna spend the rest of my life there
=============================================================================



-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 17:57:27 GMT
From:      matt@ra.oc.com (Matthew Lyle)
To:        comp.protocols.tcp-ip
Subject:   Re: OPENCONNECT/MITEK

OpenConnect Systems used to do business under the name Mitek Systems Corp, there
was no merger/aquisition.  (There is a Mitek Systems in California that makes
PC peripherials with which we have no affiliation)

You can contact our sales group by sending e-mail to info@oc.com.  Our main
corporate phone number is (214) 484-5200.

farley@farley.orl.mmc.com writes:
>Does anyone have any knowledge of Openconnect acquiring Mitek Corporation ???
>Also, does anyone have a phone number and/or contact at Openconnect available ???		
 
>THANKS, GARY BURGER
-- 

Matthew Lyle                                           matt@oc.com
                                                       matt@utdallas.bitnet
OpenConnect System, Dallas, Texas                      (214) 888-0474

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 18:20:25 GMT
From:      poc@shaddam.usb.ve (Patrick O'Callaghan)
To:        comp.protocols.tcp-ip
Subject:   Re: complex (to me) telnet query

In article <1993Aug02.034341.19022@news.mhs.oz.au> jbell@pdev.ga.oz.au (John Bell) writes:

	   I need some advice re the behaviour of  telnet.  It appears to be
   impossible to redirect  the standard input of a telnet session.

	   ie.	telnet hostname < inputfile

	   merely crashes with _Connection closed  by foreign host_.  This
   presumably implies that one  cannot write a program that feeds input to
   a telnet session launched by a daemon and captures its output (say via
   pipes bound to the stdin/stdout of the telnet session)  Certainly, my efforts
   to do so have come to nought.  I would dearly like 
   to have a program which would allow my database software to engage in such
   an "interactive" session.  Is this possible?  Is there something in the
   public domain which can help me do this?

Your prayers are answered :-) You need 'expect', available from fine
FTP sites everywhere, but in particular from
durer.cme.nist.gov:pub/expect.shar.Z

--
Patrick O'Callaghan			Internet: poc@usb.ve
Departamento de Computacion		NICNAME: PO22
Universidad Simon Bolivar 		Tel: +058 (2) 906 3320, 906 3947
Apartado de Correos 89000		FAX: +058 (2) 93 71 28
Caracas, Venezuela			"There is no Net but the Internet"

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 18:53:52 GMT
From:      lessem@ibg.colorado.edu (LESSEM JEFFREY M)
To:        comp.protocols.tcp-ip
Subject:   Wireless Long Range Lans


The institute where I am working is considering purchasing a terminal server to
set up several SLIP lines to allow people to access the network from home.  As
an alternative to the SLIP setup we are also considering long range LANS based
on microwaves or some such.  We believe the higher speed gained by the wireless
setup will greatly offset an increased cost over the SLIP option.
However we are at a loss as to where to look for such wireless devices.  If
anybody has any information or company recomendations please mail them to me.
I will post a summary of responses.


-- 
--
Jeff Lessem
lessem@abacus.colorado.edu
Better living through barbecue.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 19:32:34 GMT
From:      Andy Malis <malis_a@timeplex.com>
To:        comp.protocols.tcp-ip
Subject:   RFC 1356 (IP/X.25) Implementation and Interoperability Experience

In order to advance RFC 1356 (Multiprotocol Interconnect over X.25)
from proposed to draft standard, I am soliciting implementation and
interoperability experience from the Internet community.  Any
interoperability experience with RFC 877 would also be appreciated.
 Please mail replies to malis_a@timeplex.com.

Thanks,
Andy
_______________________________________________________________________
____
Andrew G. Malis    malis_a@timeplex.com                  Ph: +1 508
266-4522
Ascom Timeplex     289 Great Rd., Acton MA 01720  USA    FAX:+1 508
264-4999

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 20:30:55 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Help! Telnetd problems

In article <CB6xKw.7oI@abacus.be> aba@abacus.be (Tony Badcock) writes:
>    telnetd: All network ports in use.

You have run out of ptys of whatever flavor that SCO provides for you.
You will likely need to make more pty devices and regenerate the
kernel.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Aug 1993 23:06:04 GMT
From:      danny@dragon.stgt.sub.org (Daniel Schwager)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP PD Stuff

Hi all,
we intend to build a X-terminal based on a RISC Processor, 16MB DRAM,....
and a AMD AM 79C900JC 32-Bit ethernet-controller.
Besides of porting the MIT X11R5 sources to the new platform, we have to
port some TCP/IP stuff, to run the X-Terminal in our university.
Now my question:

a) Is there somewhere a PD / shareware TCP/IP stuff writen in C,
   which does NOT require multitasking (because our kernel has no
   multitasking feature) ?? This code should include all
   layers from layer one (except the hardware specific Code for the AMD Chip)
   to layer three (?? which includes maybe ?? the TCP/IP sockets, which where
   used by the X-System.

b) Does anybody do such a port and can give us some helpful clues ?


It's very importent for me to get these information, because we (my friend
and i) should do the port within 4 month... and so, we need _ALL_ helpfull
comments.

Thanks

Danny
  

 
-- 

Please use the following address
EMAIL: !!! schwager@azu.informatik.uni-stuttgart.de !!!
                       ,,,

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 00:21:57 GMT
From:      shome@ee.umanitoba.ca (Tapas Shome)
To:        comp.protocols.tcp-ip
Subject:   I plan to implement tcp/ip on bare hardware. Suggestions needed!!!

Keywords: multitasking kernel

I am a graduate student doing research in diatributed operating system.
We are actually building one from chip level.
For Lan, we have SGS Thopson chipset. The idea is to
connect our parallel machine to access the file system of sparc.
So that file system development is avioded.

There are braoad range of questions:

(i) According to software engineering approach, Do I really have to
write these things (tcp/ip) in c/c++. As per specs, I only
have the kernel design, lan chipset design and TCP/IP RFC's.
I want to how to go about this project. I have heard about
free BSD vesion of TCP/IP implementation, How do I get that.


(iii) At the parallel machine level, all the interface will be
through RPC mechanism. What is the best possible
info for this. Can you point to some technical report
for RPC implenetation that is solid. such as describing
algorithm, data structure etc.

(iv) Any other information that you may wish to pass on??

All replies will be highly appreciated.

Regards. 


-- 
E_mail: shome@ee.umanitoba.ca
Lateral Thinking. 

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 00:48:18 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Can we send attachments over smtp ?

In article <hashmiCB7Koy.33r@netcom.com> hashmi@netcom.com (Atiq Hashmi) writes:

>Now, how should a single email be prepared from these ascii and binary
>files:

Use MIME.  Read the MIME RFC for details on the spec.  Go read
the FAQ in comp.mail.mime for a decent intro...

This is itself a FAQ and so I felt that a posting would be more useful.

Ran
atkinson@itd.nrl.navy.mil



-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 93 00:49:15 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: WIN/OS2/TCPIP/UNIX-PROBLEM

In article <4.1995.362.0N5668E6@euronetis.no>, ronny.hatlemark@euronetis.no (Ronny Hatlemark) writes:
| A OS/2 2.1 computer communicates with UNIX (HP9000) through a TCP/IP
| protocoll. This works fine, but when running a Windows-application under
| OS/2 2.1 the Windows-application is not able to pick up the TCP/IP
| support of OS/2 2.1
| 
| Is there any way of making both OS/2 2.1 and Windows-applications run
| under OS/2 2.1, communicate with UNIX through TCP/IP?

It depends on whose tcp/ip you are using.  At the moment, there are
two OS/2 tcp/ip products that have support for WINOS2 and DOS-box tcp
APIs:  my TCP/2 and Novell's Lan Workplace for OS/2.  TCP/2 supports
several popular APIs including Winsock.  LWP for OS/2 supports most of
LWP for DOS's APIs, but has no Winsock support yet.  Several other vendors
are working on adding this feature to their products so there will be
more choices shortly.

				Dan Lanciani
				ddl@harvard.*

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 02:30:17 GMT
From:      bwolfe@is.rpslmc.edu (Brian Wolfe)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans.fddi
Subject:   short term rental/lease of routers?


Hi there,

Is anyone aware of any companies that lease high-end routers? I have
a project that requires the use of several ethernet/fddi routers
for approximately 8 weeks.

Any pointers appreciated,

regards,

Brian

--
Brian Wolfe				                    
Rush Presbyterian-St. Lukes Medical Center/Rush University
1400 W. Van Buren
Chicago IL 60612		
Internet:  bwolfe@is.rpslmc.edu  	Voice: 312-942-2141    FAX:  
312-942-4062

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 93 06:39:09 GMT
From:      ccastel@garfield.inria.fr (Claude Castelluccia)
To:        comp.protocols.tcp-ip
Subject:   On the implementation of protocols


-- 
I am looking for references (or tips) on the techniques of  protocols implementation  for High Speed Networks in  a "C/UNIX" environment (Optimization of the code , structure of the programs,  ...).

Any help on that subject would be very appreciated and helpfull...

Thanks in advance.

Claude.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Claude Castelluccia        castelluccia@sophia.inria.fr

    INRIA -- Projet RODEO
    B.P. 93, 06902 Sophia-Antipolis Cedex FRANCE
    Tel:  +33 93 65 78 09

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1993 08:09:32 GMT
From:      invernic@sassella.ICO.OLIVETTI.COM (Roberto Invernici)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   PORTING FROM SOCKET TO TLI

	I'm trying to figure out which could be the amount of job has to
	be done for porting a huge application from socket (AF_INET) to TLI.

Which are the possible troubles may arise doing that?

Any hint are appreciated! Thanks.

-robi

Please use Email: robi@ico.olivetti.com

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 08:20:13 GMT
From:      evas@cs.few.eur.nl (Eelco van Asperen)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

g88m0396@alpha.ru.ac.za (Jon-Dean Mountjoy) writes:
>We get them here too, but they do seem to have an effect on our
>386BSD boxes.  They terminate them!! (and we have to reboot afterwards)

We've had something similar here; it turned out that some older revisions of
the packet driver for the Ethernet cards used here (WD8003) caused giant packets.
Whenever such a giant packet occured on the net, all pc's with WD cards would
hang in their network code.  Upgrading to a later revision of the packet
driver solved the problem.
--
Eelco van Asperen.           | Erasmus University Rotterdam
-----------------------------| Department of Computer Science, room H4-32
internet: evas@cs.few.eur.nl | PObox 1738, 3000 DR Rotterdam, The Netherlands

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 09:21:48 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.protocols.tcp-ip
Subject:   Re: I plan to implement tcp/ip on bare hardware. Suggestions needed!!!

In article <CB9FoL.CCo@ccu.umanitoba.ca> shome@ee.umanitoba.ca (Tapas Shome) writes:
>
>I am a graduate student doing research in diatributed operating system.
>We are actually building one from chip level.
>For Lan, we have SGS Thopson chipset. The idea is to

Which chipset, LANCE?.

>connect our parallel machine to access the file system of sparc.
>So that file system development is avioded.

Implementing full TCP/IP from scratch is at least as complicated as implementing
a filesystem. Speaking as one who undertook such a project for the INMOS B300
product a few years ago it's of the order of 1-10 man years depending on how good
your experience is and how stable/complete you need the final implementation to be.

>
>There are broad range of questions:
>
>(i) According to software engineering approach, Do I really have to
>write these things (tcp/ip) in c/c++. As per specs, I only

No, you don't have to write TCP/IP in C, what spec are you talking
about, TCP/IP is defined by a set of RFCs. As far as I know, apart
from some algorithms defined in a sort of pseudo language in some
of the RFCs, there is no mention made of how they are to be implemented.

If you want to do Sun RPC though this is only realy defined in terms of
the C language.

>have the kernel design, lan chipset design and TCP/IP RFC's.
>I want to how to go about this project. I have heard about
>free BSD vesion of TCP/IP implementation, How do I get that.

The BSD NET/2 release is available by FTP from a number of sites, including
ftp.uu.net. It is also available by tape on payment of the appropriate licence
tape fee from the CSRG at UC Berkeley.

What processor are you implementing this on?.

>
>
>(iii) At the parallel machine level, all the interface will be
>through RPC mechanism. What is the best possible
>info for this. Can you point to some technical report
>for RPC implenetation that is solid. such as describing
>algorithm, data structure etc.

The full sources to Sun's implementation of RPC, XDR and rpcgen are available
by FTP from a number of sites (rpcsrc-4.0)

I think that they are in any case included in NET/2 as rpclib???

>
>(iv) Any other information that you may wish to pass on??

If you only need to implement NFS/RPC for a research project then you don't
actually need full TCP/IP at all. You can get away with a fairly naive UDP/IP
implementation. This would be approx and order of magnitude less work than a
full TCP stack. If you want to make use of the Sun RPC/XDR lib sources then
you will need to do a fairly convincing Socket Library interface to your stack
to make this work out of the box.

Good Luck.

--
    Rob Pickering, INMOS.

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 09:44:50 GMT
From:      ianl@xylint.co.uk (Ian Lawley)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet and Procomm


In article <1993Aug2.113817.6087@ccsvax.sfasu.edu>, z_johnsta@ccsvax.sfasu.edu writes:
|> Here's the deal:
|>
|> I am looking for a bit of software that (I know this sounds like a bit much)
|> replaces interrupt 14h with a program that either a.) sends/recieves TCP/IP
|> packets in such a manner that I can write a TELNET server on a UNIX box, or,
|> even better but much less likely, actually replaces the interrupt 14h with
|> a TELNET client, such that I can use Procomm Plus for Windows to access TELNET
|> services.
|>
|> I am currently working on a special project here at the library that uses
|> Procomm's scripting language (Aspect, take a look some time, it's extremely
|> powerful!) control/monitor access to various dial-up services.  Now that they
|> have the script, and I'm going to be leaving (and it would be a bad idea to
|> code something to replace what already worked), I need something that lets the
|> same Aspect script control/monitor TELNET sessions.  Currently, we use a
|> product by J&L that converts int 14h calls into IPX packets, which allows us to
|> use Procomm with the modem server on our network (Novell).
|>
|> If anyone has any idea as to where I can find such and animal, please let me
|> know!  Also, if I have to write the thing myself, the source to an already
|> existing TELNET client would be most helpful. If anyone knows where I can get
|> that source as well, please let me know.
|>
|> Please reply via E-Mail, as I only read a few of the groups to which I posted
|> this message.
|>
-------------------------------------------------------------------------------

I managed to stumble across a solution to your problem a while ago.

The PC/TCP 2.1 package from FTP Software Inc, can do what you want.

Using the PCTCP 'tnglass' program all you need to do is :

tnglass <ip-addr> <port number> -e <int14 emulator command list>

This could be your favorite Int 14 or Nasi comms software such as
Qmodem Pro or Procomm.

Then you can get connected to the modem, dial the remote number and use a
ZMODEM, KERMIT or some other file transfer program to upload/download files
from your PC from/to a remote system using a modem connected to your UNIX
Box, or Terminal Server for that matter.

Best Regards,

Ian Lawley                                              tel: +44 908 222112
Technical Support - Networking Products                 fax: +44 908 222115
Xylogics International Limited                   email: lawley@xylint.co.uk
Featherstone Rd, Wolverton Mill, MK12 5RD, UK.          lawley@xylogics.com

--
Ian Lawley                                              tel: +44 908 222112
Technical Support - Networking Products                 fax: +44 908 222115
Xylogics International Limited                   email: lawley@xylint.co.uk
Featherstone Rd, Wolverton Mill, MK12 5RD, UK.          lawley@xylogics.com

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 12:11:01 GMT
From:      poem_fv@wm.estec.esa.nl (POEM Frederic Vermenouze)
To:        comp.protocols.tcp-ip
Subject:   FTP server (Anonymous)

I have to set up an FTP server and I would like to know where I can find information about it.
Is there any public domain software available ?
I also have the choice between a VAX-VMS or SUN-UNIX platform and I'd like to know
if one could be more suitable.

Thanks,
Frederic Vermenouze
ESA, ESTEC, WMS

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 93 13:42:28 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP access to/from MVS and VM

The only single product that fits all of your criteria is from Open Connect
Systems.  They can get you full TCP/IP services and APPC.  But, since IBM
hasn't published what APPC looks like on TCP, their approach is, of course,
proprietary.

We did NOT use their APPC libraries here because a development group had
already developed a lot of code using DCA comservers before the central
telecommunications group got around to developing TCP/IP services for the
mainframes.

Because of that, the OCS product has been relegated to a general purpose tn3270
gateway and we have the IBM TCP/IP stack with 3172 on most of the systems for
high performace socket applications and file transfer.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 93 17:03:43 GMT
From:      mday@pollock.ucsf.edu (Mark Day)
To:        comp.protocols.tcp-ip
Subject:   Connection limits in Sun RPC?

I'm having a problem writing a distributed application that relies on ONC/RPC.
In a nutshell, I'm unable to open more than four connections to an RPC service
via clnt_create().  Four connections works just fine, but the opening of the
fifth connection fails with a "Remote system error - Connection timed out"
error.  I have no trouble believing that there is a hard coded limit on
the number of connections, but four seems a little small.

The actual application relies on a compute engine that is distributed
asynchronously across multiple remote hosts.  They all coordinate with an
RPC service running on the master to return results.  Since each remote
process will handle multiple requests from the master, I've coded it to
open all connections at initialization, rather than incurring the overhead
of closing/reopening the connection with every request.  Unfortunately I'm
unable to open enough connections to satisfy our needs.

I've distilled my code down to a small program that displays this behaviour. 
If anyone could point out the error in my ways, or suggest how to increase the
allowed number of connections, I'd be eternally grateful.

=============== rpctest.c  (Usage: rpctest connection_number) =============

#include <stdio.h>
#include <rpc/rpc.h>

#define PROGNUM		0x20000060
#define VERSION		1

static void	dummy(struct svc_req *request, SVCXPRT *xprt);
static void	open_connections(int count);

main(int argc, char *argv[])
{
	SVCXPRT	*transport;

	if ((transport = svctcp_create(RPC_ANYSOCK, 0, 0)) == NULL) {
		perror("Can't create rpc socket");
		exit(1);
	}

	/*
	 * register service with portmapper.
	 */
	pmap_unset(PROGNUM, VERSION);
	if (!svc_register(transport, PROGNUM, VERSION, dummy, IPPROTO_TCP)){
		perror("Can't register RPC reply service");
		exit(1);
	}

	/*
	 * Open specified number of connections to rpc service.
	 */
	open_connections(atoi(argv[1]));

	pmap_unset(PROGNUM, VERSION);
	return 0;
}

static void
open_connections(int count)
{
	int	i;
	char	host[BUFSIZ], buf[BUFSIZ];
	CLIENT	**client;
	
	if ((client = (CLIENT **) malloc(sizeof(CLIENT *) * count)) == NULL) {
		fprintf(stderr, "Out of memory.\n");
		exit(1);
	}

	/*
	 * create "count" connections.
	 */
	(void) gethostname(host, sizeof host);
	for (i = 0; i < count; i++) {
		if ((client[i] = clnt_create(host, PROGNUM, VERSION, "tcp"))
		  == NULL) {
			(void) sprintf(buf, "Can't open connection #%d", i + 1);
			clnt_pcreateerror(buf);
			return;
		}
	}
}

/*
 * Dummy dispatch function.
 */
static void
dummy(struct svc_req *request, SVCXPRT *xprt)
{
	if (!svc_sendreply(xprt, xdr_void, 0)) {
		perror("Can't acknowledge rpc reply");
	}
}
--
Mark Day
Dept. of Pharmaceutical Chemistry		mday@picasso.ucsf.edu
University of California, San Francisco		..ucbvax!ucsfcgl!mday
Voice: (415) 476-5326	FAX: (415) 476-0688

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 17:08:11 GMT
From:      weber@world.std.com (Bob Weber)
To:        comp.protocols.tcp-ip
Subject:   tcp to ISDN mappings

are there proposals or standards for mapping IP addresses or 
Domain Names into E.164 addresses in ISDN? is there an RFC or
FYI? i couldnt locate one.
Thanks
Bob Weber 


-- 
Robert Weber                       Voice: 617/570-0791 
Northeast Consulting Resources     Fax:   617/523-0150 
85 Devonshire Street, 4th floor    Internet: weber@world.std.com 
Boston MA 02109-3504                        rweber@well.sf.ca.us 

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 17:34:53 GMT
From:      ks@acn.purdue.edu (Kirk Smith)
To:        comp.protocols.tcp-ip
Subject:   Dialup PPP for Solaris 2.x

I have just completed dp-3.0, a dialup PPP package that works under Solaris 2.X.
It is available from ftp.acn.purdue.edu:pub/dp-3.0.tar.Z.  It can handle dialing
and disconnecting idle lines.  It's freeware, so it comes with no support, but
there is a discussion list (dplist-request@phoenix.acn.purdue.edu for subscription).
It's got a few rough edges, but if you know what you are doing, it works quite
well.  We have 16 remote sites linked to a central hub via 4 modems.

					Kirk Smith
					Purdue Agricultural Computer Network


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 19:02:24 GMT
From:      tmm@apollo.HP.COM (Thomas M. Mistretta)
To:        comp.protocols.tcp-ip,comp.networks.noctools.wanted
Subject:   Summary : tests and tools for IP routers

==========================================================================
   
A while ago I posted a request to this newsgroup about getting tools
and test suites for IP routers.  I got several requests to summarize
and repost.  So here it is...

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

Don't forget to test the quality of the forwarding capacity. Can it
handle bursts, are there any permanent or temporary delays or blocking?
At what load level will packet loss start to grow too high?

Using two PCs and PDCLKSET will help you answer these questions.
The readme.1st file appended below.

Jan E LDC

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

PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.

It can use BOOTP to get IP number and other info.
PDCLKSET talks to the network card via a packet driver.

PDCLKSET can assign the proper normal or dls timezone name to
an environment variable (TZ is used by most systems).

There is also a very powerful buildt in ping/echo client and server giving
important statistics on delay, load and packet loss.

The PDTBUILD program, which is included in the ZIP package, looks
at all ARP broadcasts and generates hardware address tables with all the IP 
hosts on this (sub)net. It detects IP and hardware address duplication.

And still, PDCLKSET is so small (13 KB) you can use it even on 
diskette-only PCs.

For more info, see file PDCLKSET.DOC.

PDCLKxxx.ZIP is available at msdos.ftp.sunet.se:pub/network/pdclkset,
ftp.lu.se:pub/network/pdclkset, wsmr-simtel20.army.mil:PD1:<MSDOS.PKTDRVR>,
oak.oakland.edu:pub/msdos/pktdrvr, wuarchive.wustl.edu:mirrors/msdos/pktdrvr,
nic.funet.fi:pub/msdos/networks/pktdrvr, and probably other Simtel mirror
archives.

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

This may not be much, but we have a low-cost software-only PC-based protocol
analyzer that supports TCP/UDP/IP on ethernet, token-ring, and ARCNET.  We
are also about to release a similar product for async SLIP and PPP analysis.
The PacketView software (ethernet, token-ring, and ARCNET) costs $249.00.

Please let me know if you think this might help you.

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

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

A long time ago (in a galaxy...) NIST contracted to get
a TCP/IP test suite done that did conformance testing for
TCP, UDP, IP, ICMP, FTP, SMTP, and TELNET.  This suite is
still around and it runs (sorry) on a DEC VAX system under
Ultrix (1.1 I think).  The IP and ICMP tests are quite
good.  There may still be a few labs in your area that
do the testing for a fee.  Call BBN and ask them about
the NIST Test Suite for TCP/IP.  They may be able to
help you.

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




-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1993 19:06:26 GMT
From:      rocket@wam.umd.edu (BAMBOO FLAG)
To:        comp.protocols.tcp-ip
Subject:   Performance of error control codes

Hi, 

I am trying to find the most efficient error control codes for a computer
network such as internet. Anyone know if there are information available on
the performance of each code that is being used? Please mail the information
to shoot@eng.umd.edu. Your help would be greatly appreciated...


Charlie.


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1993 19:44:43 GMT
From:      walker@pms705.pms.ford.com (Dave Walker)
To:        comp.protocols.tcp-ip
Subject:   Jacobson Paper on Performance

Does anyone know how I can obtain a copy of the Van Jacobson paper on tcp/ip performance?

Dave Walker                              Phone: (313) 337-1792
Engineering Communications Network       email: walker@pms705.pms.ford.com
Workstation Systems Department           Profs: dwalker6
Ford Motor Company



-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Aug 1993 21:28:17 GMT
From:      ronf@mazel. (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: Jacobson Paper on Performance


Me too!!!!!!!!!!

In article a8f@ef2007.efhd.ford.com, walker@pms705.pms.ford.com (Dave Walker) writes:
>Does anyone know how I can obtain a copy of the Van Jacobson paper on tcp/ip performance?
>
>Dave Walker                              Phone: (313) 337-1792
>Engineering Communications Network       email: walker@pms705.pms.ford.com
>Workstation Systems Department           Profs: dwalker6
>Ford Motor Company
>
>



---

>
Ron Feigen
ronf@panther.mot.com


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1993 21:33:54 GMT
From:      akingdom@vtaix.cc.vt.edu (Sandy Knapp)
To:        comp.protocols.tcp-ip
Subject:   ftp client for shell scripts needed.

Hi,

I am trying to ftp files from script (sh) files. Does anyone know of a
ftp client that does this easily (say 'grab <host> <account> <pass> <file>')?

Or are there other tricks to do this sort of thing?

Thanks,

Philip


-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      05 Aug 1993 22:39:21 GMT
From:      dtm@Ebay.Sun.COM (Duane T. Mun)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp client for shell scripts needed.

"Sandy" == Sandy Knapp <akingdom@vtaix.cc.vt.edu> writes:

Sandy> I am trying to ftp files from script (sh) files. Does anyone
Sandy> know of a ftp client that does this easily (say 'grab <host>
Sandy> <account> <pass> <file>')?

You could try something like this...

----------------------------------------------------------------------------
#!/bin/sh

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

--

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1993 23:09:31 GMT
From:      gat@robotics.jpl.nasa.gov (Erann Gat)
To:        comp.lang.lisp.mcl,comp.protocols.tcp-ip
Subject:   Telnet protocol?

I am trying to write a telnet client (on top of Guillaume Cartier's
TCP package) and I need to find out what the telnet protocol is.
Simply opening a TCP stream to port 23 doesn't seem to work.  Any
help would be much appreciated.

Thanks,
Erann Gat
gat@robotics.jpl.nasa.gov


-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 00:33:36 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Jacobson Paper on Performance

> Does anyone know how I can obtain a copy of the Van Jacobson paper on tcp/ip performance?

There are several, and then there's the even more fun stuff he's never
published.  Here's the stuff that is relatively easy to get:

%A D.D. Clark
%A V. Jacobson
%A J. Romkey
%A H. Salwen
%T An Analysis of TCP Processing Overhead
%J IEEE Communications
%D June 1989
%V 27
%N 6
%P 23-29

Discusses where the overhead is in TCP processing.

%A V. Jacobson
%T Congestion Avoidance and Control
%J Proc. ACM SIGCOMM '88
%D August 1988
%C Stanford, Calif.
%P 314-329

Explains slow start and Van's round-trip time estimation routine.

%A V. Jacobson
%T 4BSD Header Prediction
%J ACM Computer Communication Review
%D April 1990
%V 20
%N 1
%P 13-15

Copies of slides that show how TCP header prediction work.  TCP processing
in under 100 instructions per packet.

%A V. Jacobson
%T Tutorial Notes from SIGCOMM '90
%C Philadelphia
%D September 1990

Full of ideas -- WITLESS interfaces, combining memory copies and checksums,
how to do IP in under 100 instructions per packet.  Only tutorial attendees
have copies and they probably won't let you borrow them!:-)  I'm trying
to persuade Van to teach an updated version of this tutorial at SIGCOMM '94
(in London, 30 August - 2 September 1994) but we'll see how successful I am.

%A V. Jacobson
%A R. Braden
%A D. Borman
%T TCP Extensions for High Performance; RFC-1323
%J Internet Request for Comments
%N 1323
%D May 1992

TCP options to achieve gigabit speeds (while keeping fully compatible with
existing TCPs).

In addition, Sally Floyd and Van have a paper appearing in this fall's SIGCOMM
conference (drop me a note if you want info on SIGCOMM '93).

Furthermore, Van's lectures (especially the SIGCOMM '90 tutorial) motivated
several folks to try out some of his ideas about protocol performance.
Two useful instances:

%A G. Watson
%A D. Banks
%A C. Calamvokis
%A C. Dalton
%A A. Edwards
%A J. Lumley
%T Afterburner
%J IEEE Network Magazine
%V 7
%N 4
%D July 1993
%P 36-43

Afterburner is a realization of Van's idea for WITLESS interfaces.

%A C. Partridge
%A S. Pink
%T A Faster UDP
%J IEEE/ACM Transactions on Networking
%V 1
%N 4
%D August 1993

Steve Pink and I tried out a number of Van's TCP optimizations on UDP and
got a 30% performance improvement.

Hope this helps,

Craig Partridge
Bolt Beranek and Newman
craig@bbn.com

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 08:47:30 MDT
From:      slmt9@cc.usu.edu (Joshua Dinerstein)
To:        comp.protocols.tcp-ip
Subject:   HELP: I need some info on the TALK protocol.

	Hi all,

	I am in need of a document or fragment of source code that has the
specifications for a TALK client and sever that actually use the TALK protocol.
The only things that I have been able to find have been for the NTALK protocol
only.

	So if the source is available for anonymous ftp or there is a spec out
there somewhere then please let me know! And I can handle lots of responses
so please anyone that know send me a message. =)

	Joshua
	SLMT9@cc.usu.edu

p.s. Anyone know of a site that has the BSD2 sources on them. I must be the
only one out there that can't seem to find them. :)


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 06 Aug 93 02:53:06 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell,bit.listserv.novell
Subject:   AT1[57]00.ZIP - Allied-Telesis 1500 & 1700 packet drivers

I have uploaded to WSMR-SIMTEL20.Army.Mil and OAK.Oakland.Edu:

pd1:<msdos.pktdrvr>
AT1500.ZIP      Allied-Telesis 1500 packet driver
AT1700.ZIP      Allied-Telesis 1700 packet driver

This is a packet driver for the Allied-Telesis AT1500T, AT1500BT,
AT1700T and AT1700BT Ethernet adapters.

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

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 03:13:04 GMT
From:      melanie@ph-meter.beckman.uiuc.edu (Melanie Humphrey)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

dpm@wixer.bga.com (David Maynard) writes:

>harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:
>>I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
>>for our Macs and PCs on campus.  I am getting an error which I am not sure
>>what it means.  Below is the message I have in my error file:
>>Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
>>Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
>
>I haven't seen this in awhile, but it used to be a fairly good indication
>of either a cabling or a transceiver problem.  If the ether segment isn't
>too big then it's probably worth checking all of the connections.  If all
>of the PCs and Macs live on it then maybe it's being caused by one of them
>rebooting as mentioned in another post.
>

mhhm, a late collision. due to semi-bogus reflections. 

we have have this problem with goofy, brain dead AIX systems within
which the MTU IS SET WRONG OUT OF THE BOX AAAGGUH. if you have any IBM
RT's on the net this is probably it. check the /etc/net file to make sure
the MTU is 1500 or less.

you might look in your ARP tables to see if you can associate an IP
address and name with the MAC address. this might indicate the culprit. 
etherfind might also be enlightening; see if you can associate any
identifier at all with the MAC address. of course, if it's a giant packet,
you may be getting a nonsensical MAC address as well. 'well, i give up. i'll
assume the frame starts, ooooohhhh *here*'

rebooting a mac or pc shouldn't cause giant packets. if it does, the
card or driver is Broken.

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

-------------------------------------------------------------------------------
Melanie Humphrey | Mgr. Systems Services  | BISS --
msh@uiuc.edu	 | Beckman Institute	  |	If we can't fix it, it 
217-244-1079	 | University of Illinois |	ain't broke.
-------------------------------------------------------------------------------

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 08:55:59 GMT
From:      David.Harrison@barclays.co.uk
To:        comp.protocols.tcpip,comp.unix.pc-clone.32bit
Subject:   Interactive SLIP - basic problem

Dialing in from home to my internet provider (demon.co.uk) using sldialup on
Interactive 3.0.1, everthing seems to get set into a raw mode (which makes
sense, I guess). Only problem with this is that I now can't log in as I need
to give my host name, password and protocol type :-(

<Ctrl>-J works (after a fashion) but my host/passord combo gets rejected - due 
to extra control chars getting in?

Any ideas? Am I missing something here? Can I not see further than my nose? :-)

BTW - I've asked demon about this, no reply just yet.

-- David

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 09:59:06 GMT
From:      David.Harrison@barclays.co.uk
To:        comp.protocols.tcpip,comp.unix.pc-clone.32bit
Subject:   Interactive SLIP - again

Ok, I think my SLIP problem (unable to log into internet providers gateway as
the <Return> key is not recognised) is down to the sldialup command. 

How do I set it up to allow 8 bits no parity with one stop bit when I dial?

I'm assuming using AT-04 to set the modem serial port makes no difference.

Cheers,

-- David

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 10:00:18 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip,comp.sys.dec,comp.unix.ultrix,comp.unix.osf.osf1,comp.unix.admin,comp.sys.sun.admin,comp.sys.sun.misc
Subject:   A new tool for managing network variables like TCP max window size


			NETCONFIG

	Netconfig is a program intended to make management of
network configuration options such as TCP maximum window size a part
of routine system administration.  Berkeley Unix based networking
software is configurable to a surprising degree by means of assorted
kernel variables such as 'tcp_recvspace' and 'ipforwarding'.  One can
raise TCP max window size to raise performance over FDDI or long
connections, or one can lower it to improve SLIP performance.  With
the increasing emphasis on networking and increasing diversity of
networks, I believe that it is increasingly important that it be easy
for individual system administrators to configure network software.
	Unfortunately, as matters stand it is difficult to find out
what variables can be changed, especially for those who lack access to
source code.  Learning how to change the variables is not particularly
easy, either, since it changes from machine to machine and there are
no obvious manual page pointers.  Most difficult of all is figuring
out what values are appropriate to one's network.
	Netconfig attempts to fix these problems.  When run with no
arguments, it prints out a list of all the network configuration
variables that both the program knows about and are present in the
currently running kernel so that a system administrator can easily see
what variables are available to be changed.  For example, it prints
out the following on a Sun running SunOS 4.1.2:

IP:
    Routing (_ip_forwarding):                   on
    Verbose (_ip_printfs):                      off
ICMP:
    Redirects (_ip_sendredirects):              on
TCP:
    Output Buffer Size (_tcp_sendspace):        28672
    Input Buffer Size (_tcp_recvspace):         28672
    No Delayed ACK (_tcp_nodelack):             off
    Maximum Segment Size (_tcp_default_mss):    512
UDP:
    Checksum (_udp_cksum):                      on
    Max Sndbuf and Msg Size (_udp_sendspace):   65535
    Max Rcvbuf and Msg Size (_udp_recvspace):   65535
    TTL (_udp_ttl):                             60

Netconfig allows for easy change of the variables involved.  I set a
number of the values above using the following commands:

$ netconfig tcp_sendspace 28672 tcp_recvspace 28672 udp_sendspace 65535
$ netconfig udp_recvspace 65535 udp_cksum on

The manual page includes a short description of the impact of some of
the variables and suggestions on configuration values.

Netconfig has been ported to the following machine/OS pairs:

Architecture			OS
-----------------------------------------
DECstation			Ultrix
Vax				Ultrix
Sun 3				SunOS
Sun 4				SunOS
Alpha				OSF/1


LOCATION

Netconfig is available for anonymous FTP at:

ucsd.edu:pub/csl/netconfig/netconfig.tar.Z


INSTALLATION

	Ideally, netconfig should be installed as setgid kmem.  If you want
your users to be able to see what the values of network variables are (can't
hurt, might even help), you must install 'netconfig' setgid (netconfig never
allows anybody lacking permission to write to /dev/kmem to change network
variables).  Examine the permissions on /dev/kmem and /vmunix to see what sort
of permissions are needed to write /dev/kmem and read /vmunix.

1) Examine 'makefile'.
	Edit the value of INSTALLDIR to your satisfation.
	Edit the chmod and chgrp commands to reflect the above discussion on
		setgidness - probably no change will be needed.
2) Type 'make'. 
3) su
4) Type 'make install'.


PORTING
	Netconfig is portable, and getting more so.  The body of the program
compiled and ran without complaint on every machine I tried it on.
However, it does need a valid list of variables to work on a given machine.
if you attempt to compile netconfig up on an architecture not listed
above without prior effort, it will probably compile and run and not print
out any variables at all.  The porting process to a BSD-based OS is:

1) Enumerate what variables are available in a newly created <machine>.h file.
2) Update machdep.h to reflect the new machine-specific header file
3) Add new vendor-specific variables to tables.c.


AUTHOR
Jon Kay (jkay@ucsd.edu) 
University of California, San Diego Computer Systems Lab 


ACKNOWLEDGEMENTS
I gratefully acknowledge help from Kim Claffy, of the University of
California, San Diego Computer Systems Lab (kc@cs.ucsd.edu) with
the documentation.


COPYRIGHT

Copyright (c) 1993 Regents of the University of California.
All rights reserved.

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without written agreement is
hereby granted, provided that the above copyright notice and the following
paragraph appears in all copies of this software.

THIS SOFTWARE IS PROVIDED BY THE REGENTS ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
EVENT SHALL THE REGENTS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


Version 1.2
Wed Aug  4 22:42:11 PDT 1993

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 11:46:37 GMT
From:      erasver@lmera.ericsson.se (Proj.anst. JL/ODC Sven Eriksson JL/OGG)
To:        comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

We also had this giant packet problem. It started with one message now and then on
all Sun systems on that subnet. We were fortunate to have a good instrument to
messure noise on the network. It told us that there were a lot of packets with
strange sizes and a lot of noise. This subnet contains 150-200 nodes so it would
be hard to find the exact problem. We looked over the machines that had been
installed during the latest days and the instrument reported that the network
was clean when one of the newly installed boxes was disconnected. The source was
a bad connector on an ethernet board connected to thin ethernet.

Good instruments are expensive to buy but are nescessary in our large network.


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 12:00:48 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Jacobson Paper on Performance

>%A V. Jacobson
>%T Congestion Avoidance and Control
>%J Proc. ACM SIGCOMM '88
>%D August 1988
>%C Stanford, Calif.
>%P 314-329
>
>Explains slow start and Van's round-trip time estimation routine.

A version of this classic is also available via anonymous ftp at
ftp.ee.lbl.gov in the file congavoid.ps.Z.

	Rich Stevens

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 12:54:37 GMT
From:      gnn@cs.utwente.nl (George Neville-Neil)
To:        comp.dcom.lans,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Latest bandwidth measuring software out...

Hi Folks,

	OK, I know I just did a release recently but I needed something
to measure network jitter, so I wrote a new program, udp_jitter which 
measures jitter over a UDP connection to the echo daemon. 

	The new package is on pegasus.cs.utwente.nl in pub/bandwidth
with file name: bwmeas-0.3.tar.Z .

	As usual all bug reports suggestions etc. should be sent to
me (gnn@cs.utwente.nl).
	
Enjoy,
George

--
So may all your wives, if you need them, be rich and pretty; and all your 
husbands, if you want them, be young and virile; and all your cats as
wily, perspicacious and resourceful as: Puss-In-Boots.
-- Angela Carter (Puss-In-Boots)

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 12:56:33 GMT
From:      paul@ace.acadiau.ca (Paul Steele)
To:        comp.protocols.tcp-ip
Subject:   Need information on Internet Policies

Up until now, we have always allowed all of our users full 
internet access from anywhere on campus.  Now that I have our 
router up and running, I am setting up some filtering to prevent 
certain types of access.  The question has come up concerning 
internet access from public (student) labs.  We have heard that 
it is against internet  policy to allow unauthenticated 
access to the network. If that is the case then we can certainly 
do it, but our students sure won't be happy.

Please let me know what the situation is, and if there is any 
documentation where this policy is stated.  If there is a more appropriate 
group to post this message, please let me know what it is.



___
Paul Steele, Network Services Manager              902-542-2201x1660
Acadia University, Computer Centre            FAX: 902-542-4364
Wolfville, Nova Scotia, Canada, B0P 1X0  Internet: Paul.Steele@acadiau.ca

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 1993 19:46:08 -0400
From:      rayc@panix.com (Ray Compton)
To:        comp.protocols.tcp-ip,misc.books.technical,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought

In <1993Aug6.173735.17937@mccaw.com> peterg@eng.krldwa.mccaw.com (Peter Gregory) writes:
>I need recommendations for one or more books on TCP/IP LANs and WANs.
>I'll soon be in a consulting capacity and "stretching the envelope" with regards
>to my knowledge of large TCP/IP networks.  My client has thousands of nodes on
>a nationwide router-based network, and I need to quickly come up to speed on the
>issues facing large networks.
>I know all the basics of TCP/IP, understand the protocol and have done network
>client/server programming with ICMP, UDP and TCP on UNIX and non-UNIX systems.
>So I don't need a "basics of TCP/IP" book, but more advanced stuff.
>Concepts I need to master are: netmasks, subnetting, routers, SNMP, gateways,
>DNS and other WAN issues.
>Thanks!
[deleted]

My personal favorites:

TCP/IP Network Administration by: Craig Hunt
O'Reilly & Associates, Inc.
~US$30
	Thorough, practical, no nonsense text.


Internetworking with TCP/IP by: Douglas E. Comer
Prentice Hall
~US$48-50
	Currently a three volume set that deserves a look.  Oriented
	toward a university level course TCP/IP in networking.  Good
	low level (protocol) stuff.

Good luck
/rayc
-- 
<MyIdeas >/dev/null 2>/etc/motd

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 14:16:46 GMT
From:      sinz@pauke.informatik.uni-stuttgart.de (Werner Sinz)
To:        comp.protocols.tcp-ip
Subject:   Protocol-Port

Hi,

I want to port an IP-Layer protocol from SunOS-4.1.3 to SunOS-5.2.

The protocol is a good old 4.3BSD-kernel-protocol-implementation what means,
that the upper-interface are sockets (pr_usrreq ... called from the socket-
routines through the protocol-switch-table (so_proto)) and that the lower
interface is given by the ifnet-structure (network-interface).

The procedure of implementing a protocol in this way is e.g. described in
the book "The Design and Implementation of the 4.3BSD Unix Operating System"
by Leffler et al.

I didn't find any similar documentation about porting/implementing socket-
protocols (not STREAMS-based!) to/in SVR4 (SunOS-5.2).

	Can  y o u  help me?
	Do   y o u  know any good documentation about (socket-based)
		protocol-development for SVR4? (The Answerbook is no help!)
	Or do  y o u  have any experience in porting .......
	Do I have a chance anyway without having the UNIX source-code ?				     
                                     ,,,    
		    	            (o o)
+-------------------------------oOO--(_)--OOo----------------------------------+
|									       |
| Werner Sinz                 | email: Werner.Sinz@informatik.uni-stuttgart.de |
| Universitaet Stuttgart      |						       |
| - IPVR - Verteilte Systeme  | Tel.:  (+49) 0711/7816-477		       |
| Breitwiesenstrasse 20-22    | Fax:   (+49) 0711/7816-424		       |
| D-7000 Stuttgart 80         | 					       |
| Germany                     |						       |
|									       |
 +------------------------------------------------------------------------------+

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 16:37:24 GMT
From:      kmanecke@honda.honda.com (Kurt Manecke)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   SLIP setup on RS6K and Sun

After posting this message awhile ago, I have gotten several responses
from people who also need the answers, but I have gotten no solutions.
Has anyone out there successfully set up SLIP4.1.1 on a Sun4 machine
running SunOS4.1.1 or an IBM RS/6000 running AIX V3 with the version
of slip that comes bundled with AIX. I am trying to get the two machines
to communicate via a dial up line using Telebit T2500 modems. Any
responses would be extremely appreciated :-). Please send email to
kmanecke@honda.com. Thanks in advance.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 22:21:00
From:      brian@awfulhak.demon.co.uk (Brian Somers)
To:        comp.protocols.tcp-ip
Subject:   TLI/X25


I want to set up some form of TLI over x25 - fairly straight forward, but...

I only wish to do file transfers.  Some of the nodes on the WAN are
machines with serial lines connecting to PADs.  I want to minimise the
number of transmitted packets (I'm charged per packet), and therefore
want to (if I can) switch the ECC off on the x25 side - ECC is pointless
because of the potential serial line involved.  Initially, I will do the
ECC myself for the moment, but eventually I would like a TLI level
sitting on top of the x25 packet driver (sans ECC).

Is this possible ?
Are there any packages (including proprietry) that will do this for me ?
If so, do any of these packages support continued transfers (after a line
drop) ?

The machines will all be Unix SVR4 - eventually.  Currently, I've got to
support SVR3 without TCP libraries, meaning that I must do the ECC myself.

Any help / suggestions would be madly appreciated !

Thanks.

Brian <brian@awfulhak.demon.co.uk>
--
Brian <brian@awfulhak.demon.co.uk>

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 17:28:47 GMT
From:      azia@caip.rutgers.edu (Ashar Zia)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP (& UDP) without 'acknowledgements'

Hi guys,

 I want to transfer data from host A to host B. Ideally one would send a block
of data to B, then get acknowledgement from B and transfer next block of data.
The problem is that we want to save the time needed for acknowledgements as
there will always be oneway transfer of data. TCP/IP guarantees that the data
will be 'written' to host B without errors - BUT if I continuously send data
I might be 'writing' at a faster rate and 'reading' at a slower rate.
 Perhaps one way could be to put some delay before sending; but then there is
no way to find an optimal value of this delay - and it conflicts the basic 
goal of saving time.

 Consider the same problem with UDP where we don't care about the lost packets
as long as we can get some syncronization and don't 'send' data at a faster
rate than 'receiving' data.

 The whole thing becomes more complex as we consider three nodes:
We want data from host A to be sent to host B; now host B after receiving data
sends it to host C. The problem comes at host B:- it can be receiving at a 
slower rate and sending data to C at slower rate..  So there has to be some
concept of syncronization. Any ideas about achieving this synchronization 
without ACKNOWKLEDGEMENTS ? (or it might not be possible to get that 
syncronization without ACK ?)

 I would appreciate any help on this.

-Ashar Zia

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 17:37:35 GMT
From:      peterg@eng.krldwa.mccaw.com (Peter Gregory)
To:        comp.protocols.tcp-ip,misc.books.technical,comp.protocols.snmp
Subject:   TCP-IP book recommendations sought

I need recommendations for one or more books on TCP/IP LANs and WANs.

I'll soon be in a consulting capacity and "stretching the envelope" with regards
to my knowledge of large TCP/IP networks.  My client has thousands of nodes on
a nationwide router-based network, and I need to quickly come up to speed on the
issues facing large networks.

I know all the basics of TCP/IP, understand the protocol and have done network
client/server programming with ICMP, UDP and TCP on UNIX and non-UNIX systems.
So I don't need a "basics of TCP/IP" book, but more advanced stuff.

Concepts I need to master are: netmasks, subnetting, routers, SNMP, gateways,
DNS and other WAN issues.

Thanks!

---

Pete Gregory   peterg@eng.krldwa.mccaw.com  |  "It may be rice wine to you,
Senior Consultant. ASIX, Inc., Seattle, WA  |  but it's sake to me."
on-site at McCaw Cellular Communications, Kirkland, WA


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 1993 18:10:16 GMT
From:      mcox@access.digex.net (M Cox)
To:        comp.protocols.tcp-ip
Subject:   NEED MAC TCP/IP FAST!

Anyone know where I can get a Macintosh TCP/IP stack?  I need:

IP, ICMP, TCP, SMTP, FTP, telnet, UDP, and TFTP support.

Please email me ASAP with names, numbers, prices, etc.

Thanks in advance!  I'll sacrifice my first book to you!

Mike
--
Michael Cox                             Work:   mcox@access.digex.com
Amiga Conquers, AMOS Rules!             Play:   aj639@cleveland.freenet.edu
This space intentionally left blank     Fido:   1:109/456.0
        The text above is my own and all that other disclaimer junk

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 18:25:43 GMT
From:      ssrhouns@reading.ac.uk (Paul Hounslow)
To:        comp.protocols.tcp-ip
Subject:   Parallel port woes.


I have an ARLAN AR680 Wireless network device.  This is _currently_
connected to a PC with a bi-directional parallel port.

Unfortunately* I need to attach this to a 68000 box with a Zilog CIO Z8536.

Does anybody know how I can write a 'printer' driver for this chip.  I have the
Product Specification but any other information about it would be useful.

Also does anyone have any information on driving the AR680?

Please could you *MAIL* answers to me at ssrhouns@reading.ac.uk

If this newsgroup is not the correct one for this post, please accept my
apologies.

Many thanks

Paul


*As I have software and drivers for the PC.

----
73's de Paul                     The smelling pistakes are all my own.
Packet: G4YFE@GB7BEQ             I have no employer (I retired ;-).
EMail:  ssrhouns@reading.ac.uk  1990 16 valve K100LT        DoD #0573


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 19:09:03 GMT
From:      rawn@Seagull.RTD.COM (Rawn Shah)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

From article <lawsonCB7BIv.9nn@netcom.com>, by lawson@netcom.com (Steven Lawson):
> Could it be possible there is a mix of Ethernet and 802.3 frames out
> there on the wire?  I understand the type and size fields are interchanged
> between these.
> 

Anything from  a bad transceiver to some form of bus extension if you use
10Bas2 or 10Base5. Giant packets are abnormally sized (larger than the
allowable MTU of the Ethernet or the allowable maximum of Ethernet) and when
the interface chip gets one, it has to dump it because of illegal format.
"STP bit in rmd cleared" is directly in relation to a giant packet exceeding
its allowable length and messing up the STP (Start of Packet bit) for the
next Ethernet packet. 

There is some machine out there gone faulty. If you got a valid Ethernet
address instead of FF:FF:FF:FF:FF:FF which is the broadcast address, try
finding that machine with the matching Ethernet address and removing it from
the network.

Tracing this can generally be a real problem. Its time to pull out a sniffer
if you don't already know the source of your troubles. (Try the most
recently attached machine first).

--
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------
-- 
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Aug 1993 21:14:03 GMT
From:      (Chuck Watts)
To:        comp.protocols.tcp-ip
Subject:   Lexis/Nexis interface over the Internet

I want to access Lexis/Nexis over the internet via a Macintosh.  My PC
colleagues have an interface that uses TCP/IP but, since I'm the only Mac
user on our lan, the has not been much of a search for a MacTCP/IP version.
 

I'm new to the net but this seemed to be the place to post this request. 
If the message is somewhat confused, its because I'm not to sure of my
specific understanding.  I thing I made the general point though.

Any one have assistance?

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri,  6 Aug 93 18:05:00 +0200
From:      rune.mossige@euronetis.no (Rune Mossige)
To:        comp.protocols.tcp-ip
Subject:   complex (to me) telnet qu

To: 
Subject: 


JURM+impossible to redirect  the standard input of a telnet session.

JURM+ ie. telnet hostname < inputfile
I also had a similar problem some time ago, but after I updated my 
.netrc file in my home directory, I am now able to drive telnet by 
redirecting stdin. Check your man pages for .netrc, as the format 
varies. 

Rune Mossige

 * 1st 1.11 #274 * We had a meeting of the minds but yours didn't show up.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 06 Aug 1993 22:38:44 GMT
From:      pcaloca@ssf-sys.DHL.COM (Paul Caloca)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

In article <1993Aug3.201011.24148@wixer.bga.com>, dpm@wixer.bga.com
(David Maynard) writes:
|> harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:
|> >I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
|> >for our Macs and PCs on campus.  I am getting an error which I am not sure
|> >what it means.  Below is the message I have in my error file:
|> >Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from
 xx-xx-xx-xx-xx-xx
|> >Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
|> 
|> I haven't seen this in awhile, but it used to be a fairly good indication
|> of either a cabling or a transceiver problem.  If the ether segment isn't
|> too big then it's probably worth checking all of the connections.  If all
|> of the PCs and Macs live on it then maybe it's being caused by one of them
|> rebooting as mentioned in another post.
|> 
|> -David
|> 
|> -- 
|>  David P. Maynard, Carnegie Mellon University & Dependable Solutions 
|>  USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862
|>  EMail: dpm@depend.com,  Tel: +1 512 251 8122,  Fax: +1 512 251 8308

We had the same problem here. We had to 10BaseT hubs connected with thin wire
etehrnet. One of the transceivers was flakey. As soon as the transceiver was
disconnected, the problem cleared. We replaced the tranceiver and hav had no
problems since.

========================================================================
Paul Caloca				DHL Systems
Sr. UNIX Abuser				Burlingame, Ca
pcaloca@ssf-sys.DHL.COM			#include <std.disclaimer.h>

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 21:38:36 EET
From:      jaakola@cc.helsinki.fi
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Dial-up LPD via SLIP: how to start spooling?

Hi!

I'm considering various alternatives to provide printing to a remote PC.
The PC connects to a central HP9000 running HP-UX 9.0 via a modem. We
want to print files produced on the HP to a printer attached to the PC.
The files may be produced by a batch process which may be run when the
PC may have no connection to the HP box.

My solution is to set up a LPD server on the PC and use SLIP to dial
into the HP. Print jobs queue their output to a local spool, which is
spooled via the LPD protocol (RFC 1179) to the LPD on the PC. If the
connection is down, then the jobs stay spooled on the HP.

THE PROBLEM IS HOW TO AUTOMATICALLY START SPOOLING THOSE QUEUED JOBS TO
THE PC LPD WHEN THE SLIP CONNECTION IS ESTABLISHED?

The HP tries periodically to open connection to the remote LPD. WHAT
RULES GOVERN THIS RE-TRYING? HOW MANY TIMES THE HP BOX TRIES TO OPEN THE
CONNECTION? FOR HOW LONG TIME? DOES IT EVER GIVE UP? WHERE CAN I FIND
MORE INFORMATION? I have tried to read "man rlp" but it doesn't help.

IS THERE ANY WAY THE LPD CAN TRIGGER THE HP BOX TO START SENDING QUEUED
PRINT JOBS TO THE LPD? The RFC doesn't mention any way, but is there any
(maybe HP-specific) way to accomplish this?

(I know of vt220 transparent printing, but I don't want to use it because
of its poor reliability)

Thanks in advance!
--
Juhani Jaakola, jaakola@cc.helsinki.fi

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Aug 1993 04:51:02 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP-IP book recommendations sought

> concepts I need to master are: netmasks, subnetting, routers, SNMP, gateways,
> DNS and other WAN issues.

I assume you have all three volumes of Doug Comer's "Internetworking with
TCP/IP", published by Prentice Hall.  Subnetting is covered in the first book.

For information on routing, I recommend Radia Perlman's book, "Interconnections:
Bridges and Routers" from Addison-Wesley.  Radia also teaches a course at
INTEROP on this topic.

For details on SNMP, get Marshall Rose's book, "The Simple Book," from
Prentice Hall.

For DNS material, get "DNS and Bind" by Albitz and Liu, published by O'Reilly
and Associates.  (I recently had cause to review it before recommending it
to a client - very good.  And note that I view myself as a retired DNS
wizard because I designed MX RRs).

To my knowledge, there are no good books on routers (esp. related to
performance, Radia's book covers routing algorithms).  I think Scott Bradner
was working on a book but I don't know what's happened with it.  Scott teaches
a good course on router performance issues at INTEROP.

Craig Partridge
craig@bbn.com
BBN

PS: Disclaimers -- it is an incestuous world out there, so I should make my
excuses here :-).  I teach a course at the INTEROP conference, and I have
a book on gigabit networking coming out from Addison-Wesley next month.
And I was a pre-publication reviewer of both Comer's and Rose's books.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 93 11:00:26
From:      peter@future.midnight.com (Peter H. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff


   a) Is there somewhere a PD / shareware TCP/IP stuff writen in C, which
      does NOT require multitasking (because our kernel has no multitasking
      feature) ?? This code should include all layers from layer one (except
      the hardware specific Code for the AMD Chip) to layer three (?? which
      includes maybe ?? the TCP/IP sockets, which where used by the X-System.

Hmm, Phil Karn's (et al.) KA9Q is a very solid, single-threaded implementation
of TCP/IP.  I last looked at the sources over 2 years ago, but I assume it has
only improved since then :-) It is well-written code that I found easy to
modify.  It is very popular on DOS machines, but I was using it to do SLIP
under Unix on AT&T 3B1s (68000 processor).  I'm not 100% sure it will do
everything you need, but it's worth a look, anyway.

Archie says you can find it at a ton of places, but here are a couple
specifics:

Host flash.bellcore.com

    Location: /pub
      DIRECTORY drwxr-xr-x        512  Jul 20 1990  ka9q

Host gatekeeper.dec.com

    Location: /.3/net
      DIRECTORY dr-xr-xr-x        512  Apr 24 03:50  ka9q

Host files1zrz.zrz.tu-berlin.de

    Location: /pub/dos
      DIRECTORY drwxrwxr-x       1024  Jun 19 1992  ka9q

Host sun.rz.tu-clausthal.de

    Location: /pub/msdos/networking
      DIRECTORY drwxr-xr-x        512  Aug 10 1992  ka9q

Host ipc1.rvs.uni-hannover.de

    Location: /pub/info-systems/gopher/PC_server
      DIRECTORY drwxr-xr-x        512  May 30 07:40  ka9q
    Location: /pub/msdos-koeln/tcpip
      DIRECTORY drwxr-xr-x        512  Mar 10 08:01  ka9q

Host askhp.ask.uni-karlsruhe.de

    Location: /pub/infosystems/gopher/PC_server
      DIRECTORY drwxr-xr-x       1024  Jul 16 18:10  ka9q

Host ftp.uni-kl.de

    Location: /pub/ham-radio
      DIRECTORY drwxrwxr-x        512  Feb 14 1992  ka9q

Hope this helps! -- Peter
--
Peter H. Schmidt        |`'| .  | ,_  .  , |_  +      Midnight Networks Inc.
peter@midnight.com      |  | | (| | | | (| | | |,     100 Fifth Avenue
tel: 617/890-1001                       _|            Prospect Hill
fax: 617/890-0028        N  E  T  W  O  R  K  S       Waltham, MA 02154


-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 93 16:30:45 +1000
From:      itb451natzke@qut.edu.au
To:        comp.protocols.tcp-ip
Subject:   Kinit src convertion (Unix -> PC)

Hi!

I'm interested in speaking with someone with experience in converting 
KINIT sources from Unix to IBM PC DOS.  I'm interesting in avoiding
known pitfalls.  I'm using BORLAND C++ 3.1 compiler.  Any response greatly
appreceiated.

Fred NATZKE
Email:  ITB451natzke@acacia.qut.edu.au
   or:  n0948861@water.fit.qut.edu.au

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 93 14:59:21 GMT
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP book recommendations sought


I agree with the other book recommendations, and will add another
excellent book, which adds some extra stuff, including management issues,
whether to register IP addresses or not, planning subnetting
strategies (more important these days of scarce "B's")
system configuration & optimising performance, choice of routers etc.:

	TCP/IP - Running a Successful Network, K Washburn, JT Evans
	(both of them are Brits, doncha know, and work for Integralis)
	Addison Wesley,  ISBN 0-201-62765-5

I've just been sitting in the sun in the garden reading it and boning
up on the silly window syndrome...

Phil R.

-- 

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

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1993 15:08:23 GMT
From:      shoot@eng.umd.edu (Chu-Chi Li)
To:        comp.protocols.tcp-ip
Subject:   performances of error control codes used on networks

Hi

I am interested in error control codes that are used on the networks to
transfer data(i.e. mail, file transfer, etc). What are the codes used today
for this purpose? I am also interested on obtaining some data or overview on 
the performance of each code. The following aspects of a code are of interest
to me:

	1) Number of errors the code can detect

	2) How well does the error correcting code recover lost data(%)?

	3) How difficult is it to encode and decode using that method?

	4) How much burder does the code place on the system?

	5) Is it difficult to implement the code?

	6) How fast is the transmission of data using this code?

	7) In what situations is it best to use the code?

		a) which type of channel noise is the code most effective(burst,
		   random errors, etc)? 

		b) which bandwidth is it best to use the code? 

	8) what is the approximate cost of using such a code?
 
I have read that in most instances, computer networks tend to use automatic
retransmission to insure accurate information is received. Has there been
any comparison made between that method and FEC(uses error correcting code to
correct). In which cases is FEC a better method?

I realize this is a bit long. However, if you have any idea on parts of error
control codes or where I can obtain such an information,please mail me at 
shoot@eng.umd.edu. I would really appreciate your response.


Chi Li (shoot@eng.umd.edu)



-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Aug 93 15:29:42 GMT
From:      mlindsey@nyx.cs.du.edu (Mark R. Lindsey)
To:        comp.protocols.tcp-ip
Subject:   Local tn3270 network to ethernet?

I'm posting on behalf of a friend barred from the usenet for a while. He
wants to set up a internet site on a PC, I suppose usingeither CuTCP or
Linux or something along that line, but the local school he's at runs 
an old IBM with Tn3270. I've heard, somewhere, that it's possible to do such,
but I'm not sure.

Is it possible? Please reply to 71202.1313@compuserve.com or me, and I'll
forward it to him.

Thanks.

 - Mark

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 93 20:35:34
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: info on tcp-ip layer on atm layer

In article <CBEzFE.5oM@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
   >Also is there a specific news group on atm?

   Yes.  The name is encrypted to make it harder to locate. :-( 
   ATM is discussed in comp.dcom.cell-relay.  Way back when I had proposed 
   comp.protocols.atm, but that made too much sense and was devoid of 
   marketing terminology.

I gather that there are other cell-relay technologies as well, but
only ATM is generating flames at present.  If the others were, they
would be showing up on comp.dcom.cell-relay as well.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
The driver was also careful to observe the strict New York City Vehicle Horn
Code, under which it is illegal to honk your horn except to communicate one of
the following emergency messages: 1) the light is green, 2) the light is red,
3) I hate you, 4) this vehicle is equipped with a horn.	-- Dave Barry

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Aug 1993 16:44:12 GMT
From:      doc@magna.com (Matthew J. D'Errico)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.unix.admin,comp.unix.misc
Subject:   Internet Firewall info/advice...

I'm interested in any info anyone can offer regarding Internet firewall
strategies or recommendations for commercial and/or the security conscious.

Actual implementation advice, real life experiences, and/or references
to written material would be greatly appreciated !

Please respond via email -- I'll summarize if appropriate...

Thanx and regards !

-- Doc

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Aug 1993 21:38:32 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP book recommendations sought

Craig's list of books is directly on target.

  The only note I would add is that Marshall Rose's THE SIMPLE BOOK
should be appearing in a 2nd Edition at a bookstore sometime later
this year.  The 1st edition covers SNMPv1 really well.  The 2nd
Edition will cover SNMPv2 and will probably be as high quality.

Ran
atkinson@itd.nrl.navy.mil

P.S.
  Add most of Craig's disclaimer here.  I also hang out in the IETF
and deal with some of these folks periodically.



-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8 Aug 1993 00:16:26 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: info on tcp-ip layer on atm layer

In article <1993Aug4.154817.11680@hubcap.clemson.edu> hnatara@eng.clemson.edu writes:
>I would like to know the standard size of a packet which is made up of 
>a recombination of atm cells when a tcp-ip layer is on top of an atm layer.

Well, the overhead due to the AAL frame is in the AAL specification.
AAL5 is what everyone is using (well, everyone except the phone
companies who use AAL1 for telephone voice).  If one read's Juha's
recent RFC on "Multiprotocol Encapsulation over ATM Adaptation Layer
5" (whose number I forget, don't ask, just ftp the rfc-index from the
RFC archive site near you), one can find out the gory details of
IP/AAL5 interaction.  TCP remains TCP, same as always.  The size of
the TCP datagram varies as usual with the protocol and usage.  There
is an Internet Draft out that proposes 9180 octets as the default IP
MTU for use over ATM AAL5, however that MTU could be negotiated using
the ATM signalling protocol to be as low as 576 octets or as high as
65534 octets.

I'm not sure this answers the original question, but then I'm not sure
I understood the original question.

>Also is there a specific news group on atm?

Yes.  The name is encrypted to make it harder to locate. :-( 
ATM is discussed in comp.dcom.cell-relay.  Way back when I had proposed 
comp.protocols.atm, but that made too much sense and was devoid of 
marketing terminology.

Ran
atkinson@itd.nrl.navy.mil



-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1993 10:12:14 +1000
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: PORTING FROM SOCKET TO TLI

invernic@sassella.ICO.OLIVETTI.COM (Roberto Invernici) writes:

>	I'm trying to figure out which could be the amount of job has to
>	be done for porting a huge application from socket (AF_INET) to TLI.
 
>Which are the possible troubles may arise doing that? 

sockets code often presumes use of select() as a way of doing async I/O
so you need to have a way of doing non-blocking event queues. As long
as you get that from a TLI it should be ok.

When I've had to re-target socket code to a non-socket i/o method I've
usually written wrappers to the underlying interface that look at least
SOMETHING like the sockets call. the fd is just a numeric descriptor so
its not too hard to either re-use what the underlying code has or else
maintain a small mapping table and use the index as a pseudo-fd.

ISODE is targetted onto sockets, bizzare non-socket I/O and TLI and is
out there for FTP. you want to look at the compat/ and tsap/ directories
for examples of tying an upper layer onto both. I didn't do any of this,
its what I use when I need a working example.

-George

-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sun, 08 Aug 93 03:09:46 GMT
From:      martin@mkas.mcs.com (Matthew Martin)
To:        comp.protocols.tcp-ip
Subject:   Little Big Lan or LBL, does anyone know if they have an email address

Does anyone know if LBL, which I think stands for Little Big Lan, has an
email address?  If so what is it.  I what to get some information.  Any 
other info like telephone numbers would be great also.

Thanks,

Matt.


           /--------------------------------------\
           | Matthew Martin       Bolingbrook IL. |
           |         martin@mkas.mcs.com          |
           |                 _?_                  |
           |                (o o)                 |
           \--------------oO-(_)-Ooo--------------/

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 93 15:16:14
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: Need information on Internet Policies

paul@ace.acadiau.ca (Paul Steele) writes:

   Up until now, we have always allowed all of our users full
   internet access from anywhere on campus.  Now that I have our
   router up and running, I am setting up some filtering to prevent
   certain types of access.  The question has come up concerning
   internet access from public (student) labs.  We have heard that
   it is against internet  policy to allow unauthenticated
   access to the network. If that is the case then we can certainly
   do it, but our students sure won't be happy.

   Please let me know what the situation is, and if there is any
   documentation where this policy is stated.  If there is a more appropriate
   group to post this message, please let me know what it is.

ariel.unm.edu:/ethics is supposed to hold several dozens of policy papers from
many institutes,  maybe you can find there some usefull stuff.

Cheers,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8 Aug 1993 20:27:23 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Firewall info/advice...

In article <CBEEHp.Dx1@magna.com> doc@magna.com writes:

>I'm interested in any info anyone can offer regarding Internet firewall
>strategies or recommendations for commercial and/or the security conscious.
>
>Actual implementation advice, real life experiences, and/or references
>to written material would be greatly appreciated !
>
>Please respond via email -- I'll summarize if appropriate...

I'm very interested in this too.
Try FTP'ing to pub/docs/firewalls at decuac.dec.com
and ftp.greatcircle.com

There's a lot of info, but I'm having difficulty printing it
because most of it's in postscript and my laserjet wont handle
it.  I tried copying the file to a supposedly PS printer at a
client's last week, but it just printed rubish...

Please summarise what you find and I will copy you with any info
I get.

-- 

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

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8 Aug 1993 21:10:15 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?


	We have had the same thing happen at Oklahoma State University after
we installed some 10baseT  hubs.  It totally paralyzed our Sun Sparc which
didn't seem to know what to do with the packets.  As soon as the source of the
bombardment was removed, the Sun stopped choking and began to function properly,
again.

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

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1993 10:17:58 -0500
From:      bataller@afya.acs.uwosh.edu (Erik M. Bataller)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Help:  MAC/TCP, bootp, server, Dynamic IP

Hello,
	I have been having a lot of trouble getting Macintoshes to utilize 
the MAC/TCP server selection.  It's an odd problem and I have it on a 
few MAC's.  I believe I am running 7.1 with phase II, MacTcp 1.1.1.  If
I setup manually they are able to initialize the MAC/tcp drivers, If I set
it for server they cannot initialize the TCP/ip drivers or they say
dynamic allocation isn't available(??).  It worked and we tried to upgrade
the MAC/tcp and the network drivers and now it don't work.  I was wondering
if someone could give me:

	-  The run down on versions of the various drivers and OS's and 
	   what not that they working.
	   
	-  What MAC/TCP Server selection should get you, the bootp server
	   I am using can handout any piece of info, but I am unable to 
	   leave the Gateway blank???  A run down of how the MAC/TCP
	   utilizes the Server selection would be very helpful.
	   
	-  Any suggestions you have found and any experience with bootp/
	   dynamic allocation would be great.
	   
Thanks

Erik



-- 
!!  Erik M. Bataller | Phone: (414) 424-0347 | Univ. of Wi., Oshkosh 
!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
!!  Oshkosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
!!  Bitnet: Bataller@oshkoshw.bitnet

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1993 09:58:36 -0400
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp client for shell scripts needed.

In article <23ruc2$9c0@vtserf.cc.vt.edu> akingdom@vtaix.cc.vt.edu (Sandy Knapp) writes:

>I am trying to ftp files from script (sh) files. Does anyone know of a
>ftp client that does this easily (say 'grab <host> <account> <pass> <file>')?
>
>Or are there other tricks to do this sort of thing?

ncftp 1.0.2 can do this (check archie for the location nearest you).
There's also Spaf's perl-ftp package which works really well, but only
does a "get".  (A new version that does a "put" is expected in the next
week or so.)

Tom

-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.org (play)
"Some people run 'biff' to alert them that  | Disclaimer:  I do not
they have new email.  I run '/bin/true'".   | speak for Mentor Graphics.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Aug 93 12:44:09 GMT
From:      kwli@esk.compserv.utas.edu.au (Ringo K. LI)
To:        comp.protocols.tcp-ip
Subject:   msg struct to send msg to talkd or ntalkd daemon ??


Hi netter.

My client program needs to be able to communicate with the "talkd" daemon of 
the unix However, I do not have the message structure that used by Sun Unix 
(Sun 4.3.1).

I have the message structure for BSD (which I ftp from bsd source code), 
but the message structure from BSD is for "ntalk" !! 

Someone mentioned to me that there exists two version of message structure
for talkd !!  

Can anyone out there have any idea of how to locate information about it??

I try to check in the Manual and rfc but no luck. 

Please respond by email (if possible) to kwli@esk.compserv.utas.edu.au

Thanks 

Ringo Li (kwli@esk.compserv.utal.edu.au )
Department of Applied Computing
University of Tasmania at Launcestion


-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 93 12:59:25 GMT
From:      rkirk@oasys.dt.navy.mil (Randy Kirk)
To:        comp.protocols.tcp-ip
Subject:   Programming TCP/IP from Windows


	I am looking for a product that will allow me to write a program
	with TCP/IP  calls in it.  I need to do this in windows and 
	prefer Visual Basic/Visual C as programming language.  The program
	is to allow a PC to recieve and send short messages to another PC
	on the network.  Any suggestion for a programming tool would be 
	appreciated.


							Thanks
							Randy
							rkirk@oasys.dt.navy.mil



-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1993 14:20:17 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Strange giant packets in a LAN

In article <23j2qn$3ri@munich.ixos.de> snoopy@munich.ixos.de (Snoopy) writes:
>
>I am getting lots of messages from the SUN consoles saying
>
>"giant packet recived from <ethernet address>"
>
>When I use arp -a etc. to find out who sends the packets, its very
>strange: sometimes they emanate from a SUN, sometimes from an NCD X-Terminal
>and sometimes from our Cisco-Router.
>
>My question is: what is the most common cause for giant packets ?
>

Several causes of giant packets are noted in this newsgroup from time to
time. If you are seeing packets reported with "real" ethernet addresses,
at least one cause seems to be that the packets are actually two ethernet
frames, where the sender of the second packet did not "hear" the sender
of the first packet, who was already transmitting, before the sender of 
the second packet started to transmit. This can be a "broke hardware"
problem, which is hard to find because you don't know where the second
packet starts to pick up the ethernet address, or it can be a "LAN too
big" problem, where the propagation delay from one end of your ethernet
segment to the other exceeds ethernet specs. Some LAN analysis tools call
these "late collisions".

If inserting a MAC-level bridge in the middle of your ethernet segment
makes the messages go away, you have the second type of problem and need
to look at your LAN layout again. You may have too many "fanout boxes"
(10BASE-T), or too long a piece of coax (10BASE-5), depending on what
type of ethernet you're using.

If inserting a MAC-level bridge does not make the messages go away on 
BOTH sides of the bridge, you are looking for broken hardware. If you know
what was being installed when you first saw the messages, this is often
helpful.

At least, this has been my experience.
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1993 17:01:53 GMT
From:      mgrice@athena.mit.edu (Matthew Grice)
To:        comp.protocols.tcp-ip
Subject:   SLIP server (starting) ??

The computer I log into (UNIX@19.2 Kbaud)
goes into a terminal emulation type of mode.
Is there any way that I can install a SLIP
server to start up a slip connection after
logging in?  How is this sort of thing done?
It'll be an Ultrix computer, I think, and
I'm not a superuser.  Is this possible?
If it's not, it should be!

-Matt



-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 93 19:56:39 GMT
From:      luce@ccit21.duq.edu (Douglas Luce)
To:        comp.protocols.tcp-ip
Subject:   One ethernet, two network numbers


I've got a single Ethernet, and I'm researching the possibility of running
two networks.  We've got a Class C network running on a single Ethernet,
and it would be nice to be able to slowly switch individual hosts on
this Ethernet over to our new Class B number, while retaining hosts
with Class C numbers on that net.

A few preliminary tests (with our NeXT's) show some problems.  If I take
one NeXT, and give it a Class B IP number, then add a route to it's table
pointing at the Class C net through it's Ethernet, and then take a second
host with a Class C number, point at the Class B net through it's
Ethernet, I get odd results.  I can ping either host from the other,
but Telnet bombs (from the Class B side, it looks like no communication
occurs at all.  From the Class C side, it connects, but then hangs).

Any quick clues as to what I'm running in to?

Doug Luce
CCIT
Duquesne University

(Pardon to anyone who sees this reposted; my news software is lacking)
 

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Aug 1993 20:06:26 GMT
From:      rawn@Seagull.RTD.COM (Rawn Shah)
To:        comp.protocols.tcp-ip
Subject:   Re: Programming TCP/IP from Windows

From article <41129@oasys.dt.navy.mil>, by rkirk@oasys.dt.navy.mil (Randy Kirk):
> 
> 	I am looking for a product that will allow me to write a program
> 	with TCP/IP  calls in it.  I need to do this in windows and 
> 	prefer Visual Basic/Visual C as programming language.  The program
> 	is to allow a PC to recieve and send short messages to another PC
> 	on the network.  Any suggestion for a programming tool would be 
> 	appreciated.
> 

There are many commercial packages which have developer kits for writing
TCP/IP applications for PCs. There is also a standard which helps in this
area known as the Windows Sockets API. The description for this is available
via ftp from sunsite.unc.edu:/pub/micro/pc-stuff/ms-windows/winsock/*
To use this API however, you need a DLL from some commercial vendor
currently. Soon there may be a shareware implementation of this. 

If you need a list of the commercial vendors look in the (PC)NFS FAQ list
available from:
	seagull.rtd.com:/pub/tcpip/pcnfsfaq.zip
> 
> 							Thanks
> 							Randy
> 							rkirk@oasys.dt.navy.mil
> 
> 

--
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------
-- 
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Aug 1993 20:19:34 GMT
From:      rawn@Seagull.RTD.COM (Rawn Shah)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Help:  MAC/TCP, bootp, server, Dynamic IP

From article <245pr6$qvv@afya.acs.uwosh.edu>, by bataller@afya.acs.uwosh.edu (Erik M. Bataller):
> Hello,
> 	I have been having a lot of trouble getting Macintoshes to utilize 
> the MAC/TCP server selection.  It's an odd problem and I have it on a 
> few MAC's.  I believe I am running 7.1 with phase II, MacTcp 1.1.1.  If
> I setup manually they are able to initialize the MAC/tcp drivers, If I set
> it for server they cannot initialize the TCP/ip drivers or they say
> dynamic allocation isn't available(??).  It worked and we tried to upgrade
> the MAC/tcp and the network drivers and now it don't work.  I was wondering
> if someone could give me:
> 
Sounds like your Macintoshes are on a Localtalk network. If not disregard
the rest of the post.

> 	-  The run down on versions of the various drivers and OS's and 
> 	   what not that they working.

MacOS 6.8 & 7.x do not work together very well.

> 	   
> 	-  What MAC/TCP Server selection should get you, the bootp server
> 	   I am using can handout any piece of info, but I am unable to 
> 	   leave the Gateway blank???  A run down of how the MAC/TCP
> 	   utilizes the Server selection would be very helpful.

There needs to be a DDP-IP gateway for MacTCP to be used on a Localtalk
network. This assigns the information via Bootp, etc. Currently these are
hardware gateways only. 

> 	   
> 	-  Any suggestions you have found and any experience with bootp/
> 	   dynamic allocation would be great.
> 	   
> Thanks
> 
> Erik
> 
> 
> 
> -- 
> !!  Erik M. Bataller | Phone: (414) 424-0347 | Univ. of Wi., Oshkosh 
> !!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
> !!  Oshkosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
> !!  Bitnet: Bataller@oshkoshw.bitnet

--
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------
-- 
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Aug 1993 20:25:03 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP (& UDP) without 'acknowledgements'

In <Aug.6.13.28.47.1993.22183@caip.rutgers.edu> azia@caip.rutgers.edu (Ashar Zia) writes:

>Hi guys,

+> I want to transfer data from host A to host B. Ideally one would send a block
+>of data to B, then get acknowledgement from B and transfer next block of data.
+>The problem is that we want to save the time needed for acknowledgements as
+>there will always be oneway transfer of data. 

	The way you do this in tcp is to expand the window.  There is an
RFC (1323?) that defines how with tcp options to grow the window huge.
(past 64k).  If you get the window big enough and do only one ack per
window, you have what you want.

	The congestion control stuff in tcp should take care of making
the window smaller based on conditions.



> Consider the same problem with UDP where we don't care about the lost packets
>as long as we can get some syncronization and don't 'send' data at a faster
>rate than 'receiving' data.

+> The whole thing becomes more complex as we consider three nodes:
+>We want data from host A to be sent to host B; now host B after receiving data
+>sends it to host C. The problem comes at host B:- it can be receiving at a 
+>slower rate and sending data to C at slower rate..  So there has to be some
+>concept of syncronization. Any ideas about achieving this synchronization 
+>without ACKNOWKLEDGEMENTS ? (or it might not be possible to get that 
+>syncronization without ACK ?)

	The only way to get such conditions is to have a point-to-point
link between two systems or something else that guarentees bandwidth,



-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Aug 1993 21:48:54 GMT
From:      johnl@chico.iecc.com (John R Levine)
To:        comp.protocols.tcp-ip,comp.unix.pc-clone.32bit
Subject:   POP server for ISC Unix?


Does anyone have a POP2 or POP3 server for ISC Unix?
Or failing that, a working server that talks TLI or sockets?
Archie was surprisingly unsuccessful in turning anything up.

TIA,
-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.com, {ima|spdcc|world}!iecc!johnl
"Time is Money!  Steal some today!"

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Aug 1993 21:51:27 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: One ethernet, two network numbers

In article <245pnf$hb6@noether.duq.edu> luce@ccit21 writes:

>I've got a single Ethernet, and I'm researching the possibility of running
>two networks.  We've got a Class C network running on a single Ethernet,
 
>Any quick clues as to what I'm running in to?

What subnet numbers does the router port attached to the subnet have?
In order for the setup to work, the router port should have the main
C subnet number AND the new B subnet number (allocated as a secondary
subnet).  (Ie. the router is made to believe you've got two subnets
on the one wire.)   Cisco routers allow secondary subnet addresses, 
but I'm not sure about other routers.

Look also at your subnet mask settings.  The C hosts must have 
255.255.255.0 and the Bs 255.255.0.0, unless you are doing some
more elegant subnetting.

Under these settings, the router will redirect a message from a C
to a B, by telling the C "the B is actually on this subnet, with 
an ethernet address of xx.xx.xx.xx.xx.xx".

Are you sure you've got ARP set up on all the hosts?

If this doesn't help, can you describe the setup some more?


Regards,

-- 

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

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1993 21:58:54 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.protocols.tcp-ip
Subject:   Default routing question

Last week someone activated RIP on a host on one of our Ethernets. This
host then started to broadcast it's default routing address. This seems
to have taken down the router between this Ethernet and the outside
world. The router that went down was, in fact, the default router for
this Ethernet.

It doesn't seem to me that a host should ever broadcast it's default
routing address. I don't understand what the recipient of such a
broadcast would do with it.

I haven't seen anything about this situation in my references - any
insights would be much appreciated.

Thank you,

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

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 93 22:33:08 GMT
From:      thogard@robins.af.mil (Cont Tim Hogard;653 CCSG/SCDI)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Firewall info/advice...

Phil Royse (proyse@peeras.demon.co.uk) wrote:

: >I'm interested in any info anyone can offer regarding Internet firewall
: >strategies or recommendations for commercial and/or the security conscious.
: >
: >Actual implementation advice, real life experiences, and/or references
: >to written material would be greatly appreciated !
 
: I'm very interested in this too.
: Try FTP'ing to pub/docs/firewalls at decuac.dec.com
: and ftp.greatcircle.com
 
: There's a lot of info, but I'm having difficulty printing it
: because most of it's in postscript and my laserjet wont handle
: it.  I tried copying the file to a supposedly PS printer at a
: client's last week, but it just printed rubish...

There is going to be 1 day tutorial program at the 4th Unix Security Symposium
put on by Usenix.  For info contact: conference@usenix.org

-tim

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1993 23:58:10 GMT
From:      ross@matadero.ncd.com (Ross Oliver)
To:        comp.protocols.tcp-ip
Subject:   Example bootp client wanted

I am trying to write a bootp client that sends a bootp
request and prints out the info bootpd returns, to be
used for debugging booting problems.  I've gotten my
program to send a bootp request, and bootpd sees it,
but I can't pick up the response.  Does anyone have
some sample code, or a PD implementation of HP's
bootpquery?  All leads appreciated.


Ross Oliver
NCD Technical Support
ross@ncd.com
---------------------------
"Flying is the art of learning to throw yourself at the ground, and miss."
                                           -- Hitchhiker's Guide to the Galaxy

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Aug 1993 02:32:59 GMT
From:      mdl@cypress.com (Matt Landrum)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Strange giant packets in a LAN

In article <245mf1$1gh@crchh327.bnr.ca> dawkins@bnr.ca (Spencer Dawkins) writes:



   Several causes of giant packets are noted in this newsgroup from time to
   time. If you are seeing packets reported with "real" ethernet addresses,
   at least one cause seems to be that the packets are actually two ethernet
   frames, where the sender of the second packet did not "hear" the sender
   of the first packet, who was already transmitting, before the sender of 
   the second packet started to transmit. This can be a "broke hardware"
   problem, which is hard to find because you don't know where the second
   packet starts to pick up the ethernet address, or it can be a "LAN too
   big" problem, where the propagation delay from one end of your ethernet
   segment to the other exceeds ethernet specs. Some LAN analysis tools call
   these "late collisions".

good input, I'm getting these messages from virtually all of my new
SPARC10s on subnets with TPRMIMs (Twisted Pair Repeater Media
Interface Module... or sometthing like that).  I don't think I have a
length problem.  The SPARC10s and the Cabletron equipment are new.
Anybody have a suggestion as to how to narrow down the problem?


thanks,
matt

--


Matt Landrum, CAD Engineer      | e-mail: mdl@cypress.com
Cypress Southeast Design Center | office: (601) 324-4609, FAX - 4614
1 Research Blvd, Suite 200      | "You can get what you want if you
Starkville, MS  39759           | know how to find it." -- Tower of Power



-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1993 11:47:20 -0500
From:      tumlin@cs.utexas.edu (Evelyn Tumlin)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Two TCP/IP hosts who aren't speaking

Hi again.  It's me, with the four-AT&T workstation cluster.  (two
StarServers, two 386 towers, both running UNIX System V r.4.)  I
posted a little while ago about a problem whereby two of my machines
won't talk to each other via telnet, rlogin or ftp.  Both machines
can contact any other machines (including machines not in the NFS
cluster) and be contacted by them -- they just aren't speaking to
each other.

I have received several helpful suggestions that I check the arp
tables.  However, this is not the problem, as it turns out that sometimes
if I wait a LONG time (or am lucky) a telnet connection may be established 
between the two machines, but it then hangs before the login prompt is
received.  In these cases, I have to hit the escape character several
times; the resulting session looks like this:

----------------------------------------------------------
Trying 128.83.138.146 ...
Connected to <my machine>
Character mode is enabled.
Escape character is '~'.
~
~

telnet> close  /* Nothing happens here until I hit <delete>.  Then I get: */
Connection closed.
net can't write..(9)
<my machine>: Bad file number
Connection closed.
Connection closed by foreign host.
telnet>
----------------------------------------------------------

I'm poring over manuals, but I haven't yet found anything apropos.
Help?

Lyn Tumlin (tumlin@cs.utexas.edu)

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1993 12:14:38 -0500
From:      bataller@afya.acs.uwosh.edu (Erik M. Bataller)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Racal INterlan: drivers for ni5210???

Hello All,
	Does anyone know where the latest and greatest drivers for 
Racal Interland NI5210 card are?  I am interested in both packet
drivers and ODI drivers.   


THanks 


Erik


-- 
!!  Erik M. Bataller | Phone: (414) 424-0347 | Univ. of Wi., Oshkosh 
!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
!!  Oshkosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
!!  Bitnet: Bataller@oshkoshw.bitnet

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1993 16:02:10 -0500
From:      kafka@genesis.MCS.COM (Kevin A. Chin)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   WAN course recommendation

I would some recommendations on WAN technology courses/books.

Currently I know how to build a small LAN on a floor
of a building. I would like to know how to extend
this to:

	1) Several floors
	2) Several buildings
	3) possibly several cities

I was considering taking courses from Sun, Cisco, SynOptics
but I was worried about product bias from the instructors.

Part of the problem is that I may need products from each
of the above vendors, but I don't neccesarily want to commit
to these vendors exclusively (ie un-biased instruction).

thanks.
Kevin A. Chin
kafka@genesis.mcs.com



-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1993 13:06:07 GMT
From:      dale@access.digex.net (Dale Farmer)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Strange giant packets in a LAN

Matt Landrum (mdl@cypress.com) wrote:

: good input, I'm getting these messages from virtually all of my new
: SPARC10s on subnets with TPRMIMs (Twisted Pair Repeater Media
: Interface Module... or something like that).  I don't think I have a
: length problem.  The SPARC10s and the Cabletron equipment are new.
: Anybody have a suggestion as to how to narrow down the problem?

	As an experiment, take one of the SPARC10s and the TPRIM with it
and set it up near the center of the network.  look and see of it is still
doing the same thing.  remove the TPRMIN, look again.  if it still does it
with or without the TPRMIM device in line, sounds like a hardware problem.
If it does not do it, sounds like a propagation delay problem.  

	Also if you have a bridge or router laying around you might want
to stick  it in the middle somewhere and see if it fixes the  problem. 

	draw out on a piece of paper your network showing all repeaters,
bridges, cable types, cable lengths, and number of stations on each
segment of cable.  obtain a copy of the ethernet rules for all of the
media types you have.  Check carefully each rule and see if you may have
violated any.  Are the TPRMIMs repeaters?...

	If you have a thinnet coax segment in your network, physically
examine all of the jumpers between the wall plates and the computers.  You
are looking for the enterprising fellow (or lady) who went to radio shack
and bought two more pieces of coax cable to extend the length so he could
rearrange the office/lab, and used RG/59 instead of RG/58.  

	RG/58 is 50 ohm nominal impedance, RG/59 is 75 ohm impedance. 
RG/59 is used in television stuff and is at first and second glance
identical in appearance to RG/58.  And will work in ethernet, but only in
very small networks (couple of machines close together)

good luck.

--Dale Farmer


-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Aug 1993 15:45:38 GMT
From:      peterg@eng.krldwa.mccaw.com (Peter Gregory)
To:        misc.books.technical,comp.protocols.tcp-ip,comp.dcom.lans,comp.sys.sequent,comp.sys.sun.admin
Subject:   OSI books sought

I need some book-buying advice.  I'll soon be providing professional services to
a firm which runs an OSI (not IP) LAN and WAN.  This WAN has Retix routers,  
Sun 2000s, and Sequent 2000/450s, all running the OSI protocol stack rather than
the IP protocol stack.

I need one or more good books to get me up to speed.  I'm good with TCP/IP, but
know next-to-nothing about OSI.

Info on FAQs, mailing lists, newsgroups also solicited and appreciated.

Thanks again!

[I'd like to thank all who responded to my recent request for technical books on 
TCP/IP WAN and LAN issues.  Big help...]

---

Pete Gregory   peterg@eng.krldwa.mccaw.com  |  "It may be rice wine to you,
Senior Consultant. ASIX, Inc., Seattle, WA  |  but it's sake to me."
on-site at McCaw Cellular Communications, Kirkland, WA


-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Aug 93 17:26:38 GMT
From:      ramiro@ctt.bellcore.com (Ramiro Reinoso)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP (& UDP) without 'acknowledgements'

In article <visser.744927903@convex.convex.com>, visser@convex.com (Lance Visser) writes:
|> In <Aug.6.13.28.47.1993.22183@caip.rutgers.edu> azia@caip.rutgers.edu (Ashar Zia) writes:
|> 
|> >Hi guys,
|> 
|> +> I want to transfer data from host A to host B. Ideally one would send a block
|> +>of data to B, then get acknowledgement from B and transfer next block of data.
|> +>The problem is that we want to save the time needed for acknowledgements as
|> +>there will always be oneway transfer of data. 
|> 

I agree with previous posting that opening the TCP window might solve
your problem although you were not clear in specifying whether the
acknowledgements were to be generated by the application receiving
the block of data or by the TCP protocol.

At any rate, the following formula will tell you how big your
window should be based on the round trip delay of the network and
the speed of the slowest transmission link.

Minimum Window Size = Throughput * round-trip Delay/8   (Bytes)

If your window size is greater than the one given by this formula,
then the acknowledgements should not have an adverse effect on the
performance of your transmission.

e.g., in a cross-country T1 ciruit (1.544 Mbps and 60 millisencods
round trip delay), the minimum window size should be 12 Kilobytes.
If you make your window at least 12 Kilobytes, you should be able
to obtain close to 1.544 Mbps accross this link.  A smaller window
will limit the transfer rate because the transmitter has to wait for
acknowledgements.  A bigger window won't make a difference because
you cannot transmitt faster than 1.544 Mbps.

-- 
--------------------------------------------------------------------
|Ramiro E. Reinoso         | E-mail: ramiro@ctt.bellcore.com	   |
|Bellcore                  | Phone : (908) 699-5021		   |
|444 Hoes Lane, 1D-222     | "The simplest solution is usually the |
|Piscataway, NJ 08854      |  correct one." E. Rechtin             |
--------------------------------------------------------------------


-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Aug 93 17:31:45 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: Two TCP/IP hosts who aren't speaking

In Article <m6fk8oINN7jl@latexo.cs.utexas.edu>
tumlin@cs.utexas.edu (Evelyn Tumlin) writes:
>Hi again.  It's me, with the four-AT&T workstation cluster.  (two
>StarServers, two 386 towers, both running UNIX System V r.4.)  I
>posted a little while ago about a problem whereby two of my machines
>won't talk to each other via telnet, rlogin or ftp.  Both machines
>can contact any other machines (including machines not in the NFS
>cluster) and be contacted by them -- they just aren't speaking to
>each other.
>
>I have received several helpful suggestions that I check the arp
>tables.  However, this is not the problem, as it turns out that sometimes
>if I wait a LONG time (or am lucky) a telnet connection may be established 
>between the two machines, but it then hangs before the login prompt is
>received.  In these cases, I have to hit the escape character several
>times; the resulting session looks like this:

This is just a shot in the dark, but are the machines on the same coax cable?
Maybe thin Ethernet (10Base2)? If there is a physical problem on the cable, you
may have a standing wave on the line that interferes with packets between these
two systems and NOT with packets to other systems, even on the same coax.

While this sounds far-fetched, I have seen it more than once, usually from
either a "T" in the cable (not attached directly to a controller) or a segment
of the wrong cable (RG-59).

In one case my own workstation could not talk reliably with the worstation 15
feet away, but both stations could talk to any other system on the net just
fine. I TDRed the cable and the problem was VERY obvious. Two offices away
someone moved his workstation a few feet and extended the cable with a piece
of RG-59. He couldn't believe that it really made any difference, but he was
a CS tech who had no knowledge of transmission lines. To him, wire was wire and
if it fit, it should work. But I'm letting my Engineering bias show.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 93 20:23:21 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.internals
Subject:   ttcp benchmark ported to TLI


Hi,

	For various reasons, I recently modified the venerable ttcp
benchmark program to run atop TLI rather than sockets.  I've enclosed
the results below for your enjoyment.  There are several observations
I made as a result of my experience:

	1. TLI leads to more verbose code since it is both
	   more general (e.g., supports transport independence)
	   and more primitive (i.e., requires the programmer to
	   handle certain aspects that sockets perform
	   automatically, such as concurrent servers with listen
	   queues > 1).

	2. The TLI socket and TCP option handling format is
	   quite obscure (probably the best kept secret
	   since the Manhatten project ;-)).  If for no other reason,
	   you might want to check out how options are passed via
	   TLI (see struct sochdr and the SET_SO_OPTION macro below).

	3. The performance differences between the TLI-based version
	   of ttcp and the socket-based version do not appear to
	   be significant.  I did some rough benchmarking on our
	   SPARCserver 1000 2-CPU machine and really didn't notice
	   any measurable difference whatsoever (i.e., sometimes
	   TLI came out ahead, sometimes sockets, but not by much
	   and not with any discernable pattern).  I'd be interested
	   if anyone else performs more controlled benchmarks
	   that indicate a performance advantage with one or the
	   other.

	   (BTW, SPARCservers running TCP in loopback mode are
	   pretty speedy -- I was routinely getting ~80 - 120
	   megabits/sec transmitter-to-receiver performance).

	Please send all questions or comments to me.

	Thanks,

		Doug

----------------------------------------
/*
 *      T T C P . C
 *
 * Test TCP connection.  Makes a connection on port 5001
 * and transfers fabricated buffers or data copied from stdin.
 *
 * Usable on 4.2, 4.3, and 4.1a systems by defining one of
 * BSD42 BSD43 (BSD41a)
 * Machines using System V with BSD sockets should define SYSV.
 *
 * Modified for operation under 4.2BSD, 18 Dec 84
 *      T.C. Slattery, USNA
 * Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.
 * Modified in 1989 at Silicon Graphics, Inc.
 *      catch SIGPIPE to be able to print stats when receiver has died
 *      for tcp, don't look for sentinel during reads to allow small transfers
 *      increased default buffer size to 8K, nbuf to 2K to transfer 16MB
 *      moved default port to 5001, beyond IPPORT_USERRESERVED
 *      make sinkmode default because it is more popular,
 *              -s now means don't sink/source
 *      count number of read/write system calls to see effects of
 *              blocking from full socket buffers
 *      for tcp, -D option turns off buffered writes (sets TCP_NODELAY sockopt)
 *      buffer alignment options, -A and -O
 *      print stats in a format that's a bit easier to use with grep & awk
 *      for SYSV, mimic BSD routines to use most of the existing timing code
 * Modified by Steve Miller of the University of Maryland, College Park
 *      -b sets the socket buffer size (SO_SNDBUF/SO_RCVBUF)
 * Modified Sept. 1989 at Silicon Graphics, Inc.
 *      restored -s sense at request of tcs@brl
 * Modified Oct. 1991 at Silicon Graphics, Inc.
 *      use getopt(3) for option processing, add -f and -T options.
 *      SGI IRIX 3.3 and 4.0 releases don't need #define SYSV.
 * Modified by Douglas C. Schmidt August 10. 1993
        rewrote ttcp to run atop TLI rather than sockets
 * Distribution Status -
 *      Public Domain.  Distribution Unlimited.
 */
#ifndef lint
static char RCSid[] = "ttcp.c $Revision: 1.9 $";
#endif

/* #define BSD43 */
/* #define BSD42 */
/* #define BSD41a */
#define SYSV /* required on SGI IRIX releases before 3.3 */

#include <stdio.h>
#include <signal.h>
#include <ctype.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/fcntl.h>
#include <tiuser.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/time.h>           /* struct timeval */

/* Set the socket options using TLI conventions... */

#define SET_SO_OPTION(SOCHDR, LEVEL, OPTION, SIZE, VALUE) \
  do { SOCHDR.opthdr.level = LEVEL; SOCHDR.opthdr.name = OPTION; \
       SOCHDR.opthdr.len = SIZE; SOCHDR.value = VALUE; } while (0)

#if defined(SYSV)
#include <sys/times.h>
#include <sys/param.h>
struct rusage
{
  struct timeval ru_utime, ru_stime;
};

#define RUSAGE_SELF 0
#else
#include <sys/resource.h>
#define memcpy(A,B,C) bcopy ((A),(B),(C))
#define memset(A,B,C) bzero((A),(C))
#endif /* SYSV */

struct sockaddr_in sinme;
struct sockaddr_in sinhim;
struct sockaddr_in frominet;

int fromlen;
int fd;                         /* fd of network socket */

int buflen = 8 * 1024;          /* length of buffer */
char *buf;                      /* ptr to dynamic buffer */
int nbuf = 2 * 1024;            /* number of buffers to send in sinkmode */

int bufoffset = 0;              /* align buffer to this */
int bufalign = 16 * 1024;       /* modulo this */

int udp = 0;                    /* 0 = tcp, !0 = udp */
int options = 0;                /* socket options */
int one = 1;                    /* for 4.3 BSD style setsockopt() */
short port = 5001;              /* TCP port number */
char *host;                     /* ptr to name of host */
int trans;                      /* 0=receive, !0=transmit mode */
int sinkmode = 0;               /* 0=normal I/O, !0=sink/source mode */
int verbose = 0;                /* 0=print basic info, 1=print cpu rate, proc
                                 * resource usage. */
int nodelay = 0;                /* set TCP_NODELAY socket option */
int b_flag = 0;                 /* use mread() */
int sockbufsize = 0;            /* socket buffer size to use */
char fmt = 'K';                 /* output format: k = kilobits, K = kilobytes,
                                 *  m = megabits, M = megabytes,
                                 *  g = gigabits, G = gigabytes */
int touchdata = 0;              /* access data after reading */

struct hostent *addr;
extern int errno;
extern int optind;
extern char *optarg;

char Usage[] = "\
Usage: ttcp -t [-options] host [ < in ]\n\
       ttcp -r [-options > out]\n\
Common options:\n\
        -l ##   length of bufs read from or written to network (default 8192)\n\
        -u      use UDP instead of TCP\n\
        -p ##   port number to send to or listen at (default 5001)\n\
        -s      -t: source a pattern to network\n\
                -r: sink (discard) all data from network\n\
        -A      align the start of buffers to this modulus (default 16384)\n\
        -O      start buffers at this offset from the modulus (default 0)\n\
        -v      verbose: print more statistics\n\
        -d      set SO_DEBUG socket option\n\
        -b ##   set socket buffer size (if supported)\n\
        -f X    format for rate: k,K = kilo{bit,byte}; m,M = mega; g,G = giga\n\
Options specific to -t:\n\
        -n##    number of source bufs written to network (default 2048)\n\
        -D      don't buffer TCP writes (sets TCP_NODELAY socket option)\n\
Options specific to -r:\n\
        -B      for -s, only output full blocks as specified by -l (for TAR)\n\
        -T      \"touch\": access each byte as it's read\n\
";

char stats[128];
unsigned long nbytes;           /* bytes on net */
unsigned long numCalls;         /* # of I/O system calls */
double cput, realt;             /* user, real time (seconds) */

void err ();
void mes ();
int pattern ();
void prep_timer ();
double read_timer ();
int Nread ();
int Nwrite ();
void delay ();
int mread ();
char *outfmt ();

void
sigpipe ()
{
}

/* See <sys/socket.h> for details on this format */

struct sochdr
{
  struct opthdr opthdr;
  long value;
} sochdr;

main (argc, argv)
     int argc;
     char **argv;
{
  unsigned long addr_tmp;
  int c;
  struct t_optmgmt *so_options;
  struct t_optmgmt *so_options_ret;

  if (argc < 2)
    goto usage;

  while ((c = getopt (argc, argv, "drstuvBDTb:f:l:n:p:A:O:")) != -1)
    {
      switch (c)
        {

        case 'B':
          b_flag = 1;
          break;
        case 't':
          trans = 1;
          break;
        case 'r':
          trans = 0;
          break;
        case 'd':
          options |= SO_DEBUG;
          break;
        case 'D':
#ifdef TCP_NODELAY
          nodelay = 1;
#else
          fprintf (stderr,
                   "ttcp: -D option ignored: TCP_NODELAY socket option not supported\n");
#endif
          break;
        case 'n':
          nbuf = atoi (optarg);
          break;
        case 'l':
          buflen = atoi (optarg);
          break;
        case 's':
          sinkmode = !sinkmode;
          break;
        case 'p':
          port = atoi (optarg);
          break;
        case 'u':
          udp = 1;
          break;
        case 'v':
          verbose = 1;
          break;
        case 'A':
          bufalign = atoi (optarg);
          break;
        case 'O':
          bufoffset = atoi (optarg);
          break;
        case 'b':
#if defined(SO_SNDBUF) || defined(SO_RCVBUF)
          sockbufsize = atoi (optarg);
#else
          fprintf (stderr,
                   "ttcp: -b option ignored: SO_SNDBUF/SO_RCVBUF socket options not supported\n");
#endif
          break;
        case 'f':
          fmt = *optarg;
          break;
        case 'T':
          touchdata = 1;
          break;

        default:
          goto usage;
        }
    }
  if (trans)
    {
      /* xmitr */
      if (optind == argc)
        goto usage;
      memset ((char *) &sinhim, 0, sizeof (sinhim));
      host = argv[optind];
      if (atoi (host) > 0)
        {
          /* Numeric */
          sinhim.sin_family = AF_INET;
#if defined(cray)
          addr_tmp = inet_addr (host);
          sinhim.sin_addr = addr_tmp;
#else
          sinhim.sin_addr.s_addr = inet_addr (host);
#endif
        }
      else
        {
          if ((addr = gethostbyname (host)) == NULL)
            err ("bad hostname");
          sinhim.sin_family = addr->h_addrtype;
          memcpy ((char *) &addr_tmp, addr->h_addr, addr->h_length);
#if defined(cray)
          sinhim.sin_addr = addr_tmp;
#else
	  sinhim.sin_addr.s_addr = addr_tmp;
#endif /* cray */
        }

      sinhim.sin_port = htons (port);
      sinme.sin_port = 0;       /* free choice */
    }
  else
    {
      /* rcvr */
      sinme.sin_family = AF_INET;
      sinme.sin_port = htons (port);
      sinme.sin_addr.s_addr = INADDR_ANY;
    }

  if (udp && buflen < 5)
    buflen = 5;               /* send more than the sentinel size */

  if ((buf = (char *) malloc (buflen + bufalign)) == (char *) NULL)
    err ("malloc");
  if (bufalign != 0)
    buf += (bufalign - ((int) buf % bufalign) + bufoffset) % bufalign;

  if (trans)
    {
      fprintf (stdout,
               "ttcp-t: buflen=%d, nbuf=%d, align=%d/%d, port=%d",
               buflen, nbuf, bufalign, bufoffset, port);
      if (sockbufsize)
        fprintf (stdout, ", sockbufsize=%d", sockbufsize);
      fprintf (stdout, "  %s  -> %s\n", udp ? "udp" : "tcp", host);
    }
  else
    {
      fprintf (stdout,
               "ttcp-r: buflen=%d, nbuf=%d, align=%d/%d, port=%d",
               buflen, nbuf, bufalign, bufoffset, port);
      if (sockbufsize)
        fprintf (stdout, ", sockbufsize=%d", sockbufsize);
      fprintf (stdout, "  %s\n", udp ? "udp" : "tcp");
    }

  if ((fd = t_open (udp ? "/dev/udp" : "/dev/tcp", O_RDWR, 0)) < 0)
    err ("socket");
  mes ("t_open");

  if ((so_options = (struct t_optmgmt *) t_alloc (fd, T_OPTMGMT, T_ALL)) == 0)
    err ("t_alloc");
  if ((so_options_ret = (struct t_optmgmt *) t_alloc (fd, T_OPTMGMT, T_ALL)) == 0)
    err ("t_alloc");

  /* Set up options for TLI */
  so_options->opt.maxlen     = sizeof sochdr;
  so_options->opt.len        = sizeof sochdr;
  so_options->opt.buf        = (char *) &sochdr;
  so_options->flags          = T_NEGOTIATE;
  so_options_ret->opt.maxlen = sizeof sochdr;
  so_options_ret->opt.len    = sizeof sochdr;
  so_options_ret->opt.buf    = (char *) &sochdr;

  if (!trans) /* Server side */
    {
      struct t_bind req;
      req.addr.maxlen = sizeof sinme;
      req.addr.len    = sizeof sinme;
      req.addr.buf    = (char *) &sinme;
      req.qlen 	      = 1;

      if (t_bind (fd, &req, 0) == -1)
	err ("t_bind");
    }
  else /* Client side */
    if (t_bind (fd, 0, 0) == -1)
      err ("t_bind");

#if defined(SO_SNDBUF) || defined(SO_RCVBUF)
  if (sockbufsize)
    {
      if (trans)
        {
	  SET_SO_OPTION (sochdr, SOL_SOCKET, SO_SNDBUF, 4, sockbufsize);
	  if (t_optmgmt (fd, so_options, so_options_ret) == -1)
            err ("t_optmgmt: sndbuf");
          mes ("sndbuf");
        }
      else
        {
	  SET_SO_OPTION (sochdr, SOL_SOCKET, SO_RCVBUF, 4, sockbufsize);
	  if (t_optmgmt (fd, so_options, so_options_ret) == -1)
            err ("t_optmgmt: rcvbuf");
          mes ("rcvbuf");
        }
    }
#endif

  if (!udp)
    {
      signal (SIGPIPE, sigpipe);
      if (trans)
        {
	  struct t_call call;
          /* We are the client if transmitting */
          if (options)
            {
	      SET_SO_OPTION (sochdr, SOL_SOCKET, options, 4, 1);
	      if (t_optmgmt (fd, so_options, so_options_ret) == -1)
		err ("t_optmgmt: debug");
            }
#ifdef TCP_NODELAY
          if (nodelay)
            {
              struct protoent *p;
              p = getprotobyname ("tcp");
	      SET_SO_OPTION (sochdr, p->p_proto, TCP_NODELAY, 4, 1);
	      if (p && t_optmgmt (fd, so_options, so_options_ret) == -1)
		err ("t_optmgmt: nodelay");
              mes ("nodelay");
            }
#endif
	  memset (&call, 0, sizeof call);
	  call.addr.maxlen = sizeof sinhim;
	  call.addr.len    = sizeof sinhim;
	  call.addr.buf	   = (char *) &sinhim;

          if (t_connect (fd, &call, 0) == -1)
	    {
	      if (t_errno == TLOOK)
		printf ("t_look = %d\n", t_look (fd));
	      else
		err ("t_connect");
	    }
          mes ("t_connect");
        }
      else
        {
          /* otherwise, we are the server and
	   * should listen for the connections
	   */

	  struct t_call *call_ptr;
	  if ((call_ptr = (struct t_call *) t_alloc (fd, T_CALL, T_ADDR)) == 0)
	    err ("t_alloc");

          if (options)
            {
	      SET_SO_OPTION (sochdr, SOL_SOCKET, options, 4, 1);
	      if (t_optmgmt (fd, so_options, so_options_ret) == -1)
		err ("t_optmgmt: debug");
            }

          if (t_listen (fd, call_ptr) == -1)
	    err ("t_listen");

	  if (t_accept (fd, fd, call_ptr) == -1)
	    err ("t_accept");

	  fprintf (stderr, "ttcp-r: t_accept from %s\n",
		   inet_ntoa (((struct sockaddr_in *) call_ptr->addr.buf)->sin_addr));
	}
    }

  (void) t_free ((char *) so_options, T_OPTMGMT);
  (void) t_free ((char *) so_options_ret, T_OPTMGMT);

  prep_timer ();
  errno = 0;
  if (sinkmode)
    {
      register int cnt;
      if (trans)
        {
          pattern (buf, buflen);
          if (udp)
            (void) Nwrite (fd, buf, 4); /* rcvr start */
          while (nbuf-- && Nwrite (fd, buf, buflen) == buflen)
            nbytes += buflen;
          if (udp)
            (void) Nwrite (fd, buf, 4); /* rcvr end */
        }
      else
        {
          if (udp)
            {
              while ((cnt = Nread (fd, buf, buflen)) > 0)
                {
                  static int going = 0;
                  if (cnt <= 4)
                    {
                      if (going)
                        break;  /* "EOF" */
                      going = 1;
                      prep_timer ();
                    }
                  else
		    nbytes += cnt;
                }
            }
          else
            {
              while ((cnt = Nread (fd, buf, buflen)) > 0)
		nbytes += cnt;
            }
        }
    }
  else
    {
      register int cnt;
      if (trans)
        {
          while ((cnt = read (0, buf, buflen)) > 0 &&
                 Nwrite (fd, buf, cnt) == cnt)
            nbytes += cnt;
        }
      else
        {
          while ((cnt = Nread (fd, buf, buflen)) > 0 &&
                 write (1, buf, cnt) == cnt)
            nbytes += cnt;
        }
    }
  if (errno)
    err ("IO");
  (void) read_timer (stats, sizeof (stats));
  if (udp && trans)
    {
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
    }
  if (cput <= 0.0)
    cput = 0.001;
  if (realt <= 0.0)
    realt = 0.001;
  fprintf (stdout,
           "ttcp%s: %ld bytes in %.2f real seconds = %s/sec +++\n",
           trans ? "-t" : "-r",
           nbytes, realt, outfmt (((double) nbytes) / realt));
  if (verbose)
    {
      fprintf (stdout,
               "ttcp%s: %ld bytes in %.2f CPU seconds = %s/cpu sec\n",
               trans ? "-t" : "-r",
               nbytes, cput, outfmt (((double) nbytes) / cput));
    }
  fprintf (stdout,
           "ttcp%s: %d I/O calls, msec/call = %.2f, calls/sec = %.2f\n",
           trans ? "-t" : "-r",
           numCalls,
           1024.0 * realt / ((double) numCalls),
           ((double) numCalls) / realt);
  fprintf (stdout, "ttcp%s: %s\n", trans ? "-t" : "-r", stats);
  if (verbose)
    {
      fprintf (stdout,
               "ttcp%s: buffer address %#x\n",
               trans ? "-t" : "-r",
               buf);
    }
  exit (0);

usage:
  fprintf (stderr, Usage);
  exit (1);
}

void
err (s)
     char *s;
{
  fprintf (stderr, "ttcp%s: ", trans ? "-t" : "-r");
  t_error (s);
  fprintf (stderr, "errno=%d, t_errno = %d\n", errno, t_errno);
  exit (1);
}

void
mes (s)
     char *s;
{
  fprintf (stderr, "ttcp%s: %s\n", trans ? "-t" : "-r", s);
}

pattern (cp, cnt)
     register char *cp;
     register int cnt;
{
  register char c;
  c = 0;
  while (cnt-- > 0)
    {
      while (!isprint ((c & 0x7F)))
        c++;
      *cp++ = (c++ & 0x7F);
    }
}

char *
outfmt (b)
     double b;
{
  static char obuf[50];
  switch (fmt)
    {
    case 'G':
      sprintf (obuf, "%.2f GB", b / 1024.0 / 1024.0 / 1024.0);
      break;
    default:
    case 'K':
      sprintf (obuf, "%.2f KB", b / 1024.0);
      break;
    case 'M':
      sprintf (obuf, "%.2f MB", b / 1024.0 / 1024.0);
      break;
    case 'g':
      sprintf (obuf, "%.2f Gbit", b * 8.0 / 1024.0 / 1024.0 / 1024.0);
      break;
    case 'k':
      sprintf (obuf, "%.2f Kbit", b * 8.0 / 1024.0);
      break;
    case 'm':
      sprintf (obuf, "%.2f Mbit", b * 8.0 / 1024.0 / 1024.0);
      break;
    }
 return obuf;
}

static struct timeval time0;    /* Time at which timing started */
static struct rusage ru0;       /* Resource utilization at the start */

static void prusage ();
static void tvadd ();
static void tvsub ();
static void psecs ();

#if defined(SYSV)
/*ARGSUSED*/
static
getrusage (ignored, ru)
     int ignored;
     register struct rusage *ru;
{
  struct tms buf;

  times (&buf);

  /* Assumption: HZ <= 2147 (LONG_MAX/1000000) */
  ru->ru_stime.tv_sec = buf.tms_stime / HZ;
  ru->ru_stime.tv_usec = ((buf.tms_stime % HZ) * 1000000) / HZ;
  ru->ru_utime.tv_sec = buf.tms_utime / HZ;
  ru->ru_utime.tv_usec = ((buf.tms_utime % HZ) * 1000000) / HZ;
}

/*ARGSUSED*/
static
gettimeofday (tp, zp)
     struct timeval *tp;
     struct timezone *zp;
{
  tp->tv_sec = time (0);
  tp->tv_usec = 0;
}

#endif /* SYSV */

/*
 *                      P R E P _ T I M E R
 */
void
prep_timer ()
{
  gettimeofday (&time0, (struct timezone *) 0);
  getrusage (RUSAGE_SELF, &ru0);
}

/*
 *                      R E A D _ T I M E R
 *
 */
double
read_timer (str, len)
     char *str;
{
  struct timeval timedol;
  struct rusage ru1;
  struct timeval td;
  struct timeval tend, tstart;
  char line[132];

  getrusage (RUSAGE_SELF, &ru1);
  gettimeofday (&timedol, (struct timezone *) 0);
  prusage (&ru0, &ru1, &timedol, &time0, line);
  (void) strncpy (str, line, len);

  /* Get real time */
  tvsub (&td, &timedol, &time0);
  realt = td.tv_sec + ((double) td.tv_usec) / 1000000;

  /* Get CPU time (user+sys) */
  tvadd (&tend, &ru1.ru_utime, &ru1.ru_stime);
  tvadd (&tstart, &ru0.ru_utime, &ru0.ru_stime);
  tvsub (&td, &tend, &tstart);
  cput = td.tv_sec + ((double) td.tv_usec) / 1000000;
  if (cput < 0.00001)
    cput = 0.00001;
  return (cput);
}

static void
prusage (r0, r1, e, b, outp)
     register struct rusage *r0, *r1;
     struct timeval *e, *b;
     char *outp;
{
  struct timeval tdiff;
  register time_t t;
  register char *cp;
  register int i;
  int ms;

  t = (r1->ru_utime.tv_sec - r0->ru_utime.tv_sec) * 100 +
    (r1->ru_utime.tv_usec - r0->ru_utime.tv_usec) / 10000 +
    (r1->ru_stime.tv_sec - r0->ru_stime.tv_sec) * 100 +
    (r1->ru_stime.tv_usec - r0->ru_stime.tv_usec) / 10000;
  ms = (e->tv_sec - b->tv_sec) * 100 + (e->tv_usec - b->tv_usec) / 10000;

#define END(x)  {while(*x) x++;}
#if defined(SYSV)
  cp = "%Uuser %Ssys %Ereal %P";
#else
#if defined(sgi)                /* IRIX 3.3 will show 0 for %M,%F,%R,%C */
  cp = "%Uuser %Ssys %Ereal %P %Mmaxrss %F+%Rpf %Ccsw";
#else
  cp = "%Uuser %Ssys %Ereal %P %Xi+%Dd %Mmaxrss %F+%Rpf %Ccsw";
#endif
#endif
  for (; *cp; cp++)
    {
      if (*cp != '%')
        *outp++ = *cp;
      else if (cp[1])
        switch (*++cp)
          {

          case 'U':
            tvsub (&tdiff, &r1->ru_utime, &r0->ru_utime);
            sprintf (outp, "%d.%01d", tdiff.tv_sec, tdiff.tv_usec / 100000);
            END (outp);
            break;

          case 'S':
            tvsub (&tdiff, &r1->ru_stime, &r0->ru_stime);
            sprintf (outp, "%d.%01d", tdiff.tv_sec, tdiff.tv_usec / 100000);
            END (outp);
            break;

          case 'E':
            psecs (ms / 100, outp);
            END (outp);
            break;

          case 'P':
            sprintf (outp, "%d%%", (int) (t * 100 / ((ms ? ms : 1))));
            END (outp);
            break;

#if !defined(SYSV)
          case 'W':
            i = r1->ru_nswap - r0->ru_nswap;
            sprintf (outp, "%d", i);
            END (outp);
            break;

          case 'X':
            sprintf (outp, "%d", t == 0 ? 0 : (r1->ru_ixrss - r0->ru_ixrss) / t);
            END (outp);
            break;

          case 'D':
            sprintf (outp, "%d", t == 0 ? 0 :
                     (r1->ru_idrss + r1->ru_isrss - (r0->ru_idrss + r0->ru_isrss)) / t);
            END (outp);
            break;

          case 'K':
            sprintf (outp, "%d", t == 0 ? 0 :
                     ((r1->ru_ixrss + r1->ru_isrss + r1->ru_idrss) -
                      (r0->ru_ixrss + r0->ru_idrss + r0->ru_isrss)) / t);
            END (outp);
            break;

          case 'M':
            sprintf (outp, "%d", r1->ru_maxrss / 2);
            END (outp);
            break;

          case 'F':
            sprintf (outp, "%d", r1->ru_majflt - r0->ru_majflt);
            END (outp);
            break;

          case 'R':
            sprintf (outp, "%d", r1->ru_minflt - r0->ru_minflt);
            END (outp);
            break;

          case 'I':
            sprintf (outp, "%d", r1->ru_inblock - r0->ru_inblock);
            END (outp);
            break;

          case 'O':
            sprintf (outp, "%d", r1->ru_oublock - r0->ru_oublock);
            END (outp);
            break;
          case 'C':
            sprintf (outp, "%d+%d", r1->ru_nvcsw - r0->ru_nvcsw,
                     r1->ru_nivcsw - r0->ru_nivcsw);
            END (outp);
            break;
#endif /* !SYSV */
          }
    }
 *outp = '\0';
}

static void
tvadd (tsum, t0, t1)
     struct timeval *tsum, *t0, *t1;
{

  tsum->tv_sec = t0->tv_sec + t1->tv_sec;
  tsum->tv_usec = t0->tv_usec + t1->tv_usec;
  if (tsum->tv_usec > 1000000)
    tsum->tv_sec++, tsum->tv_usec -= 1000000;
}

static void
tvsub (tdiff, t1, t0)
     struct timeval *tdiff, *t1, *t0;
{

  tdiff->tv_sec = t1->tv_sec - t0->tv_sec;
  tdiff->tv_usec = t1->tv_usec - t0->tv_usec;
  if (tdiff->tv_usec < 0)
    tdiff->tv_sec--, tdiff->tv_usec += 1000000;
}

static void
psecs (l, cp)
     long l;
     register char *cp;
{
  register int i;

  i = l / 3600;
  if (i)
    {
      sprintf (cp, "%d:", i);
      END (cp);
      i = l % 3600;
      sprintf (cp, "%d%d", (i / 60) / 10, (i / 60) % 10);
      END (cp);
    }
  else
    {
      i = l;
      sprintf (cp, "%d", i / 60);
      END (cp);
    }
  i %= 60;
  *cp++ = ':';
  sprintf (cp, "%d%d", i / 10, i % 10);
}

/*
 *                      N R E A D
 */
Nread (fd, buf, count)
     int fd;
     void *buf;
     int count;
{
  register int cnt;
  int flags = 0;

  if (udp)
    {
      struct sockaddr_in from;
      struct t_unitdata udata;

      udata.addr.maxlen  = sizeof from;
      udata.addr.buf     = (char *) &from;
      udata.udata.maxlen = count;
      udata.udata.buf    = (char *) buf;

      cnt = t_rcvudata (fd, &udata, &flags);
      if (cnt != -1)
	cnt = udata.udata.len;
      numCalls++;
    }
  else
    {
      if (b_flag)
        cnt = mread (fd, buf, count);   /* fill buf */
      else
        {
          cnt = t_rcv (fd, buf, count, &flags);
          numCalls++;
        }
      if (touchdata && cnt > 0)
        {
          register int c = cnt, sum;
          register char *b = buf;
          while (c--)
            sum += *b++;
        }
    }
 return (cnt);
}

/*
 *                      N W R I T E
 */
Nwrite (fd, buf, count)
     int fd;
     void *buf;
     int count;
{
  register int cnt;
  if (udp)
    {
      struct t_unitdata udata;

      memset (&udata, 0, sizeof udata);
      udata.addr.len     = sizeof sinhim;
      udata.addr.buf     = (char *) &sinhim;
      udata.udata.len    = count;
      udata.udata.buf    = (char *) buf;

    again:
      cnt = t_sndudata (fd, &udata);
      numCalls++;
      if (cnt == -1)
        {
	  if (errno == ENOBUFS)
	    {
	      delay (18000);
	      errno = 0;
	      goto again;
	    }
	  else
	    err ("t_sndudata");
	}
      else
	cnt = udata.udata.len;
    }
  else
    {
      cnt = t_snd (fd, buf, count, 0);
      numCalls++;
    }
 return (cnt);
}

void
delay (us)
{
  struct timeval tv;

  tv.tv_sec = 0;
  tv.tv_usec = us;
  (void) select (1, (fd_set *) 0, (fd_set *) 0, (fd_set *) 0, &tv);
}

/*
 *                      M R E A D
 *
 * This function performs the function of a read(II) but will
 * call read(II) multiple times in order to get the requested
 * number of characters.  This can be necessary because
 * network connections don't deliver data with the same
 * grouping as it is written with.  Written by Robert S. Miles, BRL.
 */
int
mread (fd, bufp, n)
     int fd;
     register char *bufp;
     unsigned n;
{
  register unsigned count = 0;
  register int nread;
  int flags = 0;

  do
    {
      nread = t_rcv (fd, bufp, n - count, &flags);
      numCalls++;
      if (nread < 0)
        {
          perror ("ttcp_mread");
          return (-1);
        }
      if (nread == 0)
        return ((int) count);
      count += (unsigned) nread;
      bufp += nread;
  } while (count < n);

  return ((int) count);
}
--
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Aug 1993 22:04:08 GMT
From:      mdd@stiatl.salestech.com (Miles Duke)
To:        comp.protocols.tcp-ip
Subject:   Question: How do you properly free up a server socket?

I have a socket server application that creates a socket, binds it to
a well-known port, and then goes into a loop listening and accepting
new sessions.  A child process is spawned for each session, but the
child remains as a duplicate of the parent (no exec is performed).

From time to time, it is necessary to shut down this server, and I do
so using a signal.  The signal trapper sets a flag and interrupts the
accept() call that the server was blocking upon.  The server performs
a close() system call on the socket that it was accepting sessions
from and exits.

The problem is that sometimes the well-known port stays busy, even
though the server and all of its children are no longer active.  New
instances of the server are unable to start up, because the bind()
call fails (errno I think is EADDRINUSE), and this condition remains
for 1 to 10 minutes after the previous server shut down.

What does the server need to do to free up this socket.  Is close()
not enough?  Any child processes created close their copy of the
socket, so none of them should be hanging on to it.  This is running
on an IBM RS/6000 520, using AIX 3.2.1.  I don't think the source
modules were compiled with -D_BSD, but this does not appear to be a
problem.  The program works otherwise, and many times it will shut
down and free up its resources normally.

-- 
Miles Duke                        ...!uupsi!stiatl!mdd
UNIX and Amiga Geek at Large      mdd@SalesTech.COM

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Aug 1993 23:58:37 GMT
From:      sr@acsu.buffalo.edu (Sudhakar Rajamannar)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   KA9Q on 386/486

Hi!!!

I would like to know if there are any options for running KA9Q for 
386/486 to use the extended memory.

I am using the version of KA9Q available at ucsd.edu (May'93 version) 
and using borland C++ version 3. (or is there an option in borland C++
to use the extended memory)

Thanks in advance.

Sudhakar

-- 
-------------------------------------------------------------------------------
     Sudhakar Rajamannar      sr@acsu.buffalo.edu       
     Electrical & Computer Engineering
                           Department 

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 93 01:12:06 GMT
From:      nam@peregrine.esl.com (Nam Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Telnet problem

I am attempting to telnet from my Sun workstartion at work to a
Univax system running Ultrix in school and only once in a thousand
times when I am successfully logging in.

The other times, I get the following sequence of output:


-----------------------------------------
Trying xxx.xx.xx.xx ...
Connected to yyyyy.
Escape character is '^]'.
Connection closed by foreign host.
-----------------------------------------

where

	xxx.xx.xx.xx is the IP address of the destination host
	yyyy	     is its hostname.


My workstation is running SunOS4.1.3, and this seemed to occur mostly
when the school's system is busy (where there are many students using
the system).  Early in the morning or late at night, this problem
still occurs, but my chance of logging in is greater (1 in 40 times!)

Please advise me of where I can do to ensure successful logging.
(I do have the source for BSD telnet).

Thanks,

Nam N.




-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 03:35:34 GMT
From:      vandusen@NeoSoft.com (Mike Vandusen)
To:        comp.protocols.tcp-ip,misc.books.technical,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought

In article <1993Aug6.173735.17937@mccaw.com> peterg@eng.krldwa.mccaw.com writes:
>I need recommendations for one or more books on TCP/IP LANs and WANs.
>
>I'll soon be in a consulting capacity and "stretching the envelope" with regards
>to my knowledge of large TCP/IP networks.  My client has thousands of nodes on
>a nationwide router-based network, and I need to quickly come up to speed on the
>issues facing large networks.
>
>I know all the basics of TCP/IP, understand the protocol and have done network
>client/server programming with ICMP, UDP and TCP on UNIX and non-UNIX systems.
>So I don't need a "basics of TCP/IP" book, but more advanced stuff.
>
>Concepts I need to master are: netmasks, subnetting, routers, SNMP, gateways,
>DNS and other WAN issues.
>
>Thanks!
>
>---
>
>Pete Gregory   peterg@eng.krldwa.mccaw.com  |  "It may be rice wine to you,
>Senior Consultant. ASIX, Inc., Seattle, WA  |  but it's sake to me."
>on-site at McCaw Cellular Communications, Kirkland, WA
>

You might try finding:

"Troubleshooting TCP/IP" by Mark A. Miller
Publisher: M&T Books   ISBN: 1-55851-268-3

The book covers LANS, MANS, and WANS, with good coverage of heterogeneous
nets.  It also covers troubleshooting at the various stack levels starting
at the hardware level and going up to the process/application level.

Good luck with your new position!
Mike VanDusen

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 13:09:27 -0500
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

pcg@aber.ac.uk (Piercarlo Grandi) writes:
> Are you sure that you *can* do a single threaded implementation of TCP/
> IP? Think carefully about it... :-) 

Sure you can.  Think state machines.  You just have to structure your API so 
that nothing blocks.  Of course, this is isomorphic to threading at some 
level, but it does not require a multitasking kernel or OS.  THe TCP/IP stack 
from NCSA Telnet for the Mac & PC is a pretty complete example (the only 
thing it doesn't do that I know of is IP fragment reassembly).


Amanda Walker
InterCon Systems Corporation



-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 93 14:18:11 PDT
From:      allen@nwnet.net
To:        misc.books.technical,comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought


In article <1993Aug6.173735.17937@mccaw.com>, <peterg@eng.krldwa.mccaw.com> 
writes:
> I need recommendations for one or more books on TCP/IP LANs and WANs.
> 

Along with all the other good suggestions that have been mentioned,
you might look at the new book by Daniel Lynch and Marshall Rose
(both editors) entitled "Internet System Handbook." Addison
Wesley, ISBN 0-201-56741-5.

Great chapters by those that have been around the Internet for 
years including Radia Perlman (Routing Protocols), Scott Bradner
(A proctical Perspective on Routers), Stephen Kent (Architectural
Security), Vint Cerf (Core Protocols).  Other contributers include
Hans-Werner Braun, Jeffrey Case, Stephen Crocker, Jon Postel and 
several others.  Well worth the bucks IMHO.

Allen Robel
Senior Network Engineer
NorthWestNet
allen@nwnet.net

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 13:26:17
From:      jobrien@mcs.umes.umd.edu (James M. O'Brien, Jr)
To:        comp.protocols.tcp-ip
Subject:   Need help getting slip up and going

I am trying to get slip up and running and need some help.  I have the slip 
driver from csn-slip-4.1.1 and have rebuilt the kernel on a ss1+, sunos 4.1.2.

I've used slattach /dev/ttya 2400 131.118.127.x 131.118.127.xx 255.255.0.0
which seemed to complete fine, or at least returned no errors.  

I have slipper v1.3 from peter tatum.   I dialed into the sun using pcplus,
exited pcplus kept the line up, started slipper and tried to run archie.
data gets tx'd and rx'd a couple of times then the link gets dropped.

I get no error msgs of any kind.....

If you can any hints pointers to 'Implementing slip' documents, etc... it would
be appreciated.

Thanks!


Jim O'Brien, CNE                University of Maryland Eastern Shore
jobrien@mcs.umes.umd.edu        Network Manager

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1993 18:44:14 -0500
From:      bataller@afya.acs.uwosh.edu (Erik M. Bataller)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: cslip-2.6:  sliplogin[223]: I_PUSH: Not ow


Hello All,

I keep getting this messsage from cslip when I login:

	Aug 11 18:29:03 afya sliplogin[14606]: I_PUSH: Not owner

Any ideas about what it means?

Thanks

Erik


-- 
!!  Erik M. Bataller | Phone: (414) 424-0347 | Univ. of Wi., Oshkosh 
!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
!!  Oshkosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
!!  Bitnet: Bataller@oshkoshw.bitnet




-- 
!!  Erik M. Bataller | Phone: (414) 424-0347 | Univ. of Wi., Oshkosh 
!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
!!  Oshkosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
!!  Bitnet: Bataller@oshkoshw.bitnet

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 13:53:50 GMT
From:      rbasket@richfree.vcu.edu (Robert E. Baskette)
To:        comp.protocols.tcp-ip
Subject:   Info needed on Centrum Communictions CentrumRemote


  We are looking to implement a remote access server that can support
tcp/ip, ipx, arap.  Has anyone used a Centrum Communications
CentrumRemote box for remote dial-up access?  If so any opinions and
other info would be desired.

Bob Baskette
Computer Systems Engineer
Virginia Commonwealth University

rbasket@cabell.vcu.edu


-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 14:51:06 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

>>> On 7 Aug 93 11:00:26, peter@future.midnight.com (Peter H. Schmidt) said:

(someone)> a) Is there somewhere a PD / shareware TCP/IP stuff writen in
(someone)> C, which does NOT require multitasking (because our kernel
(someone)> has no multitasking feature) ??

Are you sure that you *can* do a single threaded implementation of
TCP/IP? Think carefully about it... :-)

Peter> Hmm, Phil Karn's (et al.) KA9Q is a very solid, single-threaded
Peter> implementation of TCP/IP.

KA9Q is totally multithreaded. It boots under MSDOS, and it is a
complete (but for file services, for which it uses the BIOS)
multihreading memory resident realtime operating system in its own
right, with variable numbers of processes, and so on.


Perhaps you could simply add X windows service to KA9Q. KA9Q is
copyrighted by Phil Karn and others, and is available for free to
educational insitutions and packet radio users.

You could otherwise look WATTCP, the waterloo implementation of TCP/IP
for PCs. Just like KA9Q it is fully multithreaded, even if it runs under
MSDOS.

Perhaps you should have a look at the various MSDOS TCP/IP freeware
stacks.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1993 14:53:59 GMT
From:      pjoslin@mbvlab.wpafb.af.mil (Paul Joslin (Sverdrup))
To:        comp.protocols.tcp-ip,misc.books.technical,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought

In article <1993Aug6.173735.17937@mccaw.com>, Peter Gregory (peterg@eng.krldwa.mccaw.com) wrote:

: I need recommendations for one or more books on TCP/IP LANs and
: WANs.
 
: I'll soon be in a consulting capacity and "stretching the envelope"
: with regards to my knowledge of large TCP/IP networks.  My client
: has thousands of nodes on a nationwide router-based network, and I
: need to quickly come up to speed on the issues facing large
: networks.
 
: I know all the basics of TCP/IP, understand the protocol and have
: done network client/server programming with ICMP, UDP and TCP on
: UNIX and non-UNIX systems.  So I don't need a "basics of TCP/IP"
: book, but more advanced stuff.
 
: Concepts I need to master are: netmasks, subnetting, routers, SNMP,
: gateways, DNS and other WAN issues.

I strongly recommend two O'Rielly books:
DNS and Bind, by Paul Ablitz and Cricket Liu
TCP/IP Network Administration (My copy is at home - I don't recall the
author). 

Most large bookstores carry O'Rielly, or you can email to ora.com.  If
you can't reach them, email me, and I find a phone number.
--

Paul R. Joslin +1 513 255 1115

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 16:06:02 GMT
From:      gahan@chinet.chinet.com (Paul R. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Mainframe TCP/IP Questions

Please respond to the address listed below!

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

We are putting MVS/TCP-IP on our Mainframe, but doesn't have in installed
yet.  We would like to know the following from anyone who has experience
with these (they are critical to some planning we are doing now):

        How different / difficult are RPC programs on the Mainframe?

        How can a Mainframe RPC server access IMS?

        What language do you use (C would seem the obvious choice and
		we do have C370)?

        Do you (can you) use C for RPC, but access IMS through Cobol?  How
        is this done?

Thanks!!!
Paul R. Schmidt
gahan@chinet.chi.il.us

Please send your responses to:

        hi@obs.com

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 93 18:49:46 GMT
From:      dcrocker@udel.asd.sgi.com (Dave Crocker)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: PORTING FROM SOCKET TO TLI


The semantic differences between sockets and TLI can bite one
at unexpected times.  They block differently, for example, making
it necessary for one to spawn a subprocess when the other doesn't
need to.  TLI has the concept of expedited/out-of-band data.  Sockets
(for TCP) does not.  

d/

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 93 19:12:41 GMT
From:      jans@optigfx.optigfx.com (Kert Jans)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Momentum Inc. rpc


Hi,

Has anyone heard of a company called: Momentum
that makes a client/server toolkit called: X-IPC

Any pointers to an address / phone number are appreciated.

Thanks

Kert Jans
Optigraphics Corporation
9339 Carroll Park Drive
San Diego, CA 92121
(619)-625-3000
FAX: (619)-558-1843
jans@optigfx.com



-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1993 21:41:11 GMT
From:      tburns@magnus.acs.ohio-state.edu (Timothy A N Burns)
To:        comp.protocols.tcp-ip
Subject:   Trying to get Telnet  up, need help.

 I am trying to run NCSA Telnet programs on a Zenith Znote 425 Lnc.  I shut off
the autoexec loading of Netware, and am using 3c503.com 0x60 0x3 to start what 
I thought was a packet driver.

When I start telnet I get EMM386 error DMA buffer too small add D=64 and reboot
message.

HELP!
tim+@osu.edu

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1993 21:48:25 GMT
From:      jazz@hal.com (Jason Zions)
To:        comp.protocols.tcp-ip,misc.books.technical,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought

In article <24b167$mhi@iris.mbvlab.wpafb.af.mil> pjoslin@mbvlab.wpafb.af.mil (Paul Joslin (Sverdrup)) writes:

   I strongly recommend two O'Rielly books:
   DNS and Bind, by Paul Ablitz and Cricket Liu
                         ^^^^^^
Paul Albitz. A nice guy, he is, and undeserving of a typo'd last name. The
book is quite good, as well; a very useful tool to have in hand when trying
to run any size domain.

Besides, Paul would never stopp so low as to correct the spelling of his own
name on the net; spelling flames (even the no-flame variety) are beneath his
dignity. Or so he said, last time we fought about it, after we wiped the mud
off and shooed the pigs out of my living room. :-)

Jason "who, me?" Zions

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 1993 22:57:39 GMT
From:      cricket@babs.nsr.hp.com (Cricket Liu)
To:        comp.protocols.tcp-ip,misc.books.technical,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought

Hey, Jazz.

In article <JAZZ.93Aug11154825@jazz.hal.com>, jazz@hal.com (Jason Zions) writes:
|> In article <24b167$mhi@iris.mbvlab.wpafb.af.mil> pjoslin@mbvlab.wpafb.af.mil (Paul Joslin (Sverdrup)) writes:
|> 
|>    I strongly recommend two O'Rielly books:
|>    DNS and Bind, by Paul Ablitz and Cricket Liu
|>                          ^^^^^^
|> Paul Albitz. A nice guy, he is, and undeserving of a typo'd last name. The
|> book is quite good, as well; a very useful tool to have in hand when trying
|> to run any size domain.
|> 
|> Besides, Paul would never stopp so low as to correct the spelling of his own
|> name on the net; spelling flames (even the no-flame variety) are beneath his
|> dignity. Or so he said, last time we fought about it, after we wiped the mud
|> off and shooed the pigs out of my living room. :-)

And my last name is the one everybody *usually* spells wrong!

To actually add something (albeit small) to this string, _TCP/IP Network
Administration_'s author is Craig Hunt, and it's ISBN is 0-937175-82-X (can
that be right?).  _DNS and BIND_ is ISBN 1-56592-010-4.

-- 
cricket

cricket@hp.com / Hewlett-Packard Professional Services / Englewood, CO

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1993 23:29:58 GMT
From:      dadler@u.washington.edu (David A. Adler)
To:        comp.protocols.tcp-ip
Subject:   tracing an IP#??

Hi,
This group was suggested to me for my question - I hope this is  
appropriate. I administer a gopher hole. I have noticed in the log of  
accesses a strange IP# that seems to be downloading the same directory  
multiple times a day for the last 2 weeks. I am curious and somewhat  
concerned about this so I tried identifying machine BUT finger @IP#,  
whois, traceroute, nslookup all fail to find any info - results like  
unknown host, etc. Does any one have any further suggestions to trace this  
IP#? Appreciate any email suggestions.
Thanks,
David
--
David A. Adler                  Pathology SM-30
University of Washington        Seattle, WA 98195
(206) 543-0716 (phone)		(206) 543-3644 (fax)
"Science is nothing but trained and organized common sense"
T.H.Huxley

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Aug 93 23:41:33 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Racal INterlan: drivers for ni5210???

In article <248l1u$hjs@afya.acs.uwosh.edu> bataller@afya.acs.uwosh.edu writes:

           Does anyone know where the latest and greatest drivers for 
   Racal Interland NI5210 card are?  I am interested in both packet
   drivers and ODI drivers.

For packet drivers, Use The Source, Luke:


-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem.  The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add $35
check-cashing fee.

  1. Binaries and documentation:        $35  /  $40
  2. Source code:                       $60  /  $68

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>.  The drivers are there, along
with many free programs that use the packet drivers.

SIMTEL20 files are also available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6),
nctuccca.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file
servers.

Modem:

If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.

CD-ROM:

Public, private or corporate institutions and libraries interested in
the SIMTEL20 MS-DOS collection in CD-ROM format bundled with library
card-catalog type access and duplication software can contact Coyote
Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307 or by FAX at
(313) 651-4071.  Others who do not need the access and duplication
software should send e-mail to: rab@cdrom.com (Robert Bruce), telephone
(800) 786-9907 or (510) 947-5996, or FAX (510) 947-1644 for details on
his CD-ROM offer.


UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "marvin"

-- end of HOWTOGET.IT

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

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 00:07:00 GMT
From:      karl@empirical.com  (Karl Auerbach)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets?

With respect to giant packets...
-
There are lots of potential causes.
-
Some boxes intentionally sent giant, over-legal-size Ethernet/802.3
frames.  These include old Plexus machines.
-
Other boxes do it by mistake.
-
Most of the time, however, it is due to a cable plant problem.
-
If you are using FOIRL (Ethernet on fiber optics), make sure that you
have consistent power level settings at the MAUs at either end.
-
Make sure your terminations are good on coax cables.
-
If you have a good quality 10-Base-T hub with management (for example
a Synoptics or Cabletron) you can probably get the port number from which
frames are originating.
-
				--karl--

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 01:14:28 GMT
From:      amolitor@moink.NMSU.edu (Andrew)
To:        comp.protocols.tcp-ip
Subject:   Start up a FAQ?


	Here's a plan, I'll start a FAQ sheet if you'll send me in frequently
asked questions equipped with answers. Go peek at the rec.photo FAQ sheet
(FTP to rtfm.mmit.edu etc etc) if you want to see if I'm worthy. 

	The first question is:

Why is bind(2) return EADDRINUSE when I try to restart my server?

	Well, TCP leaves connections in TIME-WAIT state for a few minutes
	(4, according to RFC 793, but implementations probably vary) to
	ensure that leftover data for an old connection will have time
	to arrive and be discarded, before allowing a new TCP connection
	to be established on that socket. In order to get around this,
	you should do a setsockopt() with socket option SO_REUSEADDR when
	*starting* a new server connection. This will override the fact
	that the port is in a TIME-WAIT state, and allow you to bind.
	Note that this is a violation of the standard, and it may be a
	bad idea for critical applications, though it is very rare that
	bad things will happen.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 11:06:29 CDT
From:      zjnn04@hou.amoco.com (Jonathan Nguyen)
To:        comp.protocols.tcp-ip,amoco.tcpip.questions,comp.client-server,amoco.tcpip.coi
Subject:   Help to get rid of zombies

Hello,

I am writing a client-server application using TCP/IP socket protocol.
The server 'fork'(s) a child to handle each client request. I ended up
with a bunch of 'zombies' in the system. 

I then tried the 'skeleton daemon' as illustrated in Richard Stevens' 
Unix Network Programming book (p 82-85 daemon_start()). The server
(parent process) died after the first successful connection to the
client. The accept() system call failed with 'errno' = 4 (Interrupted
system call).  Below is the summary of what the server does:

main()
{
    ...
    daemon_start(1);
    if ((skt = socket(AF_INET,SOCK_STREAM,0)) < 0)
	error_exit("socket failed");
    ....
    if (bind(skt,(struct sockaddr *)&serv_addr,sizeof(serv_addr)) < 0)
	error_exit("bind failed");
    listen(skt, 5);
    for ( ; ; ) {
        newskt = accept(skt,(struct sockaddr *)&cli_addr,&clilen);
        if (newskt < 0) {
            printf("accept failed, errno=%d\n",errno);
	    error_exit("accept failed");
        }
        if ((childpid = fork()) < 0)
	    error_exit("fork failed");

        if (childpid == 0) {        /* Child process */
            close(skt);
            unix_netsfd(newskt);
            exit(0);
        }
        /* Parent process */
        close(newskt);
    }
 ....
}

I need help to resolve the error from the second 'accept()' system
call.

Thanks,

   Jonathan Nguyen
   Amoco Corp.
   zjnn04@hou.amoco.com



-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 93 06:10:50 GMT
From:      ccdw@kudu.ru.ac.za (Dave Wilson)
To:        comp.protocols.tcp-ip
Subject:   discard tcp packets?

I've been using etherfind to monitor network load over the last few
weeks, and have noticed large numbers of TCP 'discard' packets.  These
are always from machine A to B, source port 4648 (I don't know if that
is always the case), destination port 9 (discard).  The packets are
usually 1514 bytes.  I've had a look at some of them with tcpview, but
cannot make any sense of the packet contents.

Machine A is an IPC running SUNOS 4.1.1.  It serves as our NIS master,
primary nameserver, nntp server, etc.   Machine B is an ELC also running
SUNOS 4.1.1.

I'd like to know what the function of these packets is, and also why
there appear to be so many of them.

Thanks for any help.

--
Dave Wilson
Computing Centre, Rhodes University
Grahamstown, South Africa

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 18:25:26 -0700
From:      earle@isolar.Tujunga.CA.US (Greg Earle)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   Proper response code to FTP's "CWD" command?

I just noticed something interesting while trying to use "xarchie" 2.0.8.
Most FTP servers will respond to a (valid) "CWD" request with an answer like
"250 CWD command successful.".

I have found a few servers (like lynx.CS.ORST.EDU, for example) that respond
"200 CWD command okay.".

This causes xarchie 2.0.8 to barf (and abort the FTP) with an error popup:
	_____________________
	| FTP Error 200:    |
	|  CWD command okay.|
	| +--+              |
	| |Ok|              |
	| +--+              |
	|___________________|

I don't have the RFC for FTP handy; is "200 CWD command okay." a legal return
value here, or is the (nominal) 250 the correct value?  Is the FTP server in
the wrong, or is "xarchie" wrong for rejecting it?

(I note that this server is on a machine running an ancient version of HP-UX,
 and the newer HP-UX 9.01 server returns "250 CWD command successful.")

-- 
	- Greg Earle
	  Phone: (818) 353-8695		FAX: (818) 353-1877 [Out of order now]
	  Internet: earle@isolar.Tujunga.CA.US
	  UUCP: isolar!earle@elroy.JPL.NASA.GOV a.k.a. ...!elroy!isolar!earle

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 17:16:04 -0500
From:      tumlin@cs.utexas.edu (Evelyn Tumlin)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   TCP-IP problem was cable-related

Thanks to all who responded to my problem with the two AT&T's
which wouldn't talk to each other.  PARTICULARLY to the one
(whoever you are -- I lost your address) who suggested that
it might be a standing wave problem.  I'm still not sure what
that is (yes, I admit it; I'm a software type!) but our hardware
guru checked it out and verified that that was the problem.

Thanks again!

-- Lyn Tumlin (tumlin@cs.utexas.edu)

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 14:45:12 CDT
From:      zjnn04@hou.amoco.com (Jonathan Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: Help to get rid of zombies

I just found the way to get around the interruption to accept() call
due to the signal SIGCHLD generated by an exiting child process. My
sig_child() routine will set on a global flag named 'sigcldset'
If the accept() call fails and if the flag is set, I ignore the
error and reset the flag to zero. Then I restart the accept() call.

It worked just fine.  Do you see any potential error in doing so ?
Here is part of my code:

int sigcldset = 0;          /* <<=== global flag */
main()
{
    ...
    daemon_start(1);
    if ((skt = socket(AF_INET,SOCK_STREAM,0)) < 0)
	error_exit("socket failed");
    ....
    if (bind(skt,(struct sockaddr *)&serv_addr,sizeof(serv_addr)) < 0)
	error_exit("bind failed");
    listen(skt, 5);
    for ( ; ; ) {
        newskt = accept(skt,(struct sockaddr *)&cli_addr,&clilen);
        if (newskt < 0) {
	    if (sigcldset) {          /* <<========= */
	 	sigcldset = 0;
		continue;             /* <<========= */
	    }                    
            printf("accept failed, errno=%d\n",errno);
	    error_exit("accept failed");
        }
        if ((childpid = fork()) < 0)
	    error_exit("fork failed");

        if (childpid == 0) {        /* Child process */
            close(skt);
            unix_netsfd(newskt);
            exit(0);
        }
        /* Parent process */
        close(newskt);
    }
 ....
}
sig_child()                         /* <<========== */
{
    int pid;
    union wait status;
    
    sigcldset = 1; /* set global var. to ignore accept() interruption */
    while ((pid=wait3(&status,WNOHANG,(struct rusage *) 0)) > 0)
	;
}                                 

Thanks,
Jonathan Nguyen



-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 93 15:43:11
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Use of SIGPIPE

What's the proper way to write code such that a client will receive a
SIGPIPE as soon as possible on a server disconnect?  With what I've
tried so far, after the server goes away, I still can do a write and I
wind up having to do one more read from the socket after that before I
get the SIGPIPE on the next write attempt.  Surely there's a way to set
things up such that I will get the SIGPIPE when I want it.

Can anyone offer some discussion on the matter?  The reading material
I've found out there treats this particular subject pretty sparsely.

Regards,

Rick

===========================================================================
Rick McCarty                                         Texas Instruments Inc.
mccarty@add.itg.ti.com                               Austin, Texas
===========================================================================

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 93 12:13:55 GMT
From:      Rainer.Blaes@erno.de
To:        comp.protocols.tcp-ip
Subject:   nslookup error message



Dear reader,

I've just gotten running DNS under NIS on a Sun NIS master (SunOS 4.1.2) by

a) an entry in the /etc/resolv.conf:

   domain	erno.de
   nameserver   149.243.250.1

b) and the B=-b parameter in the /var/yp/Makefile

Our nameserver ( 149.243.250.1) is an IBM3090 under MVS with TCP/IP
software.

I can ping, telnet, ftp etc. from my Sun to all hosts in the 'erno.de' 
domain especially to the IBM nameserver.

BUT, if I'm calling on the Sun the 'nslookup' command the following message 
appears:

*** Can't find server name for address 149.243.250.1: Format error
*** Can't find initialize address for server: Timed out
Default server: localhost
Segmentation fault (core dumped)

What's wrong?

Many thanks in advance!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Dr. Rainer Blaes                   | Rainer.Blaes@erno.de                |
| Senior System Manager              |                                     |
| ERNO Raumfahrttechnik GmbH         | "In any organization there          |
| Huenefeldstrasse 1-5               | will always be one person           |
| 28199 Bremen 1 Germany             | who knows what is going             |
| Voice: +49/(0)421 539-4132         | on. This person must be             |
| Fax:   +49/(0)421 539-4424         | fired."                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 12:49:14 GMT
From:      miguel@gris.informatik.uni-tuebingen.de (Miguel Encarnacao)
To:        comp.protocols.tcp-ip
Subject:   TLI via FTP ?

Is TLI available via FTP somewhere? If so, where? I need it for SGI-Machines.

Thanks, Miguel.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Miguel Encarnacao                     | Universitaet Tuebingen, WSI/GRIS  |
| Office: [+49/0] (7071) 29-5462        | Auf der Morgenstelle 10, C9       |
| Fax:    [+49/0] (7071) 29-5466        | D-72076 Tuebingen, Germany        |
|---------------------------------------------------------------------------|
| email:  miguel@gris.informatik.uni-tuebingen.de                           |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 13:21:32 GMT
From:      jamieson@bms.com (Stephen Jamieson)
To:        comp.protocols.tcp-ip
Subject:   BASIC library for TCP/IP

I know this is  strange request, but does anyone know where someone might
find a BASIC interface/library for TCP/IP ?

Its for a friend, I'm not a BASIC fan.

steve
---
   ___                                      
   ] [ Stephen Jamieson / Network Engineer || Unix Admin
  / o \ Scientific Information Systems      
 /-o---\ Bristol-Myers Squibb Pharmaceutical Research Institute
 \___o_/  Internet: jamieson@bms.com / Phone: 609-252-5674
  


-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 18:23:00 CDT
From:      zrlw05@hou.amoco.com (Rusty L. Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Help to get rid of zombies

Jonathon,

The daemon sample code fragments in "Stevens" was intended as an
example of daemon process launching done during system startup,
presumably in one of the /etc/rc* files...

If you are building "session servers" which get forked on an
onging basis, then go away after a short life span, why not
consider writing a program that can be launched from "inetd" ?

It sort of sounds like you're building something that works
like inetd anyway, unless you are building in something
extra, like maybe a communication channel between daemons.

Just wondering,
Rusty

---
----------------------------------------------------------------
Rusty Wilson                         Amoco Production Company
Stf. Geophysicist                    550 Westlake Park BLVD
0906W3 HOU - (713) 556-7082          Box 3092, Houston, TX  77253-3092


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 14:03:59 GMT
From:      amolitor@moink.NMSU.edu (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI via FTP ?

In article <24de8a$eo0@infoserv.zdv.uni-tuebingen.de>, miguel@gris.informatik.uni-tuebingen.de (Miguel Encarnacao) writes:
> Is TLI available via FTP somewhere? If so, where? I need it for SGI-Machines.

	Is it just me, or do postings about TLI make other people want to
say things like 'Well, no, Tony Li would probably get really testy if you
tried to shove him across a TCP'?

	Scatter smilies like snowflakes across this, of course.

	Andrew


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 14:17:59 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI via FTP ?

In article <24de8a$eo0@infoserv.zdv.uni-tuebingen.de>, miguel@gris.informatik.uni-tuebingen.de (Miguel Encarnacao) writes:
>
> Is TLI available via FTP somewhere? If so, where? I need it for SGI-Machines.


TLI as in STREAMS network stuff? If so, then probably not.

It involves not only a lot of library code, but a lot kernel code.
Besides the kernel STREAMS modules, you might also want some way for
STREAMS buffers to get to the if_ mbuf network drivers and vice versa.
You might also want protocol code that implements TCP/IP or UDP/IP that
can talk to STREAMS.  And there is also the hassle of talking to the
existing applications (from sendmail to inetd) that use sockets.  And
then there are the STREAMS network daemons.

I'm not sure if the network-STREAMS-over-sockets code (kernel,
libraries, and daemons) that does all of that will be shipped in IRIX 5.1


Vernon Schryver,  vjs@sgi.com

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 16:06:03 GMT
From:      lriffe@isis.unm.edu (Larry Riffe II)
To:        comp.protocols.tcp-ip
Subject:   SLIP Packet Driver for MSDOS

Does anybody know where I can get a SLIP packet driver for an MSDOS machine 
that is capable of reassembling fragmented packets?

						Larry Riffe II
						lriffe@unm.edu

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 17:57:05 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

>>> On Wed, 11 Aug 1993 13:09:27 -0500, amanda@intercon.com (Amanda Walker) said:

Amanda> pcg@aber.ac.uk (Piercarlo Grandi) writes:

pcg> Are you sure that you *can* do a single threaded implementation of
pcg> TCP/IP? Think carefully about it... :-)

Amanda> Sure you can.

Think carefully *again*... :-)

Dennis Ritchie wrote he tried very hard to avoid multithreading (and use
a simple state machine model) in Streams, and he eventually realized
that he could not in the case of upstream activity, because of the
requirement to support bidirectional, asynchronous traffic. TCP/IP is
bidirectional, asynchronous too.

Amanda> Think state machines.

Perhaps you can do the whole transmit stack or the whole receive stack
as a state machine, but you must run the two stacks in distinct threads
at some point, one way or another. And I doubt that you can really
handle all the timeouts properly even in one direction strictly only
with a state machine (polling the clock perhaps?).

Amanda> You just have to structure your API so that nothing blocks.

...and lose the ability to receive while you are transmitting. Perhaps
the transmit side could poll the receive side or viceversa, and I doubt
very much this can be made to work reliably.

But even so data can arrive and be queued at a socket/port *before* an
application (or an upper layer) has requested it (whether reads block or
not). This requires at the very least multitasking between the receive
stack and applications. Unless of course we want to require sources to
*always* retransmit until targets request data. Somehow target buffering
seems to me a rather essential feature of TCP/IP. Anybody is free to
disagree of course. :-)

Amanda> Of course, this is isomorphic to threading at some level,

I would say that a subroutine library, or even a set of coroutines, is
not multithreaded; a thread is something that has state and changes it
*asynchronously* with other threads. I would really be wary of stating
flatly that full TCP/IP can be implemented without threading. :-)

Amanda> but it does not require a multitasking kernel or OS.
 
I agree with this, eh, this is not what the guy wrote: he wanted a
single threaded *TCP/IP implementation*, not one that (implements its
own multithreading in some way or another and) runs under a single
threaded *kernel or OS*.

Of the latter type there are several, and I indicated KA9Q NOS or
WATTCP. The NCSA TCP/IP is another option in the same category:

Amanda> The TCP/IP stack from NCSA Telnet for the Mac & PC is a pretty
Amanda> complete example (the only thing it doesn't do that I know of is
Amanda> IP fragment reassembly).

Case in point... NCSA telnet is surely multi threaded; I can get
unsolicited output. There is surely at least a thread that receives data
and displays it independently of me typing something in.

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 18:01:30 GMT
From:      zjwe06@trc.amoco.com (Jerry W. Ehlers)
To:        comp.protocols.tcp-ip
Subject:   Re: Help to get rid of zombies

In article 17475@amoco.com, zjnn04@hou.amoco.com (Jonathan Nguyen) writes:
>
>I am writing a client-server application using TCP/IP socket protocol.
 
 
 
>... The server
>(parent process) died after the first successful connection to the
>client. The accept() system call failed with 'errno' = 4 (Interrupted
>system call).  
>
 
 
 
>        if ((childpid = fork()) < 0)
>	    error_exit("fork failed");

I believe a SIGCHLD signal is received when the first child terminates,
causing the parent to take the default action to clean up and abort.
Try adding a 'signal' call before the 'fork' to cause the parent process
to ignore the child's signal when it terminates.  Maybe this will be some help.

	/*
	 * 	fork the new process (ignoring child's termination)
	 */
	signal(SIGCHLD, SIG_IGN);
	pid = fork();


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 18:22:03 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

pcg@aber.ac.uk (Piercarlo Grandi) writes:
>>> On 7 Aug 93 11:00:26, peter@future.midnight.com (Peter H. Schmidt) said:
>(someone)> a) Is there somewhere a PD / shareware TCP/IP stuff writen in
>(someone)> C, which does NOT require multitasking (because our kernel
>(someone)> has no multitasking feature) ??
>
>Are you sure that you *can* do a single threaded implementation of
>TCP/IP? Think carefully about it... :-)

Not a doubt in my mind.

>You could otherwise look WATTCP, the waterloo implementation of TCP/IP
>for PCs. Just like KA9Q it is fully multithreaded, even if it runs under
>MSDOS.

WATTCP is single threaded, but it will call an optional user-supplied
yield() function, so it will easily be slipped into multithreaded 
environments with non-preemtive taskers.

It is not PD, but it is free for most situations.  FTP it from dorm.rutgers.edu
in pub/msdos/wattcp/wattcp.zip and read the copyright.h file for permissions
and other info.

Erick

-- 

Erick Engelke
erick@dorm.rutgers.edu

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Aug 1993 18:40:38 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

amanda@intercon.com (Amanda Walker) writes:
>pcg@aber.ac.uk (Piercarlo Grandi) writes:
>> Are you sure that you *can* do a single threaded implementation of TCP/
>> IP? Think carefully about it... :-) 
>
>Sure you can.  Think state machines.  You just have to structure your API so 
>that nothing blocks.  

No, restructuring the API is not necessary either.  For example, several PC 
based TCPs are single threaded and yet have full BSD-compatible network 
APIs (well, pretty darn similar, you may have to use include files to 
account for sock_write() or so_write() vs. write()).


Erick
-- 

Erick Engelke
erick@dorm.rutgers.edu

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 19:51:34 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        misc.books.technical,comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Re: TCP-IP book recommendations sought

In article <24bno6$6a7@netnews.cac.washington.edu> allen@nwnet.net writes:
>
>In article <1993Aug6.173735.17937@mccaw.com>, <peterg@eng.krldwa.mccaw.com> 
>writes:
>> I need recommendations for one or more books on TCP/IP LANs and WANs.
>> 
>
>Along with all the other good suggestions that have been mentioned,
>you might look at the new book by Daniel Lynch and Marshall Rose
>(both editors) entitled "Internet System Handbook." Addison
>Wesley, ISBN 0-201-56741-5.
>
>Great chapters by those that have been around the Internet for 
>years including Radia Perlman (Routing Protocols), Scott Bradner
>(A proctical Perspective on Routers), Stephen Kent (Architectural
>Security), Vint Cerf (Core Protocols).  Other contributers include
>Hans-Werner Braun, Jeffrey Case, Stephen Crocker, Jon Postel and 
>several others.  Well worth the bucks IMHO.
>

The more I looked at this book, the more I liked it. For a "collection" type
book, the chapters I know something about were really up to date when the book
appeared, and as peterg says, the authors are really first-class.

For any given chapter, you can probably find a book with more detail (sometimes
by the same author), but it's a really good overview resource. I'd recommend it.
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 20:03:02 GMT
From:      jik@GZA.COM (Jonathan I. Kamens)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Help to get rid of zombies

Your questions about zombies and about gettin EINTR from accept() are both
much more related to UNIX in particular than to client-server programming or
TCP/IP in general.  Therefore, I have cross-posted this response to
comp.unix.questions and directed followups there.

In article <1993Aug12.110629.17475@amoco.com>, zjnn04@hou.amoco.com (Jonathan Nguyen) writes:
|> I am writing a client-server application using TCP/IP socket protocol.
|> The server 'fork'(s) a child to handle each client request. I ended up
|> with a bunch of 'zombies' in the system. 

The question of how to get rid of zombie processes is answered in this FAQ
posting:

Subject: Unix - Frequently Asked Questions (3/7) [Frequent posting]
Newsgroups: comp.unix.questions,comp.unix.shell,news.answers,comp.answers

Available in the indicated USENET newsgroup(s), or via anonymous ftp from
rtfm.mit.edu (18.70.0.224) in the file:

/pub/usenet/news.answers/unix-faq/faq/part3

Also available from mail-server@rtfm.mit.edu by sending a mail
message containing:

send usenet/news.answers/unix-faq/faq/part3

Send a message containing "help" to get general information about the
mail server.

|> I then tried the 'skeleton daemon' as illustrated in Richard Stevens' 
|> Unix Network Programming book (p 82-85 daemon_start()). The server
|> (parent process) died after the first successful connection to the
|> client. The accept() system call failed with 'errno' = 4 (Interrupted
|> system call).  Below is the summary of what the server does:

The most common cause of EINTR is if your program gets a signal (for example,
SIGCHLD) while you're inside the accept().  For most system calls that return
EINTR, the correct thing to do is simply to restart the system call.  So you
should modify your loop so that it does this:

for ( ; ; ) {
  newsk = accept(skt,struct sockaddr *)&cli_addr,&clilen);
  if (newskt < 0) {
    if (errno == EINTR) {
      continue;
    }
    else {
      printf("accept failed, errno=%d\n", errno);
      error_exit("accept failed");
    }
  }
 ...
}
 
-- 
Jonathan Kamens	    OpenVision Technologies, Inc.       jik@GZA.COM

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1993 22:24:51 GMT
From:      axa12@po.CWRU.Edu (Ashok Aiyar)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Packet Driver for MSDOS


In a previous article, lriffe@isis.unm.edu (Larry Riffe II) says:

>Does anybody know where I can get a SLIP packet driver for an MSDOS machine 
>that is capable of reassembling fragmented packets?
>

I don't think that you will find any.  You may find a TCP
that is capable of handling packet fragmentation.

Ashok
-- 
Ashok Aiyar                                      tel: (216) 368-3300
Department of Biochemistry                       fax: (216) 368-4544
CWRU School of Medicine                  ashok@biochemistry.cwru.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 00:01:05 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Help to get rid of zombies

> I just found the way to get around the interruption to accept() call
> due to the signal SIGCHLD generated by an exiting child process. My
> sig_child() routine will set on a global flag named 'sigcldset'
> If the accept() call fails and if the flag is set, I ignore the
> error and reset the flag to zero. Then I restart the accept() call.

That may solve the problem, but a better solution (IMHO) is to test
errno on return from accept(), and if it's EINTR (an interrupted
system call) then go back and call accept() again.

	Rich Stevens  (rstevens@noao.edu)

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 93 00:34:43 GMT
From:      jag5@pge.com (John A. Giovannetti)
To:        comp.protocols.tcp-ip
Subject:   MVS/TCP IP .


 Anyone running MVS TCP/IP:
 We have a client who wants to develop a CICS application using native TCP/IP. 
 Any info on the following issues would be appreciated.
  
 
  1. What's the message throughtput between CICS and the  MVS TCP/IP component?
     How about the throughtput between the MVS TCP/IP component and the 3172?

  2. How does the product affect mainframe CPU utilization as the # 
      CiCS transactions increase?
 
  3. What's the overhead to open and close the socket every time a user
      speaks to CICS (This is how the  vendor developed the 
      application.)
     
  4. Does the TCP/IP component store the messages above or below the 16meg 
      line (for example CSA, versus ECSA)?

  5. How much does the offload feature affect the performance of the 3172
      model 3?

 

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1993 01:14:38 GMT
From:      bmorgan@bell.tansu.com.au (Brett Morgan)
To:        comp.protocols.tcp-ip
Subject:   Info wanted on RPC and TLI

Greetings,
	I am interested in any information/articles/books on RPC and TLI.
	I am a novice with regard to both.
	Thanks, Brett Morgan
	


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 93 01:20:51 GMT
From:      turner@cs.uq.oz.au (Marg Turner)
To:        comp.protocols.tcp-ip
Subject:   Refs: Multicasting over Unreliable WAN


Would anyone have any references / pointers about 
multicasting over an unreliable WAN - protocols, source etc.

TIA,

---
Margaret Turner			email: turner@cs.uq.oz.au
Department of Computer Science	fax:   +61 7 365 1999
University of Queensland
Australia  4072


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 07:08:47 GMT
From:      Kathryn Wilson <K.Wilson@unsw.edu.au>
To:        comp.protocols.tcp-ip
Subject:   Cisco Router Problems on ISDN

The Situation:
 
Large corporate network connected across NON semi permanent (Dial on
Demand)
ISDN links using Cisco 4000 Routers.
 
The Protocols:
 
Appletalk, Decnet, TCP/IP, IPX..
 
The Problem:
 
Cisco routers will only initiate and hold links when forwarding TCP/IP
traffic
across the remote link.
 
The Question:
 
How to initiate and hold open links where the service requested is based
on
Appletalk only protocols?  That is AFP sessions or PAP print requests?
 
If you can help please send information to:
 
            
_________________________________________________________________
             Anthony WOLFENDEN
   ,-_|\     Senior Systems Engineer     E-mail:
AUST0105@applelink.apple.com
  /     \    Logical Solutions           APPLELINK:  AUST0105
  \_,-._* <- 55 Mountain St              Compuserv:  100033.1314
       v     Ultimo 2007                 Phone:      +61 18 611 558
             Sydney, AUSTRALIA           Fax:        +61 2 371 9449
            
_________________________________________________________________

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 07:45:00 GMT
From:      Stefan.Paulsson@malmo.trab.se (Stefan Paulsson)
To:        comp.protocols.tcp-ip
Subject:   Fast connection loss detection

Hello,

I need to detect when my connected TCP socket looses its contact
with the remote side. The program must be able to run on different
operating systems.

I need something where a verification can be made every minute,
thus the SO_KEEPALIVE option using setsockopt(2) can not be used
since this requires that a connection is idle for 2 hours before
a packet is sent.

Somebody suggested a while ago that you can probe your connection
via send(2) using OOB (out of band) data. To avoid having the OOB
data appear in the client's normal receive buffer, the SO_OOBINLINE
option using setsockopt(2), must be turned off. I'm doing that and
OOB data is sent on a connected socket to a remove machine. When
power on the remote host is turned off or the host is disconnected
from the LAN, and more OOB data sent, different operating systems
behave differently.

When the sending process runs on HP-UX9.0, two calls to
 send( fd, " ", 1, MSG_OOB ); is made before an error occurs and
perror(3) returns "No buffer space available". This is OK and
helps me to solve the problem.

If I do the same with a sparcstation 2 using SunOS 4.1.3,
approximately 4600 simular calls must be made before send(2)
returns an error. perror(3) then returns the same result "No buffer
space available". This is not so good since it will cost too much
to send that much OOB data, one byte at a time, every minute.


(a) Is there a buffer that must be filled in the SunOS case or
    what?

(b) Is there a way to work around the problem, e.g. reduce the
    buffer to 1 byte?

(c) Is there a bug in SunOS 4.1.3 or is the solution with OOB data
    something that is not required by the standard?

(d) Is there another way for me to verify that connections still
    have contact with their remote peer. Mayby a standard way that
    everybody knows about.

I haven't tried Solaris 2 yet.

Thanks Stefan

email: Stefan.Paulsson@malmo.trab.se


-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 13:41:24
From:      jobrien@mcs.umes.umd.edu (James M. O'Brien, Jr)
To:        comp.protocols.tcp-ip
Subject:   help needed: slattach error

I am trying to install a slip driver on a Sun SS1+ SunOS 4.1.2.  The slip 
package is csn-package-slip4.1.1.

I've installed per the readme's and compiled slattach.  When I log into the
sun and run slattach I get the following error:

   sparky slattach[193]: ioctl (I_PUSH) slipen: Invalid argument

If this sounds familiar to anyone and you have a solution, I'd appreciate 
hearing from you.  I'm new to slip, so if you need more info let me know.

Thanks.



Jim O'Brien, CNE                University of Maryland Eastern Shore
jobrien@mcs.umes.umd.edu        Network Manager

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1993 14:04:58 GMT
From:      enbcf@mailhost.tcs.tulane.edu (Bryan Foster)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?


At work I have Novell's Lan Workplace for DOS running on 486s along with
IPX.  Both protocols are bound to our Tiara Lancarde/E NICs and the only
problem I haveis that Cadkey sometimes locks up on us.  Other than that,
we ftp files from the SGIs on a regular basis and have no problems.


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 15:38:18 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Proper response code to FTP's "CWD" command?

> I just noticed something interesting while trying to use "xarchie" 2.0.8.
> Most FTP servers will respond to a (valid) "CWD" request with an answer like
> "250 CWD command successful.".
> 
> I have found a few servers (like lynx.CS.ORST.EDU, for example) that respond
> "200 CWD command okay.".
> 
> This causes xarchie 2.0.8 to barf (and abort the FTP) with an error popup:
 ...
> I don't have the RFC for FTP handy; is "200 CWD command okay." a legal return
> value here, or is the (nominal) 250 the correct value?  Is the FTP server in
> the wrong, or is "xarchie" wrong for rejecting it?

The human readable text after the numeric reply code is allowed to vary,
according to RFC-965 p. 35:

      An FTP reply consists of a three digit number (transmitted as
      three alphanumeric characters) followed by some text.  The number
      is intended for use by automata to determine what state to enter
      next; the text is intended for the human user.  It is intended
      that the three digits contain enough encoded information that the
      user-process (the User-PI) will not need to examine the text and
      may either discard it or pass it on to the user, as appropriate.
      In particular, the text may be server-dependent, so there are
      likely to be varying texts for each reply code.

but a "200" numeric reply value is *not* a legal reply to CWD, according to
RFC-965 pp. 49-50:
----------------------------------------------------------------------
      Command-Reply Sequences

         In this section, the command-reply sequence is presented.  Each
         command is listed with its possible replies; command groups are
         listed together.  Preliminary replies are listed first (with
         their succeeding replies indented and under them), then
         positive and negative completion, and finally intermediary
         replies with the remaining commands from the sequence
         following.  This listing forms the basis for the state
         diagrams, which will be presented separately.
...
               CWD
                  250
                  500, 501, 502, 421, 530, 550

So the ftp server is expected to reply "250", but the human readable text
could in principle say "frobnitz" or something similarly uninformative.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 93 17:00:49 GMT
From:      jim@grimaldi.rutgers.edu (Jim Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted Src: UDP for IBM/PC (DOS)

itb451natzke@qut.edu.au writes:

>I'm looking for source code to an implementation of the network protocol 
>UDP/IP (versus TCP/IP) module for IBM PC running DOS.  All responses greatly
>appreceiated.  Thank you.

	When refering to a "TCP/IP" implementation, you are generally
refering to an implementation of the IP suite of protocols. These are
primarily TCP, UDP, and ICMP. So, if I understand you correctly, you
just need a IP for the PC which implements UDP (I think they all do).
My suggestion would be WATTCP, which can be found via anonymous ftp on
ftp-ns.rutgers.edu in /pub/msdos/wattcp. Good luck!

							Jim

-- 
	Jim Martin			Internet: jim@noc.rutgers.edu
	Network Services		UUCP: {backbone}!rutgers!jim
	Rutgers University		Phone: (908) 932-3719

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 17:02:43 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

>>> On Thu, 12 Aug 1993 18:22:03 GMT, erick@sunee.uwaterloo.ca (Erick
>>> Engelke) said:

Erick> pcg@aber.ac.uk (Piercarlo Grandi) writes:

pcg> You could otherwise look WATTCP, the waterloo implementation of
pcg> TCP/IP for PCs. Just like KA9Q it is fully multithreaded, even if
pcg> it runs under MSDOS.

In this I must admit I exxagerated: the recent "NOS" releases of KA9Q
actually implement multiple processes in a way WATTCP does not quite
equal. The WATTCP multithreading is not as "full", yet it works well.

Erick> WATTCP is single threaded,

So WATTCP is single threaded. Wonderful. Since it is single threaded,
after an application invokes it to establish a connection, and before a
read() is done, all intervening packets are dropped because the single
thread of control is now executing the user code? :-) (this is the
problem with upward Streams traffic that Ritchie hoped to solve but
obviously couldn't).

Erick> but it will call an optional user-supplied yield() function, so
Erick> it will easily be slipped into multithreaded environments with
Erick> non-preemtive taskers.

What I would call this is cooperative multithreading between the
application and WATTCP; the WATTCP thread is scheduled when an interrupt
arrives or when the application invokes it, and the application thread
is scheduled on return from an interrupt or from a call to the WATTCP
stack or, kindly, on a temporary return (the yield call) from WATTCP.


Just to be more precise: it is possible (and a rather popular technique)
to implement both directions of a TCP/IP stack using a sort of event
loop model within a single thread, even if doing so one loses fragment
reassembly; but this one thread *must* be an independent thread
(stateful, asynchronous) from the application thread.

One cannot implement TCP/IP as a pure subroutine (or even coroutine)
library. It *must* be done with at least one independent thread just for
the TCP/IP stack; and to do fragment reassembly, it *must* be done with
multiple threads (one really cannot handle the timeouts with just an
event loop), in various ways simulated.


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 17:25:34 GMT
From:      harvey@vax.cns.muskingum.edu (Ryan Harvey)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Giant Packets? - I found the culprit!

In article <melanie.744606784@ph-meter.beckman.uiuc.edu>, melanie@ph-meter.beckman.uiuc.edu (Melanie Humphrey) writes:
> dpm@wixer.bga.com (David Maynard) writes:
> 
>>harvey@vax.cns.muskingum.edu (Ryan Harvey) writes:
>>>I have a sparcstation 2 running SunOs 4.1.2.  I am using it as a fileserver
>>>for our Macs and PCs on campus.  I am getting an error which I am not sure
>>>what it means.  Below is the message I have in my error file:
>>>Jul 31 05:43:00 moon vmunix: le0: Receive: giant packet from xx-xx-xx-xx-xx-xx
>>>Jul 31 05:43:05 moon vmunix: le0: Receive: STP in rmd cleared
>>


I found it!  I tracked down the ethernet address and found out that it wasn't
that machine which was the problem, but rather the 10BaseT hub to which it
was connected.  I replaced the card (10BaseT card in our Xyplex chasis),
and all of a sudden, my giant packet messages disappeared (not to mention
a few other quirks).  Thanks for all the advice!

Ryan Harvey
HARVEY@VAX.CNS.MUSKINGUM.EDU

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 17:40:07 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>>>> amanda@intercon.com (Amanda Walker) said:
>
>pcg> Are you sure that you *can* do a single threaded implementation of
>pcg> TCP/IP? Think carefully about it... :-)
>
>Amanda> Sure you can.
>
>Think carefully *again*... :-)
>
>Perhaps you can do the whole transmit stack or the whole receive stack
>as a state machine, but you must run the two stacks in distinct threads
>at some point, one way or another. And I doubt that you can really
>handle all the timeouts properly even in one direction strictly only
>with a state machine (polling the clock perhaps?).

Poppycock!  I have a 2210 line reply, just download my TCP which
accomplishes this without any particular brilliance.

Suppose you are on an Ethernet and getting TCP performance of about
100 kbytes/s.  That means you write your data out to the network 
card and sit idle waiting for it to be acked.  But while you are
waiting, why not process any incoming packets, including ones related
to other sockets.  You just update the buffers (ie. dispose of ACK'd
data, buffer incoming data) and update the TCP state machines, and
possibly ACK or otherwise respond to the inbound packets.  It also
gives you time to do retransmits on timed-out data, etc.  This is
all trivial housework.

>But even so data can arrive and be queued at a socket/port *before* an
>application (or an upper layer) has requested it (whether reads block or
>not). This requires at the very least multitasking between the receive
>stack and applications. Unless of course we want to require sources to
>*always* retransmit until targets request data. Somehow target buffering
>seems to me a rather essential feature of TCP/IP. Anybody is free to
>disagree of course. :-)

Not at all, the TCP just buffers incoming data until the application
is ready to read it.  ALL decent TCP systems have to do this, otherwise 
they would kill our networks with zero probes waiting for applications
to accept data.

>  I would really be wary of stating
>flatly that full TCP/IP can be implemented without threading. :-)

In retrospect, WATTCP programmers may be slightly confused because 
the documentation pretends that its sockets implementation is in
the system software and thwarts obvious attempts to muddle in its
data structures.  But that was just a design choice because I don't
believe application programs should mess with the internals of a
library, particularly when the author feels no obligation to keep
the internals at all similar from one release to the next.

Erick
-- 

Erick Engelke                
Engineering Computing

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 93 18:26:44 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Can I have IPX and TCP/IP at the same time?

In article <24ekuo$c14@wampyr.cc.uow.edu.au> mai@wampyr.cc.uow.edu.au writes:

      Any one can show me how to build a DOS station with IPX and TCP/IP
   access at the same time? Windows for Workgroup would do but it does not
   allow PD software to run. I am talking about stuffs like NCSA telnet
   or gopher.

Sure.  Get yourself the Crynwr packet drivers, then from the same
place, pdipx103.zip.  With the latter, shgen a new IPX.COM.
Install the appropriate packet driver for your card, then run IPX,
then NETX, then run NCSA Telnet, gopher, whatever.


-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem.  The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add $35
check-cashing fee.

  1. Binaries and documentation:        $35  /  $40
  2. Source code:                       $60  /  $68

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>.  The drivers are there, along
with many free programs that use the packet drivers.

SIMTEL20 files are also available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6),
nctuccca.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file
servers.

Modem:

If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.

CD-ROM:

Public, private or corporate institutions and libraries interested in
the SIMTEL20 MS-DOS collection in CD-ROM format bundled with library
card-catalog type access and duplication software can contact Coyote
Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307 or by FAX at
(313) 651-4071.  Others who do not need the access and duplication
software should send e-mail to: rab@cdrom.com (Robert Bruce), telephone
(800) 786-9907 or (510) 947-5996, or FAX (510) 947-1644 for details on
his CD-ROM offer.


UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "marvin"

-- end of HOWTOGET.IT

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

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 93 18:28:37 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Wanted Src: UDP for IBM/PC (DOS)

In article <1993Aug13.155957.66726@qut.edu.au> itb451natzke@qut.edu.au writes:

   I'm looking for source code to an implementation of the network
   protocol UDP/IP   (versus TCP/IP) module for IBM PC running DOS.
   All responses greatly appreceiated.  Thank you.

An assembly-language version (which is appropriate for some problems)
is available as oak.oakland.edu:pub/msdos/pktdrvr/pdclk152.zip.  A
C-language version appropriate for linking into your application is
wattcp, available from dorm.rutgers.edu:pub/wattcp/*.

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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 20:07:54 GMT
From:      quyen@nist.gov (Quyen_Ngo_x3860)
To:        comp.protocols.tcp-ip
Subject:   SLIP problem.


I am trying to run SLIP on an IBM 486 lap top PC with the following
software loaded:

	- DOS Version 6.0
	- PC/TCP Version 2.1
	- Kermit Version 3.13
	- ProcomPlus Version 2.1

The SLIP packet was cut short (garble) when a ping command was executed
after establishing the modem connection to the remote SLIP server with
Kermit (no SLIP packet received from the SLIP server) but it worked if
ProcomPlus was used.

If you had any experience similar to this problem please let me know.

Thanks,
Quyen

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 93 20:12:17 GMT
From:      esasaki@nyx.cs.du.edu (Eric Sasaki)
To:        comp.org.acm,comp.protocols.tcp-ip
Subject:   TCP/IP Performance Monitoring Info Sought

My name is Eric Sasaki, and I am a student at Georgia Tech.  This summer I am
interning with U S WEST Communications' Information Technologies Services
department with the Performance Monitoring Group.  We currently track avail-
ability and response time of the various U S WEST internal data communications
networks based on several different architectures, such as SNA and BANCS.

However, the company is in the process of migrating these networks to a
TCP/IP based "corporate internet."  This network will be isolated from the
the Internet via a firewall machine and will be, in essence, a mini-Internet.
Unfortunately, we have neither the experience nor the tools to measure the
performance of this network.  This is very important to our department, since
the market units that will use the internet will demand some form of service
level agreement as far as performance of the network goes.

Thus, we are looking for individuals or groups around the world that have had
real world experience in tracking performance of the Internet so that we may
develop standards for the U S WEST corporate internet.

If you have any information regarding methods or tools to accomplish TCP/IP
performance measurement (availability, packet efficiency, response time,
utilization, etc.) or know someone who does, I would be very interested from
hearing from you.  In my search, I have discovered that there are very few
individuals who know anything about this topic.

Please respond by e-mail to esasaki@nyx.cs.du.edu, and I will summarize any
responses to this group.

Thanks!

Eric M. Sasaki
Intern
U S WEST Information Technologies Services
Sustaining Engineering, Performance Monitoring Group
931 14th Street, Room 1110
Denver, CO 80202
--
Eric M. Sasaki, Georgia Tech INTA Undergrad | Nam et ispa scientia potestas est.
Internet:  esasaki@nyx.cs.du.edu  <or>      | [Knowledge is power.]
	   gt7294b@prism.gatech.edu         |                   - Francis Bacon
Slow Boat: Box 37294 Georgia Tech Station, Atlanta, Georgia 30332-1001 USA

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 20:18:03 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Proper response code to FTP's "CWD" command?

In article <24eqi6$29n@isolar.Tujunga.CA.US>
earle@isolar.Tujunga.CA.US (Greg Earle) writes: 
>I have found a few servers (like lynx.CS.ORST.EDU, for example) that respond
>"200 CWD command okay.".
>This causes xarchie 2.0.8 to barf (and abort the FTP) with an error popup:
 
>I don't have the RFC for FTP handy; is "200 CWD command okay." a legal return
>value here, or is the (nominal) 250 the correct value?  Is the FTP server in
>the wrong, or is "xarchie" wrong for rejecting it?

I maintain that xrachie is wrong.  It should see the "2" in the 200
and assume that it was cool because 2xx means "Operation compeleted
successfully"  Quibbling over 250 vs 200 on xarchie's part seems
petty.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 20:29:59 GMT
From:      chris@bermuda.ucd.ie
To:        comp.unix.aix,comp.databases,comp.databases.sybase,comp.protocols.tcp-ip
Subject:   [Q] Where to buy Sybase in Ireland/England/Europe???

Greetings Netters!
I am currently looking into the possibility of setting up Sybase on an
IBM RS/6000 (AIX v3.2) in the near future. I was wondering if anyone
reading this might know where in Ireland or England (or failing that
the rest of Europe) I might be able purchase Sybase products. Addresses,
Phone and FAX numbers would be greatly appreciated....(Rough Prices too if
anyone has any!!)
        Also, I was wondering if anyone might have any comments or advice
as regards setting up Sybase on an IBM system....I'm well experienced in
Unix System Admin., but I know nothing about databases or their management.
It is (as far as I can tell!) intended that the *nix box will act as a
database server for a number of PC's which will use GUI software running
in an OS/2 environment to access data from the RS/6000 accross an Ethernet
network via IBM TCP/IP for OS/2. Anyone see any problems here I should know
about? Any and all replies greatly appreciated, as always. Thanx in advance.

 Chris Bradshaw
 ----------------------------------------------------------------------------
 100 Marlborough Road,      |   Internet:   chris@bermuda.ucd.ie
 Donnybrook,                |               bradshaw@ccvax.ucd.ie
 Dublin 4.                  |               cbradh89@irlearn.ucd.ie
 Republic of Ireland.       |               
                            |   Voice:      +353-1-706-2202
			    |   FAX:        +353-1-283-7275
 ----------------------------------------------------------------------------  

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 93 23:08:51 GMT
From:      efb@engsun.nswses.navy.mil (Everett F Batey)
To:        comp.protocols.tcp-ip
Subject:   Need to get a slip by Sat on 4.1.2 Sun4

Urgently searching for a slip that drops in without debugging a bunch
of documentation errors on a SUN4 with SunOS 4.1.2 and a USR V.32 modem
that needs to talk to an Annex by Sunday .. H E L P .. /ev/
--
 +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
 +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
 +  Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns  WAFFLE  +

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Aug 1993 23:28:21 GMT
From:      danny@dragon.stgt.sub.org (Daniel T. Schwager)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

Amanda Walker (amanda@intercon.com) wrote:
: pcg@aber.ac.uk (Piercarlo Grandi) writes:
: > Are you sure that you *can* do a single threaded implementation of TCP/
: > IP? Think carefully about it... :-) 
 
: Sure you can.  Think state machines.  You just have to structure your API so 
: that nothing blocks.  Of course, this is isomorphic to threading at some 
: level, but it does not require a multitasking kernel or OS.  THe TCP/IP stack 
: from NCSA Telnet for the Mac & PC is a pretty complete example (the only 
: thing it doesn't do that I know of is IP fragment reassembly).

Ok, there are serveral TCP/IP programs based on MS-DOS (ka9q, ncsa, wattcp ...)
I ftp'd ka9q (src0411.zip, is this the newest version??) for MS-Dos and find
a lot of assembler code and the multitread implementation (TSR ?), somebody 
spoke about in the last article. 

Now, my (our) situation has changed a little:
It's possible for me to get a realtime-multitasking kernel for the
processor, we want to base the TCP/IP (and of course the X-System) on.
I find a ka9q implementation for linux and the net-code for BSD.
So, what do you think is the best (C-written, no Intel assembler)
TCP/IP base of a multitasking TCP/IP PD stuff.

Tomorrow i will have a closer look at the ka9q-linux-code.......

regards

Danny

P.S. Thanks for all your articles related to my problem 

-- 
                       ,,,
                      (^ ^)               
------------------oOO--(_)--OOo-----------------------
                                                 Danny

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1993 09:49:44 +1000
From:      mai@wampyr.cc.uow.edu.au (Van Dao Mai)
To:        comp.protocols.tcp-ip
Subject:   Can I have IPX and TCP/IP at the same time?


Lines:  17

Dear all,
   Any one can show me how to build a DOS station with IPX and TCP/IP
access at the same time? Windows for Workgroup would do but it does not
allow PD software to run. I am talking about stuffs like NCSA telnet
or gopher.
   I know off ODI drivers, but cannot find documentation to set this
stuff up. Also there are other drivers like ipxpkt from the net.
Please help, reply by e-mail thanks.


Van Dao Mai
Wollongong University 
Australia




-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14 Aug 93 06:28:06 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Proper response code to FTP's "CWD" command?

	I'd say both the ftpd and xarchie are wrong (as is usually the case 
with most interoperability problems, it seems). Ftpd for using a weird 
response code, and xarchie for not dealing with it right. The principle 
be conservative in what you do, liberal in what you accept would solve 
this problem on either end (that phrase is in rfc 793 the tcp one, it might 
be in the others-anyway, it is an internet philosophy).

	It all goes to show, breaking with standards can really hose one. 
I would say the both programs should be revised...



-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 93 15:59:57 +1000
From:      itb451natzke@qut.edu.au
To:        comp.protocols.tcp-ip
Subject:   Wanted Src:  UDP for IBM/PC (DOS)

Hi!

I'm looking for source code to an implementation of the network protocol UDP/IP
(versus TCP/IP) module for IBM PC running DOS.  All responses greatly
appreceiated.  Thank you.

Fred NATZKE.
Email:  itb451natzke@qut.edu.au
   or:  n0948861@water.fit.qut.edu.au  

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 93 12:58:48 GMT
From:      mayshah@gandalf.rutgers.edu (Mayank Shah)
To:        comp.protocols.tcp-ip
Subject:   Slip with FTP-PC/TCP


Hey folks,

Does any one know if there is a patch for the slip driver which comes with
FTP - PC/TCP ver 2.2?  If so where can I get a copy of it?

Thanks,

 Mayank
-- 
------------------------------------------------------------------------------
Mayank Shah				Rutgers University
mayshah@gandalf.rutgers.edu

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 93 12:59:36 GMT
From:      mayshah@gandalf.rutgers.edu (Mayank Shah)
To:        comp.protocols.tcp-ip
Subject:   binding multiple protcols to the card


Hey folks,

Can someone send me a working copy of their protocol.ini file in which you
are binding 2 different protocols to the card.  I am having a hell of a time
trying to figure this out.

Thankx,

 Mayank
-- 
------------------------------------------------------------------------------
Mayank Shah				Rutgers University
mayshah@gandalf.rutgers.edu

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Aug 1993 02:08:42 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

In article <745266404snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>In article <24ekuo$c14@wampyr.cc.uow.edu.au> mai@wampyr.cc.uow.edu.au writes:
>
>      Any one can show me how to build a DOS station with IPX and TCP/IP
>   access at the same time? Windows for Workgroup would do but it does not
>   allow PD software to run. I am talking about stuffs like NCSA telnet
>   or gopher.
>
>Sure.  Get yourself the Crynwr packet drivers, then from the same
>place, pdipx103.zip.  With the latter, shgen a new IPX.COM.
>Install the appropriate packet driver for your card, then run IPX,
>then NETX, then run NCSA Telnet, gopher, whatever.
>
>

I would offer slightly different advice.

If I were you I would use the ODI interface and use odipkt or pdether. 
The way I always do this is change the net.cfg 

add the following

link driver 3c509    	# replace 3c509 with your mlid name.
   frame ethernet_802.3	# this is what we run our ipx over
   frame ethernet_II 	# this is what we run ip over

then I have a netware.bat which contains the following

lsl
5c509
ipxodi
netx 	# or vlm
odipkt 1 96	# this means load odipkt on board #2 at hex interrupt 60
		# (96 decimal = hex 60)

Ben James

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Aug 1993 23:34:09 GMT
From:      westes@netcom.com (Will Estes)
To:        comp.protocols.tcp-ip,comp.unix.programmers,comp.terminals
Subject:   Where to get VT-100 source code in public domain?

I need to write a simple VT-100 emulator as part of a commercial
product.  Where does one find the specifications for VT-100, and is
there any code in the public domain for this emulation that can be
used as either a reference or actually copied into a commercial
product?

If no such code exists, is there a commercial source for the code
that will license it very cheaply.

-- 
Will Estes		Internet: westes@netcom.com

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1993 05:43:22 GMT
From:      jel@xerver.icl.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip,comp.unix.programmers,comp.terminals
Subject:   Re: Where to get VT-100 source code in public domain?

westes@netcom.com (Will Estes) writes:

>I need to write a simple VT-100 emulator as part of a commercial
>product.  Where does one find the specifications for VT-100, and is
>there any code in the public domain for this emulation that can be
>used as either a reference or actually copied into a commercial
>product?

Presumably Digital will sell you the appropriate reference manuals.

MS-Kermit sources might serve as a reference, although the display
emulation is unfortunately :-) already at the VT-320 level. However,
I have not looked closely enough at the copyrights to know, if the
code could be directly incorporated into a commercial product.

/Jerry Lahti

-- 
Jerry Lahti             !  tel. +358-0-567 3639
ICL Personal Systems Oy !  fax. +358-0-567 5670
P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Aug 1993 06:58:41 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Fast connection loss detection

In article <1993Aug13.074500.18793@malmo.trab.se> Stefan.Paulsson@malmo.trab.se (Stefan Paulsson) writes:
>I need to detect when my connected TCP socket looses its contact
>with the remote side....
>
>Somebody suggested a while ago that you can probe your connection
>via send(2) using OOB (out of band) data....

Why out-of-band?  Just send normal data.  If you're interested in
portability, out-of-band data is simply out of the question.  Just as
well: i don't see that it's gaining you anything, anyway.

						don provan
						donp@novell.com

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Aug 1993 15:31:26 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP PD Stuff

 pcg@aber.ac.uk (Piercarlo Grandi) writes:
> erick@sunee.uwaterloo.ca (Erick Engelke) said:
>
>Erick> WATTCP is single threaded,
>
>So WATTCP is single threaded. Wonderful. Since it is single threaded,
>after an application invokes it to establish a connection, and before a
>read() is done, all intervening packets are dropped because the single
>thread of control is now executing the user code? :-) (this is the
>problem with upward Streams traffic that Ritchie hoped to solve but
>obviously couldn't).

Not at all.  

Simple case example, here  I am assuming an Ethernet card with
only a single packet buffer - a few such things still exist in museums! 
Packet arrives, hardware generates interrupt, packet driver services 
interrupt, packet driver upcalls WATTCP instantly, WATTCP returns pointer 
to a free buffer, packet driver interrupt copies new packet from ethernet 
NIC to my supplied buffer, resets Ethernet card to accept new packets
and returns to whatever it was doing.

So the main library routines just have to sort through the queue of
received packets and process them whenever they have a chance.  This
tends to be very soon, but TCP is much less picky than I have ever
needed.  The very nature of TCP means that replies don't have to be
instantaneous, or even that they should be.  

   RFC 1122, 4.2.3.2  

            A TCP SHOULD implement a delayed ACK, but an ACK should not
            be excessively delayed; in particular, the delay MUST be
            less than 0.5 seconds, and in a stream of full-sized
            segments there SHOULD be an ACK for at least every second
            segment.


In reality, most applications call *some* WATTCP function within a
millisecond or two, so it works without problem.  My trivial TELNETD
program ties to the timer tick, so it calls the processing function
every 55 ms, and still works fine.  

And my FTP program is probably the fastest free one available on
the PC, so there really are no ill effects from this approach.

>Erick> but it will call an optional user-supplied yield() function, so
>Erick> it will easily be slipped into multithreaded environments with
>Erick> non-preemtive taskers.
>
>What I would call this is cooperative multithreading between the
>application and WATTCP; the WATTCP thread is scheduled when an interrupt
>arrives or when the application invokes it, and the application thread
>is scheduled on return from an interrupt or from a call to the WATTCP
>stack or, kindly, on a temporary return (the yield call) from WATTCP.

Not quite, WATTCP does not consume a thread.  It runs in the user's
current thread, off the same stack, etc.   It's much like printf
in that regard.  When it calls yield, it is that user's current
thread which yields.  WATTCP is still callable from any other thread.

>Just to be more precise: ....
>One cannot implement TCP/IP as a pure subroutine (or even coroutine)
>library. It *must* be done with at least one independent thread just for
>the TCP/IP stack; and to do fragment reassembly, it *must* be done with
>multiple threads (one really cannot handle the timeouts with just an
>event loop), in various ways simulated.

I don't know why you are so insistant about it, that is exactly
the way I (and many others have done it) - pure subroutines
(and trivial pseudo-interrupt handler).

Actually, the interrupt-styled handler is only required because
packet drivers need it.  A pure polling system would work if 
there were enough packet buffers on the network card, then it
would just be a subroutine library.

Erick
-- 

Erick Engelke                
Engineering Computing

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1993 12:31:36 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

Van Dao Mai (mai@wampyr.cc.uow.edu.au) wrote:

: Lines:  17
 
: Dear all,
:    Any one can show me how to build a DOS station with IPX and TCP/IP
: access at the same time? Windows for Workgroup would do but it does not
: allow PD software to run. I am talking about stuffs like NCSA telnet
: or gopher.

Use Crynwr (formerly Clarkson) packet drivers. NCSA Telnet (or better, CUTCP)
will run on top of it. For IPX, use ipxtcp.com on top of packet driver instead 
of ipx.com. It works for us very well. The stack looks like this:

net5.exe (Novell shell)
        ^
        |
        v
    IPXTCP.COM        CUTCP (from Rutgers Univ.)
        ^                ^
        |                |
        |                |
        v                v
       Crynwr packet driver
                ^
                |
                v
       hardware (Ethernet card)
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 93 21:57:57 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip,comp.terminals
Subject:   Re: Where to get VT-100 source code in public domain?

In article <24n6pq$pr8@toffu.icl.fi>, jel@xerver.icl.fi (Jerry Lahti) writes:
> westes@netcom.com (Will Estes) writes:
> 
>>I need to write a simple VT-100 emulator as part of a commercial
>>product.  Where does one find the specifications for VT-100, and is
>>there any code in the public domain for this emulation that can be
>>used as either a reference or actually copied into a commercial
>>product?
> 
> Presumably Digital will sell you the appropriate reference manuals.
> 
> MS-Kermit sources might serve as a reference, although the display
> emulation is unfortunately :-) already at the VT-320 level. However,
> I have not looked closely enough at the copyrights to know, if the
> code could be directly incorporated into a commercial product.
> 
> /Jerry Lahti
> 
> -- 
> Jerry Lahti             !  tel. +358-0-567 3639
> ICL Personal Systems Oy !  fax. +358-0-567 5670
> P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
> 00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY
------------------
	Here's the copyright notice from MS-DOS Kermit:

;  Copyright (C) 1985, 1993, Trustees of Columbia University in the 
;  City of New York.  Permission is granted to any individual or institution
;  to use this software as long as it is not sold for profit.  This copyright
;  notice must be retained.  This software may not be included in commercial
;  products without written permission of Columbia University.

	So no, one can't use the material for commercial products. The ref for
DEC VT100's is from Digital themselves (that's by far the best ref too).
        Joe D.


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1993 16:13:28 +0100
From:      cmft@doc.ic.ac.uk (C M F Tsang)
To:        comp.protocols.tcp-ip
Subject:   Routing table & machine types



I am currently writing an SNMP client application to query the routing information on certain hosts and gatways so that I can find out what 
machines it is connected to. Basically, it is to map out the whole subnet, then query the next gateway for another subnet, trying to map out the whole 
'autonomous' site. i.e. not going out to the connected internet.

My questions are : 
1. 	If the gateway uses ARP & RIP to find out physical addresses
and routing infos of its connections, and if the gateway is not up very
long, is there a possiblity that the routing table will not contain all the connections ? If that's the case then my algorithm will not work because 
it relies on the routing table (ipRoutingTable).  Anyone got a better idea?

2.	In MIB II, the address translation group exists only for 
compatiblitiy reasons( according to RFC1213 ), so can I use it still?
i.e. would it be updated? Do I need to use the new objects ipNetToMediaTable?

3.	Is there anyway to find out whether a connected machine is a host,
a gateway or just a terminal ( including dumb and X-terminals ) by looking
at a MIB object? I don't seem to find one except ipForwarding tells me the
machine can route packets( presummably a gateway? )


Not being a SNMP or TCP/IP expert, any help to any of the questions welcomed. Especially someone has a better way to map out machines on a network. I
think I can use the kernel routing table to do something similar but
it seems infinitely harder for me to understand how to dig out the info
from the kernel memory. Reply to me directly welcomed.

Frank Tsang
cmft@doc.ic.ac.uk

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 93 17:59:31 GMT
From:      spoelhof@kodakr.kodak.com (Gordon C. Spoelhof)
To:        comp.protocols.tcp-ip
Subject:   Re: Proper response code to FTP's "CWD" command?

In article <24eqi6$29n@isolar.Tujunga.CA.US>, earle@isolar.Tujunga.CA.US 
(Greg Earle) writes:
> From: earle@isolar.Tujunga.CA.US (Greg Earle) 
> Newsgroups: comp.protocols.tcp-ip,comp.windows.x 
> Subject: Proper response code to FTP's "CWD" command? 
> Keywords: FTP  xarchie  2.0.8  CWD  200 
> Date: 13 Aug 93 01:25:26 GMT 
> Organization: Personal Usenet site, Tujunga, CA USA 
> 
> I just noticed something interesting while trying to use "
> xarchie" 2.0.8. Most FTP servers will respond to a (valid) "CWD" 
> request with an answer like "250 CWD command successful.". 
> 
> I have found a few servers (like lynx.CS.ORST.EDU, for example) that 
> respond "200 CWD command okay.". 
> 
> This causes xarchie 2.0.8 to barf (and abort the FTP) with an error 
> 	popup: _____________________ 
> 	| FTP Error 200:    | 
> 	|  CWD command okay.| 
> 	| +--+              | 
> 	| |Ok|              | 
> 	| +--+              | 
> 	|___________________| 
> 
> I don't have the RFC for FTP handy; is "200 CWD command okay." a legal 
> return value here, or is the (nominal) 250 the correct value?  Is the 
> FTP server in the wrong, or is "xarchie" wrong for rejecting it? 

Hmmm - the answers are yes and no depending...

According to RFC-959, the correct response should be 250 to a CWD command.
However, clients (in this case xarchie) should be able to reply correctly depending
on the leading digit "2xx" class responses from a server indicate successful
completion of a command.  To make matters worse, the server may not have
fully implemented the CWD command per RFC959, rather implemented according
to an earlier recommendation for directory commands - RFC 775 " Directory 
oriented FTP commands".  The correct response for servers based on this older,
but not obsolete RFC would be 200.  I have a FTP client which sends a CWD 
command.  If that fails (command unsupported) a XCWD command is sent for 
older clients...  Which did your client request?  I suspect it sent the CWD...


Have a good time!

Gordon Spoelhof
Eastman Kodak Co.


Gordon Spoelhof
Eastman Kodak Company / Health Sciences Division
25 Edendery Circle / Fairport, NY 14450-1013
Email: spoelhof@kodak.com
Phone: 716-253-9735 / FAX: 716-253-7966

Myopiceconomics: (n) the study of increased system cost through unit optomizat


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1993 18:34:04 GMT
From:      markm@kandinsky.intel.com (Mark Morrissey)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:

>Van Dao Mai (mai@wampyr.cc.uow.edu.au) wrote:
 
>: Lines:  17
 
>: Dear all,
>:    Any one can show me how to build a DOS station with IPX and TCP/IP
>: access at the same time? Windows for Workgroup would do but it does not
>: allow PD software to run. I am talking about stuffs like NCSA telnet
>: or gopher.
 
>Use Crynwr (formerly Clarkson) packet drivers. NCSA Telnet (or better, CUTCP)
>will run on top of it. For IPX, use ipxtcp.com on top of packet driver instead 
>of ipx.com. It works for us very well. 

Or, of course, buy Lan Workplace for DOS from Novell.  I am currently running from
an xterm on my pc against my Sun workstation why reading IPX-based cc:mail in
another window.

No problems.

--mark
---
Mark Morrissey                    Intel Corp.
Senior Engineer                   Portland, Oregon  USA
SNMP/IP kinda guy                 +1 503 696 2068
markm@kandinsky.intel.com         #include <disclaimer.std>
"I don't speak for them.  They don't speak for me."

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Aug 1993 20:19:56 GMT
From:      dtalleri@maestro.mitre.org (David Tallerico)
To:        comp.protocols.tcp-ip
Subject:   tli conflicts with lwp?

 Has anyone gotten Sun's tli routines to work in the context
 of the lightweight process library?  Basically what I've done is 
 cobble together 2 pieces of code that worked independently, but
 bomb miserably whend put together.

 From the SunOS manual I took the example where they create an agent
 thread to watch for SIGIO on the stdin file descriptor.  In place
 of the stdin descriptor, I've substitued a tli endpoint, again using
 an example from Sun for opening a server tli endpoint.  I wanted
 to see if the lwp agent would report the SIGIO event when a connection
 request arrives on the endpoint.
 
 The problem is that the t_open() call fails with the following messages:
 
   malloc(0)...core file created
   rcvtli: t_open failed: Invalid argument
 
 I can only guess that underneath the t_open call, buffers are being
 dynamically allocated and that somehow using lwp conflicts w/ the 
 memory allocation.  I get similar behavior when I try t_open in main
 before any lwp functions are called.
 
 Any lwp gurus out there who can help?
 
 Regards,
 
 -David
 
 
 /*********** long and messy code example *******/
 #include <errno.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <errno.h>
 #include <sys/types.h>
 #include <sys/uio.h>
 #include <unistd.h>
 #include <sys/socket.h>
 #include <netinet/in.h>
 #include <netdb.h>
 #include <tiuser.h>
 
 #define TRUE 1
 #define MAXPRIO 10
 #define MAXBUF 1024
 
 main()
 {
 
   int sigioCatch();
   int tliCatch();
   int counter;
   thread_t tid;
 
   (void)pod_setmaxpri(MAXPRIO);
   lwp_setstkcache(3000, 3);
   lwp_create(&tid, tliCatch, MAXPRIO, 0, lwp_newstk(), 0);
   lwp_libcset(tid);
   lwp_setpri(SELF, MINPRIO);
 
   counter = 0;
   while(1) {
      sleep(10);
      printf("counter = %d\n", counter);
      ++counter;
   }
 
 }
 
 
 
 int tliCatch()
 {
  	extern int t_errno;
   	eventinfo_t agtmemory;
   	thread_t sender;
  	char *arg;
   	int asz;
 	int sd, rd, cc, flags;
 	int port;
 	struct sockaddr_in sock;
 	char buf[MAXBUF];
 	struct t_bind binds;
 	register struct t_bind *bind = &binds;
 	struct t_call scalls;
 	register struct t_call *scall = &scalls;
         int status1;
         int status2;
 
   	printf("tliCatch()\n");
 
 	if ((sd = t_open ("/dev/tcp", O_RDWR, NULL)) < 0) {
 		perror ("rcvtli: t_open failed");
 		exit (1);
 	}
 
 	sock.sin_family = AF_INET;
 	sock.sin_addr.s_addr = INADDR_ANY;
 
 	for (port = IPPORT_RESERVED;; port++) {
 		sock.sin_port = htons ((u_short) port);
 
 		bzero ((char *) bind, sizeof *bind);
 		bind -> addr.buf = (char *) &sock;
 		bind -> addr.len = sizeof sock;
 		bind -> qlen = 1;
 
 		if (t_bind (sd, bind, (struct t_bind *) 0) != -1) 
 			break;
 
 		switch (t_errno) {
 		    case TNOADDR:
 			continue;
 
 		    default:
 			t_close (sd);
 			perror ("rcvtli: couldn't bind");
 			fprintf (stderr, "port = %d\n", port);
 			exit (1);
 		}
 	}
 
 
 	printf ("rcvtli: port number is %d\n", ntohs (sock.sin_port));
 
         fcntl(sd, F_SETFL, O_RDWR|FASYNC|FNDELAY);
 
   	agt_create(&sender, SIGIO, (caddr_t) &agtmemory);
 
         status1 = msg_recv(&sender, &arg, &asz, 0, 0, INFINITY);
         status2 = msg_reply(sender);
         printf("\tsigio caught?, status = (%d, %d)\n", status1, status2);
 
 	bzero ((char *) scall, sizeof *scall);
 	scall -> addr.buf = (char *) &sock;
 	scall -> addr.len = scall -> addr.maxlen = sizeof sock;
 	bzero ((char *) &sock, sizeof sock);
 
 
 	if (t_listen (sd, scall) == -1) {
 		perror ("rcvtli: couldn't bind");
 		exit (1);
 	}
 	
 	if ((rd = t_open ("/dev/tcp", O_RDWR, NULL)) == -1) {
 		perror ("rcvtli: t_open failed");
 		(void) t_snddis (sd, scall);
 		exit (1);
 	}
 
 	if (t_bind (rd, NULL, NULL) == -1) {
 		perror ("rcvtli: t_bind failed");
 		(void) t_close (rd);
 		(void) t_snddis (sd, scall);
 		exit (1);
 	}
 
 	if (t_accept (sd, rd, scall) == -1) {
 		perror ("rcvtli: t_accept failed");
 		(void) t_close (rd);
 		(void) t_snddis (sd, scall);
 		exit (1);
 	}
 	else do {
 		bzero (buf, sizeof buf);
 		if ((cc = t_rcv (rd, buf, MAXBUF, &flags)) < 0) {
 			if (t_errno == TLOOK) {
 				if (t_look (rd) == T_ORDREL) {
 					if (t_rcvrel (rd) == -1)
 						perror ("rcvtli: t_rcvrel failed");
 				}
 			}
 			else {
 				perror ("rcvtli: t_rcv failed");
 				fprintf (stderr, "rcvtli: t_errno = %d, errno = %d\n",
 t_errno, errno);
 			}
 break;
 		}
 
 		if (cc == 0)
 			printf ("rcvtli: terminating connection\n");	
 		else {
 			printf ("#");
 			fflush (stdout);
 		}
 	} while (cc != 0);
 
 	(void) t_close (rd);
 	(void) t_close (sd);
 	exit (0);
 
 
 
 }
 
 





-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Aug 1993 21:50:00 +0000
From:      kevq@banana.demon.co.uk (Kevin Quinn)
To:        comp.protocols.tcp-ip
Subject:   Where to get VT-100 source code in public dom

The official documentation is the DEC stuff:
 
                            Digital Equipment Corporation
                                    PO Box CS2008
                                  Nashua, NH  03061
                          VT100 : Part No. EK-VT100-UG-003
                          VT102 : Part No. EK-VT102-UG-002
                                    (800)258-1710
 
Lifted from the PC-VT documentation, which contains very detailed lists of
VT codes etc - mail me if you can't find it (I can send you the docs
immediately), but it is available on any of the large ftp sites.  It comes
with all sources etc, but they are copyright, but are probably still worth
perusal.
 
 
Kevin Quinn
 
kevq@banana.demon.co.uk, kevq@cix.compulink.co.uk


-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 01:59:01 GMT
From:      sterling@netcom.com (Bruce Sterling Woodcock)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4,comp.unix.pc-clone.32bit
Subject:   SLIP for SVR4 (again)

I know this has been asked here before, but I now have a similar problem.
A friend of mine has an SVR4 system that didn't come with slip (I'm glad
I got Dell), so we're looking for a PD package for it.  Unfortunately, the
package I could find on dell1.dell.com doesn't work (kernel panic), and
the other versions I have found seem to be SunOS only.  Can anyone point me
towards available SLIP packages that are known to work for SVR4?

Bruce

-- 
Bruce Sterling Woodcock                 Internet:  sterling@oldcolo.com
Systems Programmer                      Alternate:  sterling@netcom.com
Old Colorado City Communications        "Global Access From Any Micro"

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 93 03:28:06 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.lang.c++,comp.unix.solaris,comp.protocols.tcp-ip,comp.unix.internals,comp.client-server,comp.unix.osf.misc
Subject:   Object-Oriented Network Programming tools now available

Hi,

	The first generally announced release of the ADAPTIVE
Communication Environment (ACE) C++ IPC wrappers are now available for
anonymous ftp from ics.uci.edu (128.195.1.1) in the ftp/gnu directory:

% ls -lt ~ftp/gnu
total 2648
-rwxr-xr-x  1 gnu       1111871 Aug 16 20:13 ACE_wrappers.tar.2.8.Z

The contents of this release encapsulate the following user-level BSD
and System V Release 4 (SVR4) IPC facilities via type-secure,
object-oriented C++ interfaces:

	o Internet and UNIX-domain sockets (including broadcasting)
	o I/O multiplexing via select and poll
	o named pipes (FIFOs) and STREAM pipes (plus connld)
	o the mmap family of memory-mapping APIs
	o System V IPC (i.e., shared memory, semaphores, message queues)
	o SVR4 explicit dynamic linking facilities (i.e., dlopen/dlsym/dlclose)

	The release contains complete source code, documentation, and
example test drivers for the C++ wrapper libraries developed as part
of the ADAPTIVE project at the University of Calfornia, Irvine.  The
current release has been tested fairly extensively on Sun workstations
running Sun OS 4.1.2 and Solaris 2.2.  I expect that most of the
release will port easily to other platforms.

	Several of the wrappers have been described in issues of the
C++ Report and in the proceedings of the 1993 C++ World conference
held in Dallas, Texas in October.  Postscript versions of the most
relevant papers are included in the release.  I've also included a
comprehensive bibliography of other related work the describes the ACE
wrappers and the ADAPTIVE system in more detail

	Please refer to the INSTALL file for information on how to
build and test the ACE wrappers.  Due to the large size of the release
(> 1 Meg) I'm sorry that I will be unable to distribute the ACE
wrappers via email.

	I welcome all comments, bug fixes, and suggestions for improvement.

	Thanks,

		Douglas C. Schmidt
--
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 93 13:47:11
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Re: Stupid TCP/keepalive question

In article <CBwuFE.ICH@world.std.com> smayo@world.std.com (Scott A Mayo) writes:

   >The unix box had no clue that the connection is useless,
   >which is a problem in this implementation. Aha, I
   >thought, this is what they invented setsockopt for.
   >On the server, as soon as the socket handle is generated,
   >I treat it to a setsockopt(h, SOL_SOCKET, SO_KEEPALIVE,
   >&v, sizeof(v)) where v is an int set to 1. It returns
   >a zero.

Your question isn't stupid at all.

I've run into oodles of problems with connection loss detection, and I've
become quite unhappy with the gyrations (i.e. kludges) I have to go through
to get things to work.  (I note that I'm on SunOS 4.1.3 - your mileage may
vary depending on your particular vehicle, but it may be similar!)

In my particular case, I have a UIUC "qi" server which operates with an
inactivity timeout.  This is fine and desirable for most clients.
However, with an X client, it is reasonable to insure that a connection
is up whenever the user wants it.  Given the design of xph, it's not
reasonable to reconnect on each query - there are cases where it's
important to maintain state (such as when someone is logged in and
changing their database entry).  So what I wanted to do was to
automatically detect a server disconnect and automatically reconnect.  I
thought it'd be easy.  Just catch the SIGPIPE on the next write,
reconnect and retry...

Not.

What I found out was that after the server goes away, I don't get the
SIGPIPE until the SECOND write.  In the intervening read(), sometimes
I get a read error with errno set to ECONNRESET and sometimes I get NO
error with 0 bytes read.  To handle all of this, I have to keep track of
a bunch of garbage I shouldn't have to, and retry queries downstream in
the process.

I've tried to figure out how to get things to work the way I want, and
have had zero luck.  The literature is useless on this particular
subject - yet it would seem there must be a way of coding an application
to do what I (and apparently others) want.  Rich Stevens' book covers a
great deal of ground and may be the most definitive book on many Un*x
networking issues (certainly has been a mainstay for me), but even he
only covers the subject of connection loss detection in passing.

Another possibility here is that SunOS 4.1.x is buggy WRT SIGPIPE
handling.

So... is there a RIGHT way to code a client application which needs to
know of a connection loss on the VERY NEXT i/o system call to a stream
socket following a server disconnect?  Or do I need to call Sun?  Or am
I out of luck?

Regards,

Rick

===========================================================================
Rick McCarty           P.O. Box 149149, MS 2227/Austin, Texas  78714-9149
Texas Instruments/ITG  mccarty@add.itg.ti.com/(512) 250-4108/250-4509 (Fax)
===========================================================================


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 93 14:38:05
From:      pott@gun.neuroinformatik.ruhr-uni-bochum.de (Ruediger Pott)
To:        comp.protocols.tcp-ip
Subject:   Can I avoid datagram fragmentation?

 Hi all,

we are using some Linux boxes in our network. Networking works like a
flame as long as we stay on our local network. 
Connecting to the outside world we get fragmented datagrams which
isn't yet implemented in Linux, which takes a lot of fun out of this
Linux-game.

Does one of the tcp-ip gurus know a way to tell other hosts that we
don't like fragmanted datagrams?

Thanks, Ruediger

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 10:21:49 GMT
From:      M.T.Shipley@bradford.ac.uk (MT SHIPLEY)
To:        comp.protocols.tcp-ip,comp.terminals
Subject:   Re: Where to get VT-100 source code in public domain?

Jerry Lahti (jel@xerver.icl.fi) wrote:
: westes@netcom.com (Will Estes) writes:
 
: >I need to write a simple VT-100 emulator as part of a commercial
: >product.  Where does one find the specifications for VT-100, and is
: >there any code in the public domain for this emulation that can be
: >used as either a reference or actually copied into a commercial
: >product?
 
: Presumably Digital will sell you the appropriate reference manuals.

If you want a specific terminal reference manual (eg VT100, VT200, VT300,
VT400 series etc) then no problem.

If you want the DEC standard for such things, as a generic standard, then
I believe what you need is "DEC STANDARD 70" (number 70 I guess), but I
think this is company confidential, and have never managed to get hold
of a copy.

If anyone knows any difference, then mail me/here


: MS-Kermit sources might serve as a reference, although the display
: emulation is unfortunately :-) already at the VT-320 level. However,
: I have not looked closely enough at the copyrights to know, if the
: code could be directly incorporated into a commercial product.

Also, have a look at the replacement MS-DOS ANSI drivers (location in
another message with VT100 in the title, I think, in this group in the
last two weeks), and at the Xterm s/w.
I don't know what the Legal situation is, but I think the first of
these may be Shareware, so may require payment or maybe you are NOT
allowed to look at it and use things for it in your product.  Suggest you
check first.


Martin

: /Jerry Lahti
 
: -- 
: Jerry Lahti             !  tel. +358-0-567 3639
: ICL Personal Systems Oy !  fax. +358-0-567 5670
: P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
: 00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1993 12:04:15 GMT
From:      mcrowley@mtholyoke.edu (Michael A. Crowley)
To:        comp.protocols.tcp-ip,comp.terminals
Subject:   Re: Where to get VT-100 source code in public domain?

Joe Doupnik (jrd@cc.usu.edu) wrote:
> ------------------
> 	Here's the copyright notice from MS-DOS Kermit:
 
> ;  Copyright (C) 1985, 1993, Trustees of Columbia University in the 
> ;  City of New York.  Permission is granted to any individual or institution
> ;  to use this software as long as it is not sold for profit.  This copyright
> ;  notice must be retained.  This software may not be included in commercial
> ;  products without written permission of Columbia University.
 
> 	So no, one can't use the material for commercial products. The ref for
> DEC VT100's is from Digital themselves (that's by far the best ref too).
>         Joe D.

It doesn't say you can't use it in a commercial product; it says you must
obtain written permission to do so.  Some years ago there was a stipulation
about including kermit.exe with commercial products such that one could not
increase the cost of the product because kermit was there.  This may still
be their intent.

But anyway, back to the topic of the thread, if you want to see some basic
VT100 coding, you might check hytelnet (ftp access.usask.ca, among others).

-mike

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 93 13:52:25 GMT
From:      rfadler@uswnvg.com (Rick Fadler 206-450-8575)
To:        comp.protocols.tcp-ip
Subject:   Good Network programming books

I just received the latest "New Book Bulletin" from Computer
Literacy Bookshops and noticed two books on SVR4 network
programming I haven't seen before.  They are:

UNIX System V Network Programming, Stephen A. Rago and

Networking Applications on UNIX System V Release 4, Michael
Padovano.

Does anyone have an opinion on either book?  

Thanks

Rick Fadler
206-450-8575

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 93 14:26:44 GMT
From:      egan@cbs.cis.com (Egan F. Ford)
To:        comp.protocols.tcp-ip
Subject:   anonymous ftp, how?

I'd like to set up an anonymous ftp site, but how do I do this?  Is there a FAQ or
other detailed document explaining this?

E-mail please.

Thanks.


-- 
Egan F. Ford
egan@cbs.cis.com

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 14:41:31 GMT
From:      waynej@ncs.com (Wayne Johnson)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.unix.aix
Subject:   Q using cisco slip

I am trying to set up an internet interface for my group.  It involved 
connecting our Livingston Portmaster modem server, which supports a slip
mode, to a cisco server at the U of MN.

The problem I seem to be getting is that the cisco is assuming we have an
internet address of 134.85.101.42 thru 134.85.101.56 depending on what phone
port we get in on.  

By using the help command on the cisco I see that there is a address 
specification on the slip command.  Does this allow be to define the ip address
for my end of the link?  It does not seem to work if I try it.  Is there some
magical incantation I need to do first?  Is there a way to override the ip 
address that the cisco will give me?

The folks at Mr.Net suggested that we do a bootp request to find out what
the address is that the cisco expects us to be.  This would be fine if we had
any software that does a bootp REQUEST (Our AIX systems already have bootpd).

I don't think this will help much since I beleive our portmaster requires us
to use a single ip address (159.182.42.15).

The folks at Livingston are too busy at this point to do any research on
using the cisco for us.  Anyone have a cisco slip server users manual they
can email me?

Thanks for any help you can give.
-- 
Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
     National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
                                           - Jim Elliott

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 93 15:04:15 GMT
From:      immi@chevron.com (Ian Miller)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Racal INterlan: drivers for ni5210???

In article <248l1u$hjs@afya.acs.uwosh.edu>, bataller@afya.acs.uwosh.edu (Erik M. Bataller) says:
>
>Hello All,
>        Does anyone know where the latest and greatest drivers for 
>Racal Interland NI5210 card are?  I am interested in both packet
>drivers and ODI drivers.   
>
>
>THanks 
>
>
>Erik
>
>
>-- 
>!!  Erik M. Bataller | Phone: (414) 424-0347 | Univ. of Wi., Oshkosh 
>!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
>!!  Oshkosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
>!!  Bitnet: Bataller@oshkoshw.bitnet

Have you tried the Racal BBS?  They will have the latest greatest drivers for 
the 5210 card.  The BBS number is (508) 264-4345 with the normal settings
(2400 baud, 8 data bits, 1 stop bit & no parity).  Racal might even have an anonymous
ftp site but I don't know what it is.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 15:45:13 GMT
From:      smayo@world.std.com (Scott A Mayo)
To:        comp.protocols.tcp-ip
Subject:   Stupid TCP/keepalive question

Apologies if this is not quite the right newsgroup for this
question, redirect me if it isn't.

I am writing a client/server set. The servers runs on
various unix boxes, and use socket() calls to set up
TCP connections. The clients runs on all sorts of things,
including unix, MS Windows, and worse. The case in hand
is a server on one of several vendors platforms (Unisys,
Univel, SCO) and a client in MS Windows using Novell for
its TCP connections, though that's not relevant.

My server and client start up and get connected, and
exchange a few pleasentries over the connection, which
works just fine. Then the client goes off into wait-for-
the-user mode and the server sits it a select() in 
wait-for-the-clients mode.

At this point the user does what users of PCs enjoy doing
most - he powers off his PC and goes away. Without
shutting down Windows or his connections, of course.

The unix box had no clue that the connection is useless,
which is a problem in this implementation. Aha, I
thought, this is what they invented setsockopt for.
On the server, as soon as the socket handle is generated,
I treat it to a setsockopt(h, SOL_SOCKET, SO_KEEPALIVE,
&v, sizeof(v)) where v is an int set to 1. It returns
a zero.

As I understood it, this means the unix TCP implementation
would query the client on occasion, and if it stopped getting
answers I should see my select() wake up with a broken pipe
situation (the read mask should show activity and when I go
to read I should get some sort of error.)

This isn't happening. I'm sitting watching the unix server
being blissfully unaware that I turned off the PC 15 minutes
ago.

Do I need to configure something else to make this work?

Ironically, if I power up the PC again and reconnect to the
server, the new connection works just fine. Since the
clients self-identify when they connect, my servers are able
to figure out that an old session silently evaporated, and
can put things back together again. But until and unless that
happens, it looks as if the server will keep the old connection
(and the baggage I associate with them) forever.

There is a related problem. If the server decides to exit in
this situation, FIN_WAIT_2 states abound, and they stick
around for a long, long time - which means I can't restart
the server. Is there some utility I can run or write which will
unhook things?? I need to get the server back up after a crash
within 3 seconds. I've seen FIN_WAIT_2 stick around for many
minutes.

Any help would be appreciated. There must be a simple solution
that I'm missing, and I *REALLY* need to know what it is. If
the answer is so trivial as to be embarrassing and you don't
want to hold me up to public scorn and ridicule, mail is
fine.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 16:02:45 GMT
From:      smayo@world.std.com (Scott A Mayo)
To:        comp.protocols.tcp-ip
Subject:   2 hours?!

I've just heard that turning on keepalives on sockets
only queries quiet ports every 2 hours. 2 hours?
I was hoping for every twenty seconds...

Is there some way to tune this value on my unix
boxes? If I establish a connection to a PC, and
then someone turns the PC off mid-dialogue, I'd
really like to see a broken pipe within a few
seconds. Several hours are no good to me. This
*is* tunable... isn't it? I am using SCO, Unisys
and Univel platforms (and others someday soon.)
Thanks for any help...

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 16:28:46 GMT
From:      jcp@logjam (John C. Peterson)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for SVR4 (again)


In article <sterlingCBvs6E.Cnu@netcom.com> sterling@netcom.com (Bruce Sterling Woodcock) writes:
>I know this has been asked here before, but I now have a similar problem.
>A friend of mine has an SVR4 system that didn't come with slip (I'm glad
>I got Dell), so we're looking for a PD package for it.  Unfortunately, the
>package I could find on dell1.dell.com doesn't work (kernel panic), and

   If I recall correctly, that version of SLIP is the one written by Roe
Peterson at Unibase Telecom. You could check that by fetching his from 
udevdiv.unibase.sk.ca!/sources, and comparing them. At any rate, I beleive
you also need to install SAS to use that one. (available from same site).
In general I suspect installing SAS would be a good idea regardless which
SLIP you end up using.

>the other versions I have found seem to be SunOS only.  Can anyone point me
>towards available SLIP packages that are known to work for SVR4?

  Also check out ftp.uu.net!/networking/ip/slip/svr4

-- 
John C. Peterson  KD6EKQ       | + 1 619 546 6539 | Disclaimer: The opinions
Science Applications Intl Corp | jcp@trg.saic.com | expressed are mine alone,
10260 Campus Point Drive MS-C6 |                  | and do not reflect those
San Diego, CA 92121            |                  | of SAIC.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 16:36:01 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I avoid datagram fragmentation?

In <POTT.93Aug17143805@gun.neuroinformatik.ruhr-uni-bochum.de> pott@gun.neuroinformatik.ruhr-uni-bochum.de (Ruediger Pott) writes:

+> Hi all,

+>we are using some Linux boxes in our network. Networking works like a
+>flame as long as we stay on our local network. 
+>Connecting to the outside world we get fragmented datagrams which
+>isn't yet implemented in Linux, which takes a lot of fun out of this
+>Linux-game.

+>Does one of the tcp-ip gurus know a way to tell other hosts that we
+>don't like fragmanted datagrams?

	What you have to do is set the TCP MSS to something really 
low (around 500 bytes) if tcp is sending outside the local network.
If Linux does not send tcp MSS options on connection establishment, it
should.
	If you want to get fancy, there is an RFC (1191) that specifies
path MTU discovery for non-local nets.  Putting that into Linux is
not going to be trivial though.
	




-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 18:18:18 GMT
From:      StefansT@rimail.interlan.com (Tom Stefanski)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Racal INterlan: drivers for ni5210???

In article <1993Aug17.150415.24189@nntpserver.calgary.chevron.com> immi@chevron.com (Ian Miller) writes:
>
>Have you tried the Racal BBS?  They will have the latest greatest drivers for 
>the 5210 card.  The BBS number is (508) 264-4345 with the normal settings
>(2400 baud, 8 data bits, 1 stop bit & no parity).  Racal might even have an anonymous
>ftp site but I don't know what it is.

	Racal-Interlan's Anonynous Ftp Server IP address is 130.204.8.16

							Tom Stefanski

***********************************************************************
*   Tom Stefanski                     *    Internet: tom@interlan.com *
*                                     *    Compuserve:  75470,1732    *
*   Interlan->Micom-Interlan->Interlan->Racal-Interlan->Racal-Datacom *
***********************************************************************

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 18:23:48 +0000
From:      thanatos@drealm.demon.co.uk ("Peter L. Jones")
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for SVR4 (again)

In article <sterlingCBvs6E.Cnu@netcom.com> sterling@netcom.com writes:

>I know this has been asked here before, but I now have a similar problem.
>A friend of mine has an SVR4 system that didn't come with slip (I'm glad
>I got Dell), so we're looking for a PD package for it.  Unfortunately, the
>package I could find on dell1.dell.com doesn't work (kernel panic), and
>the other versions I have found seem to be SunOS only.  Can anyone point me
>towards available SLIP packages that are known to work for SVR4?
>
>Bruce
>
>-- 
>Bruce Sterling Woodcock                 Internet:  sterling@oldcolo.com
>Systems Programmer                      Alternate:  sterling@netcom.com
>Old Colorado City Communications        "Global Access From Any Micro"
>

There is kernel bug in SVR4.0 before version 3.0 and SVR4.2 version 1 
which cause the (intel pd) SLIP STREAMS code to kernel panic.  The 
release of SLIP we got came with a fix (to ip/Driver.o).  It's on many 
ftp servers (something like sysvr4slip).  Also, we have been sent a 
fix for SVR4.2 - but we're not available by ftp.  If you e-mail us, 
we'll try and sort something out.

-- 
Peter L. Jones

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 19:24:13 GMT
From:      jim@kn5f.jsc.nasa.gov
To:        comp.protocols.tcp-ip
Subject:   rsh and rcp

I'm looking for the RFC numbers for rsh (remote shell) and rcp (remote copy),
if they exist. I'm also looking for the source code for these applications. Any
assistance is appreciated. 

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1993 20:01:08 GMT
From:      vijay@hicomb.hi.com (Systems Administrator)
To:        comp.protocols.tcp-ip
Subject:   Ethernet to IP Address translation

Does anybody know of a tool which can find out the IP address of
a host given its ethernet address (RARP) ? 

Thanks in advance.

Vijay



-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1993 21:49:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing table & machine types

In article <24o86o$3vf@oak29.doc.ic.ac.uk> cmft@doc.ic.ac.uk (C M F Tsang) writes:
>1. 	If the gateway uses ARP & RIP to find out physical addresses
>and routing infos of its connections, and if the gateway is not up very
>long, is there a possiblity that the routing table will not contain all the connections ? If that's the case then my algorithm will not work because 
>it relies on the routing table (ipRoutingTable).  Anyone got a better idea?

Since routers using RIP broadcast their routing tables every 30 seconds,
any particular router in an AS should have a complete routing table within
a minute of coming online.  If you start querying earlier than that you
won't get a complete picture of the net.  But it will correspond to what is
actually accessible at the time of the snapshot, since the missing subnets
will correspond to locations that are inaccessible because the gateway
doesn't know how to get there yet.

>2.	In MIB II, the address translation group exists only for 
>compatiblitiy reasons( according to RFC1213 ), so can I use it still?
>i.e. would it be updated? Do I need to use the new objects ipNetToMediaTable?

Yes, the MIB-I variables must be correct.  There wouldn't be much point to
having them there if they didn't actually contain the right information,
would there?

>3.	Is there anyway to find out whether a connected machine is a host,
>a gateway or just a terminal ( including dumb and X-terminals ) by looking
>at a MIB object? I don't seem to find one except ipForwarding tells me the
>machine can route packets( presummably a gateway? )

Lots of hosts will forward packets, though.  I don't think the distinction
you make is represented in any standard protocol.  The difference between a
gateway, host, and terminal is purely conceptual, not an intrinsic property
of the device.  It would be like trying to determine whether a host is a
microcomputer, workstation, minicomputer, or mainframe.  Consider that a
modern X terminal is more powerful than the minicomputers of 5 years ago
(except that most X terminals don't have disks).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1993 21:54:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I avoid datagram fragmentation?

In article <POTT.93Aug17143805@gun.neuroinformatik.ruhr-uni-bochum.de> pott@gun.neuroinformatik.ruhr-uni-bochum.de (Ruediger Pott) writes:
>we are using some Linux boxes in our network. Networking works like a
>flame as long as we stay on our local network. 
>Connecting to the outside world we get fragmented datagrams which
>isn't yet implemented in Linux, which takes a lot of fun out of this
>Linux-game.

It isn't a real TCP/IP if it can't reassemble fragmented datagrams.

>Does one of the tcp-ip gurus know a way to tell other hosts that we
>don't like fragmanted datagrams?

There's no way to do this for UDP.  For TCP, though, the Max Segment Size
option can be used in a SYN packet to indicate the largest packet that
should be sent.  If you set this to 576 this should prevent fragmentation,
since all IP networks are supposed to be able to handle packets that big.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Aug 1993 22:03:51 GMT
From:      adam@franz.com (Adam T. Dingle)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Performance data for PPP/SLIP?

I'm interested in the performance of PPP and SLIP for file transfers.
That is, when I transfer a file (say, by FTP) over a PPP or SLIP line
and there is no other traffic on the line, what fraction of the
line's bandwidth might I expect would be effectively used in transfering
the file?  I have heard rumors that when running SLIP as little as
1/4 of the line's bandwidth might be effectively used.  I am aware
that the performance depends on the packet size used, and would hope
that on a fairly reliable line (such as an error-correcting modem)
I might be able to use a large packet size to achieve a much higher throughput.

I would appreciate any informal advice on the subject, or any pointers
to papers which might discuss the performance of PPP and/or SLIP.

Thanks much-

Adam Dingle
adam@franz.com


-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1993 09:44:53 -0700
From:      mcitron@hsc.usc.edu (Mark Citron)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   encapsulated SNA

We are trying to exchange data between our SCO system and our             
IBM mainframe. Specifically we need to use LU6.2 (which is an             
IBM SNA protocol). Can anyone tell me what the state of the art is        
for SNA encapsulated by TCP/IP? Our mainframe is already on TCP/IP.       
                                                                          
I know Rabbit Software does this LU6.2 via token ring. Just seemed like it
might be easier on ethernet since we are already using that.              
                                                                          
                                                                          
Thanks for any help or suggestions.                                       
Mark Citron                                                               
Childrens Hospital Los Angeles                                            

-- 
Mark Citron
mark@neurosci.usc.edu


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 01:01:47 GMT
From:      Andre.Henr801e@xerox.com
To:        comp.protocols.tcp-ip
Subject:   Re: Programming TCP/IP from Windows


In article <41129@oasys.dt.navy.mil>, <rkirk@oasys.dt.navy.mil> writes:
> Path: 
rocksanne!parc!biosci!uwm.edu!cs.utexas.edu!math.ohio-state.edu!darwin.sura.net
!dtix.dt.navy.mil!oasys!rkirk
> From: rkirk@oasys.dt.navy.mil (Randy Kirk)
> Newsgroups: comp.protocols.tcp-ip
> Subject: Programming TCP/IP from Windows
> Message-ID: <41129@oasys.dt.navy.mil>
> Date: 9 Aug 93 12:59:25 GMT
> Reply-To: rkirk@oasys.dt.navy.mil (Randy Kirk)
> Distribution: usa
> Organization: Carderock Division, NSWC, Bethesda, MD
> Lines: 12
> 
> 
> 	I am looking for a product that will allow me to write a program
> 	with TCP/IP  calls in it.  I need to do this in windows and 
> 	prefer Visual Basic/Visual C as programming language.  The program
> 	is to allow a PC to recieve and send short messages to another PC
> 	on the network.  Any suggestion for a programming tool would be 
> 	appreciated.
> 
> 
> 							Thanks
> 							Randy
> 							rkirk@oasys.dt.navy.mil
You could use Netmanage Chameleon. It is windows based and comes with a SDK 
that supports Visual Basic. Call them @ (408) 973-7171
	André

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 01:19:38 GMT
From:      asw2s@uvacs.cs.Virginia.EDU (Alex S. Waterman)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   literature on ip_output() usage?

All,
	I am attempting to use the SunOS 4.1.2 kernel interface to
IP using ip_{output/output}() for protocol tunneling.  The Sun manuals
give a brief overview of this interface, but include no examples or detailed
explanation of the parameters and their usage.  

Can anyone out there give me pointers to appropriate literature that
would cover this? 

Or does anyone know how to use this interface that wouldn't mind
explaining the usage?


Thanks in advance.

 - Alex Waterman
   Alex@virginia.edu

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 02:32:58 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Performance data for PPP/SLIP?

In article <1993Aug17.220351.3719@franz.com>, adam@franz.com (Adam T. Dingle) writes:
> I'm interested in the performance of PPP and SLIP for file transfers.
> That is, when I transfer a file (say, by FTP) over a PPP or SLIP line
> and there is no other traffic on the line, what fraction of the
> line's bandwidth might I expect would be effectively used in transfering
> the file?  I have heard rumors that when running SLIP as little as
> 1/4 of the line's bandwidth might be effectively used.  I am aware
> that the performance depends on the packet size used, and would hope
> that on a fairly reliable line (such as an error-correcting modem)
>I might be able to use a large packet size to achieve a much higher throughput.
> 
> I would appreciate any informal advice on the subject, or any pointers
> to papers which might discuss the performance of PPP and/or SLIP.


You don't need a paper on such a subject.  You can figure out the values
for yourself.  See the PPP, SLIP, and VJ Compression RFC's.


Unless your data consists entirely of 0333 and 0300 bytes, the overhead
on a SLIP link is about 1 byte/higher level packet.  Even if your data
is so pathological, causing every byte to be "escaped," the overhead is
only about 50%.

On a PPP link, the overhead is about 2 bytes/ higher level packet, with
different pathological byte values.

Per user-level glob of data (e.g. payload of a TCP segment), the
overhead on a SLIP link using VJ compression is about 5 bytes, and
about 6 bytes on a PPP link.

If the globs of user data are reasonable size, and no one says anything
less than 256 is reasonable, the overhead is less around 5%.

Retransmissions caused by error on the modem line or overruns between
the modems and the computers increase the overhead, but both kinds of
errors should practically never happen with modern modems.  (A modern
modem is a v.32bis/v.42/v.42bis 14.4Kbit/sec error correcting modem.
Reasonable models can by bought for less than $250 and the best ones
for less than $425)

I prefer to run with an MTU (packet size) of 1500, which reduces the
overhead to less than 1% for file transfers.  I've done about 30MByte
since this morning on a PPP/v.32bis/v.42/v.42bis line, mostly with the
MTU reduced to ~400.

That is a far cry from 75% overhead ("1/4 othe line's bandwidth).


Vernon Schryver,  vjs@sgi.com

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 93 03:27:32 GMT
From:      edhall@rand.org (Ed Hall)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Performance data for PPP/SLIP?

In article <1993Aug17.220351.3719@franz.com>, adam@franz.com (Adam T. Dingle) writes:
> I'm interested in the performance of PPP and SLIP for file transfers.
> That is, when I transfer a file (say, by FTP) over a PPP or SLIP line
> and there is no other traffic on the line, what fraction of the
> line's bandwidth might I expect would be effectively used in transfering
> the file?  I have heard rumors that when running SLIP as little as
> 1/4 of the line's bandwidth might be effectively used.  I am aware
> that the performance depends on the packet size used, and would hope
> that on a fairly reliable line (such as an error-correcting modem)
> I might be able to use a large packet size to achieve a much higher
> throughput.

I generally get upwards of 1600bps using large files of random data and
rcp or ftp.  This is over a PPP link using V.32bis modems (vintage 1992
USR Couriers to be exact), and a default MTU of 1500 octets [bytes],
between a Sun and an Intel box (both running Unix).  Text files move
faster, proportional to the degree of V.42bis compresssion. (At least
with this model USR Courier, V.42bis doesn't seem to increase latency,
which is about 140ms round-trip.)

I'd probably do a little better with ZMODEM (perhaps 2 or 3%), but it's
real hard to run X and other TCP-based applications over ZMODEM.  :-)

If you are only getting 1/4th the available bandwidth with SLIP or PPP,
things are /not/ working properly; I think you can ignore those rumors.

		-Ed Hall
		edhall@rand.org

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 05:00:06 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Performance data for PPP/SLIP?

In article <1993Aug17.220351.3719@franz.com> adam@franz.com (Adam T. Dingle) writes:
   I'm interested in the performance of PPP and SLIP for file
   transfers... what fraction of the line's bandwidth might I expect
   would be effectively used in transfering the file?

Mr. Schryver already gave you an analytical answer, and both he and
Mr. Hall gave you some actual numbers.  Here are some more numbers,
from a slightly different measurement technique that may be useful to
you in your situation:

Running PPP on a null-modem cable between a SPARCstation-1 and a
Sun-4/110, connecting the native serial ports at 38400, FTP reported
3.7-3.8 Kbytes/sec.  Over a pair of V.32bis/V.42/V.42bis modems with
DTEs running at 38400, FTP reports a little over 2Kbytes/sec for
binary data (/vmunix) or a little over 3Kbytes/sec for text data
(/usr/dict/words).  Your numbers will vary with the compressibility of
your data.

   I would appreciate any informal advice on the subject, or any
   pointers to papers which might discuss the performance of PPP
   and/or SLIP.

I discussed the comparison, and gave some rough numbers in a footnote,
in ftp.morningstar.com:pub/papers/sug91-cheapIP*.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1993 12:06:33 -0400
From:      John Ioannidis <ji@cs.columbia.edu>
To:        comp.protocols.tcp-ip
Subject:   JI's thesis "Protocols for Mobile Internetworking" available

I finally got around to it and put my PhD up for
anonymous FTP. It is available from cs.columbia.edu:/pub/ji/.

thesis-[12]of2.ps.Z is the thesis formatted for single-sided printing,
and thesis-ds-[12]of2.ps.Z is the double-sided version. Unfortunately,
the embedded framemaker pictures will only print properly on an HP
LaserJet IIIsi (that's one of the reasons why I'd been delaying making
it available; I was hoping to find some time to redo the pictures). 

Here is the abstract:

    We consider the problem of Mobile Internetworking, that is,
    providing network access to hosts whose physical location changes
    with time.  Such hosts cannot depend on traditional forms of
    network connectivity and routing, because their location, and
    hence the route to reach them, cannot be immediately deduced from
    their network address.

    The three major points of the thesis, which are a departure from
    previous approaches, are:

      * Mobility is a network-layer problem, and is best attacked by
        embedding virtual mobile networks at the proper hierarchical
        address level.

      * Locality in host mobility, can be taken advantage of in order
        to yield efficient and practical tracking and routing
        mechanisms.

      * On-demand acquisition of mobile host location information,
        which is essentially routing information, yields a system that
        scales linearly as a function of its size.

    This dissertation shows the design, implementation and evaluation
    of IP-based protocols for mobile internetworking. The protocols
    operate mostly at the data-link and network layers, and seamlessly
    integrate mobile hosts into the current networking infrastructure.
    While it may be desirable to completely redesign networking
    protocols to support mobile systems, this would require changes to
    both the thousands of routers and the hundreds of thousands of
    hosts. This is widely viewed as being impractical, thus the thesis
    presents a method which requires no changes to routers or
    non-mobile hosts.

    The key feature is the use of ancillary routers, called Mobile
    Support Routers (MSRs), to track the location of the Mobile Hosts
    (MHs) and provide them with network access. Using a combination of
    caching, forwarding pointers, and timeouts, a minimal amount of
    state is kept in each MSR. There is no single point of failure,
    the state information is kept in a distributed fashion, the system
    scales well, and the overall network reacts quickly to changes.

The .bib entry for the thesis is:

@phdthesis{ji-thesis,
	author = "John Ioannidis",
	title = "{Protocols for Mobile Internetworking}",
	school = "Columbia University in the City of New York",
	year = 1993}

Enjoy,

/ji

--
In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 93 05:50:45 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: Good Network programming books

In article <7435@uswnvg.uswnvg.com> rfadler@uswnvg.com (Rick Fadler 206-450-8575) writes:
++ I just received the latest "New Book Bulletin" from Computer
++ Literacy Bookshops and noticed two books on SVR4 network
++ programming I haven't seen before.  They are:
++
++ UNIX System V Network Programming, Stephen A. Rago and
++
++ Networking Applications on UNIX System V Release 4, Michael
++ Padovano.
++
++ Does anyone have an opinion on either book?

I've read the Rago book cover-to-cover several times.  If you are
looking for in-depth coverage of general SVR4 kernel-level STREAMS
programming this book (particularly chapters 10-13) is extremely
valuable (basically, there is no other publically available literature
that covers the STREAMS topics with as many detailed, complete
examples).  The sections on the TLI API and the SVR4 network selection
and name-to-address translation also cover topics in much greater
detail that I've seen in other sources (e.g., Stevens UNP).

The chapter on RPC is somewhat incomplete (it must be difficult to get
inspired to write about SVR4 RPC with DCE and CORBA lurking around the
corner ;-)), but hopefully that will be spruced up in the next
edition.  Another interesting feature of the book is a fairly detailed
comparison between TLI and sockets in chapter 7.  I was disappointed,
however, that there was no justification or explanation for the
incredibly baroque semantics associated with t_listen, t_accept, and
t_look when the connection queue length is > 1 and multiple connection
requests arrive consecutively.  It has been my experience as a UNIX
network programming instructor that the gymnastics required to attain
socket-style behavior for concurrent servers is daunting enough that
most programmers would rather stick with sockets rather than wrestle
with TLI (fortunately, Rago does provide a set of library routines in
chapter 4 that do provide a relatively general solution to this
problem, however).

I've only glanced at the Padovano book briefly in the bookstore.  It
looks quite reasonable and well-written, though it does not appear to
cover the kernel-level STREAMS facilities in anywhere near the same
amount of depth.

	Doug
--
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1993 16:15:58 -0500
From:      pwickman@carroll2.cc.edu (Paul Wickman)
To:        comp.protocols.tcp-ip
Subject:   MINIMUM IP DATAGRAM SIZE


	Why is the minimum IP datagram size 576 bytes?

	
-- 
Paul J. Wickman - Network Analyst/Programmer - Harnischfeger Corporation
Internet: pwickman@carroll1.cc.edu	Phone: 414-671-7778

"Some people should die, that's just unconscious knowledge" - Jane's Addiction

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 08:38:10 GMT
From:      heitscgt@minnie.informatik.uni-stuttgart.de (Gerrit Heitsch)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP with ARCNet

This may be the wrong newsgroup, but I didn't find a better
one... 

I have a Longshine ARCNet card LCS-8830B, which I want
to use to connect a PC to an Amiga with A2060 ARCNet
card. Is there a free/shareware/PD TCP/IP software
for MSDOS available, that will work with the LCS-8830?

If yes, where?

According to the user's manual, it's a standard ARCNet
card and compatible to SMC and Pure Data ARCNet cards.

Please respond via email, because I don't read this group

Gerrit


-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 09:12:47 GMT
From:      ehab@ccs.northeastern.edu (Ehab Salem Al-Shaer)
To:        comp.protocols.tcp-ip
Subject:   Draft-rfc(s)

Hi every body,

I know how to get an RFC documnet from the existing FTP servers BUT
I don not know where I could find the DRAFT RFC(s) !?

Does any body know how/where I could find Draft RFC ?!

Thank you in advance.

-ehab



-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 93 23:08:54 -0600
From:      "Karl Finkemeyer" <p00122@psilink.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP over X.25 network?

What software packet driver can we use to encapsulate TCP/IP traffic
for transmission over an existing X.25 network?

We have:
 1) An existing client-server application using TCP/IP on an Ethernet-LAN
    with MS-Windows clients and Unix server.
 2) An existing X.25 network with 232 'remote' PCs running a dumb 
    terminal simulator (PTC) talking to an IBM 3090 mainframe.

We would like to make 1) available to the 232 remote locations through
the existing X.25 network by encapsulating the TCP/IP traffic. At the 
server site we will use several Eicon cards attached to a Novell server
(which is linked via Ethernet LAN to the Unix servers). 

We don't want to buy an Eicon card for every one of the 232 remote PCs,
so we are looking for a cheaper solution for getting the TCP/IP traffic
through the PC's serial port to the X.25 PAD.

I know very little about X.25, so it's not even clear to me if a regular
SLIP or PPP driver would already do the trick or not.

We are currently (on the LAN) using Wollongong's PATHWAY TCP/IP package,
but the remote PCs could conceivably run something else, as long as it
provides TCP/IP services to the PowerBuilder application - and connects
to the X.25 network through the PC's serial port.

Can anyone help - or at least explain to me how TCP/IP over X.25 is usually
done?

Karl Finkemeyer
p00122@psilink.com

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 13:17:17 GMT
From:      cslee@pds.nchu.edu.tw (Lee Chee Siong)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

In article <24ekuo$c14@wampyr.cc.uow.edu.au> mai@wampyr.cc.uow.edu.au (Van Dao Mai) writes:
>From: mai@wampyr.cc.uow.edu.au (Van Dao Mai)
>Subject: Can I have IPX and TCP/IP at the same time?
>Date: 13 Aug 1993 09:49:44 +1000
>
>Dear all,
>   Any one can show me how to build a DOS station with IPX and TCP/IP
>access at the same time? Windows for Workgroup would do but it does not
>allow PD software to run. I am talking about stuffs like NCSA telnet
>or gopher.
>   I know off ODI drivers, but cannot find documentation to set this
>stuff up. Also there are other drivers like ipxpkt from the net.
>Please help, reply by e-mail thanks.
>
>
  There is a program call PDIPX that can handle both TCPIP & IPX.



<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<>   CS Lee  (Lee Chee Siong  §õ§Ó²»)           <>  If you can give     <>
<>   System Manager of Computer Center          <>        nothing else, <>
<>   National Chung Hsing University,           <>                      <>
<>   Taichung, Taiwan, Republic of China.       <>  at least give a     <>
<>   Internet Address: cslee@pds.nchu.edu.tw    <>        cheerful face <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 13:46:07 GMT
From:      rbasket@cabell.vcu.edu (Robert E. Baskette)
To:        comp.protocols.tcp-ip
Subject:   Which Novell frame type to use


Hi,
  I would like to know the real difference between Novell's Ethernet
802.3 and ETHERNET_II frame types.  I need to pass one of these over
an AGS+.  I have clients that need to connect to a VAX as a telnet
client using Novell's LWP for DOS tcp/ip.  Which frame type should I
use and why?

               Thanks

Bob Baskette
Virginia Commonwealth University

rbasket@cabell.vcu.edu


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 13:49:15 GMT
From:      bobn@bobn.endicott.ibm.com (Bob Niedergerke)
To:        comp.protocols.tcp-ip
Subject:   Re: Draft-rfc(s)

In <1993Aug18.091247.9008@random.ccs.northeastern.edu>, ehab@ccs.northeastern.edu (Ehab Salem Al-Shaer) writes:
>I know how to get an RFC documnet from the existing FTP servers BUT
>I don not know where I could find the DRAFT RFC(s) !?
>
>Does any body know how/where I could find Draft RFC ?!

There are some "experimental" RFC's available from anonymous
ftp to nic.ddn.mil, if this is what you mean.  Look in the ietf
directory.

bobn
----------------------------------------------------------
Bob Niedergerke                          bobn@vnet.ibm.com
Integrated Systems Solutions Corp., Endicott Glendale Labs
Endicott, NY


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 93 14:36:12 GMT
From:      jeffa@comtch.computech.spk.wa.us (Jeff Albrecht)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   telnet failure under modem login


Hello,

I have an Interactive SVR3 Release 3.2 system, with tcp/ip 
of 1.3.0. If I'm logged in to the system locally (right 
there at the keyboard / monitor) I can telnet out to other 
hosts just fine, however if I log into the system via modem 
and then telnet out to the same hosts I get the login prompt 
from the remote host but I can't login as keystrokes don't 
appear. I can't seem to abort the session either. I can 
rlogin to other hosts when I'm on the system from modem. 
It's just when I call in on a modem and try to telnet out to 
another system that I get hung. Seems odd that I can rlogin 
to remote hosts successfully when connected to the 
originating system via modem but not via telnet.

My only thought on a possible cause to this problem would be 
some conflict in stty settings. That's just a guess.

Is anyone out there logging into Interactive SVR3 by modem 
and telneting out successfully?

-- 
Jeffrey H. Albrecht                jeffa@comtch.computech.spk.wa.us
Spokane, WA

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 15:06:34 GMT
From:      adh@alvin.ach.uams.edu (Alvis Harding Jr.)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   SLIP or CSLIP for Solaris 2.2 (Faster than 9600)

Does anyone know of a PD implementation of SLIP or CSLIP for Sun 
Solaris 2.2 that's faster than Sun's PC-NFS version of slip which
is limited to 9600 baud?  At least 19,200 (and CSLIP) would be preferred.
If no PD implementations exist, how about commercial?  Mucho gratitude
for any information.  


---                                                                         ---
----                                                                       ----
-----                                                                     -----
Alvis Harding Jr.                                  Arkansas Children's Hospital 
adh@george.ach.uams.edu                                  Cardiac Imaging Center 

"The nice thing about so many standards is that you can choose the one you
want"  --  Tanenbaum's Computer Networks


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 15:07:11 GMT
From:      hoang1@litwin.com (Ted Hoang)
To:        comp.protocols.tcp-ip
Subject:   UNIX System V Network Programming by Stephen A. Rago source code

Hi,

Could someone tell me how or where to get the source code of
UNIX System V Network Programming by Stephen A. Rago
(if it's available).

Thanks in advance,

Ted Hoang,
Email:hoang1@dynsim1.litwin.com



-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 15:27:46 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I avoid datagram fragmentation?

>>> On 17 Aug 1993 21:54:05 GMT, barmar@think.com (Barry Margolin) said:

Barry> In article
Barry> <POTT.93Aug17143805@gun.neuroinformatik.ruhr-uni-bochum.de>
Barry> pott@gun.neuroinformatik.ruhr-uni-bochum.de (Ruediger Pott)
Barry> writes:

Pott> we are using some Linux boxes in our network. Networking works
Pott> like a flame as long as we stay on our local network.  Connecting
Pott> to the outside world we get fragmented datagrams which isn't yet
Pott> implemented in Linux, which takes a lot of fun out of this
Pott> Linux-game.

Barry> It isn't a real TCP/IP if it can't reassemble fragmented
Barry> datagrams.

But the coming of the second NET is nigh! Very shortly Linux will
incorporate a full port of the NET-2 BSD code, and this should solve all
the problems with networking in older Linux releases (hopefully...).

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 93 17:00:39 GMT
From:      we44760@vub.ac.be (GRUWIER CHRIS)
To:        comp.protocols.tcp-ip
Subject:   File Transfer Protocol

Hi,

i am planning to write a ftp client supplied with a user interface.
I looked for some RFC's on the ftp protocol, but unfortunately i
didn't find them. Does anyone know how the protocol actually works,
or where i can find information about it? All help and information
is welcome.

Thanx in advance,

=====================================================================
Chris Gruwier                                     <we44760@vub.ac.be>
Brussels Free University
Dep. Computer Science                              
=====================================================================

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1993 17:02:01 GMT
From:      walt@unhsst.unh.edu (Walter R. Trachim)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Racal INterlan: drivers for ni5210???

In article <1993Aug17.150415.24189@nntpserver.calgary.chevron.com> immi@chevron.com (Ian Miller) writes:
>In article <248l1u$hjs@afya.acs.uwosh.edu>, bataller@afya.acs.uwosh.edu (Erik M. Bataller) says:
>>
>>        Does anyone know where the latest and greatest drivers for 
>>Racal Interland NI5210 card are?  I am interested in both packet
>>drivers and ODI drivers.   
>
>Have you tried the Racal BBS?  They will have the latest greatest drivers for 
>the 5210 card.  The BBS number is (508) 264-4345 with the normal settings
>(2400 baud, 8 data bits, 1 stop bit & no parity).  Racal might even have an anonymous
>ftp site but I don't know what it is.

They used to have an anonymous FTP server on interlan.com (130.204.8.1) - it
may not exist anymore, though. I'd suggest calling their Customer Support
department (1-800-LAN-TALK) to find out if it's still on line. Erik is right
about their BBS - they'd definitely have the right stuff on it somewhere....


Walt
(a former Racal-Datacom employee [1989])

-- 
    Walter R. Trachim                                   walt_trachim@unh.edu
    University of New Hampshire      Telecommunications and Network Services
    Durham, NH 03824               603-862-4742 (Voice) / 603-862-2030 (Fax)
    ########################################################################
    "Americans will do the right thing only when there are no other options."
						--Winston Churchill

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 17:12:07 GMT
From:      janzen@idacom.hp.com (Martin Janzen)
To:        comp.protocols.tcp-ip
Subject:   Re: Stupid TCP/keepalive question

In article <MCCARTY.93Aug17134711@aphid.add.itg.ti.com> mccarty@add.itg.ti.com (Rick McCarty) writes:
>[...]  So what I wanted to do was to
>automatically detect a server disconnect and automatically reconnect.  I
>thought it'd be easy.  Just catch the SIGPIPE on the next write,
>reconnect and retry...
>
>Not.
>
>What I found out was that after the server goes away, I don't get the
>SIGPIPE until the SECOND write.  In the intervening read(), sometimes
>I get a read error with errno set to ECONNRESET and sometimes I get NO
>error with 0 bytes read.  To handle all of this, I have to keep track of
>a bunch of garbage I shouldn't have to, and retry queries downstream in
>the process.

I've seen this "SIGPIPE on SECOND write attempt" behaviour as well,
on an RPC application I'm working on.  My ugly workaround was to do
something like this:

   CLIENT *        ch;
   enum clnt_stat  result;
   int             sock, err, errlen;
   extern int      errno;

   /* create a client connection, and find out which socket RPC is using */
   sock = RPC_ANYSOCK;
   ch = clnt_create(..., &sock, ...);

      ...

   /* try to write to the socket */
   result = clnt_call(ch, ...);
   err = 0;
   errlen = sizeof(err);
   if ((result != RPC_SUCCESS) ||
       ((getsockopt(sock, SOL_SOCKET, SO_ERROR, &err, &errlen) == 0) &&
        (err > 0)))
      /*
       * - on the first attempt to write to a closed socket, result is
       *   still RPC_SUCCESS, but err is set to ECONNRESET
       * - on the second attempt, result is != RPC_SUCCESS, SIGPIPE occurs,
       *   and errno (not err!) is set to EPIPE
       */

      ...



>Another possibility here is that SunOS 4.1.x is buggy WRT SIGPIPE
>handling.

I'm using HP-UX 8.07, and it does this too.

>So... is there a RIGHT way to code a client application which needs to
>know of a connection loss on the VERY NEXT i/o system call to a stream
>socket following a server disconnect?  Or do I need to call Sun?  Or am
>I out of luck?

Try the getsockopt(sock, SOL_SOCKET, SO_ERROR, ... ) call.  It's not
pretty, but I've found that it's better than nothing.  It'd sure be nice
if there were a better way, though...


-- 
Martin Janzen    janzen@idacom.hp.com
Pegasus Systems Group
Currently at:  HP/Idacom Telecommunications Division

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 19:22:02 GMT
From:      dsiegel@Seagull.RTD.COM (Dave Siegel)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, how?

> I'd like to set up an anonymous ftp site, but how do I do this?  Is there a FAQ or
> other detailed document explaining this?

You neglected to say which OS you plan to do this on.

On a unix machine, type 'man ftpd', and there should be a complete set of
detailed instructions on how to do it for *your* specific version of Unix.

If you'd like to set it up on a DOS machine (I can't imagine why you would,
but if you did) there are serveral shareware tcpip packages that come with
anonymous ftp built in.  WinQVT/net is one such package.  Commercial
packages include PC-NFS, and Beame & Whiteside TCPIP.

-dave

-- 
Dave Siegel   (DS4)             President, RTD Systems & Networking, Inc. 
   pager: (602)291-5655                 voice: (602)318-0696
     fax: (602)318-0695                 email: dsiegel@rtd.com
Consulting -- Support -- Software Development for Unix, Mac's, & Windows 3.1

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 02:15:32 -0400
From:      jayne@access.digex.net (Jayne Johnson)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Dial-up modems

I am looking for information as to how to use PPP with cu . I have 
a sparc which is connected to a modem which gives me access to the
internet. I am trying to find out a mechanism for using the link in
an efficient manner, since we only get a couple of hours on the link.
The dialup modem must be brought up and down. Currently this is a 
manual process.

Can anyone give me some pointers? Please?

Thanks in advance :-)
Jayne F. Johnson

Realtime System Solutions,Inc
Mclean,Va
email: jayne@acces.digex.net



-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 20:01:36 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: 2 hours?!

In article <CBwv8M.LD3@world.std.com> smayo@world.std.com (Scott A Mayo) writes:
>I've just heard that turning on keepalives on sockets
>only queries quiet ports every 2 hours. 2 hours?
>I was hoping for every twenty seconds...

If your application has a specific need for a given time out, then you
should build that into the implementation.  Hint: 20 seconds is *very*
low tolerance, so if that's really what you need, you've got a very
different TCP application on your hands.  The TCP keepalive timer isn't
quite doing what you want it to, anyway, so a specific facility to
handle your specific requirements would be a better solution.

In this particular case, though, i'm not sure why you really care
anyway.  When client comes back, from what you're saying the server
recognizes the new connection as a replacement for the old one.  Are
you sure those idle and apparently useless TCP connections are really
a problem in the interim?

The FIN-WAIT-2 problem has something to do with your specific
implementation, and i'm sure someone will be able to give you good
advice on that.  Generally, your TCP API should provide you a way to
abort the connection.  If you use that function instead of simply
closing the connection, the FIN-WAIT-2's shouldn't happen.

						don provan
						donp@novell.com

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1993 17:39:39 +0200
From:      taino@pippo.sm.dsi.unimi.it (Stefano Taino)
To:        comp.protocols.tcp-ip
Subject:   comp.protocols.tcp-ip ARCHIVE

I'd like to know if there is a ``ftp site'' with an archive of articles
posted in comp.protocols.tcp-ip newsgroup.

Regards,
Stefano.

---
#include "std/disclaimer.h"

#define	E-MAIL 		"taino@dsi.unimi.it"
#define ORGANIZATION 	"DSI - CS Department of Milan University - ITALY"
#define PHONE		"+39-2-27400728"
#define PUBLIC-KEY 	"finger(1) taino@ghost.dsi.unimi.it"

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1993 21:51:32 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: MINIMUM IP DATAGRAM SIZE

In article <24u66e$m3u@carroll2.cc.edu>,
Paul Wickman <pwickman@carroll2.cc.edu> wrote:
>	Why is the minimum IP datagram size 576 bytes?

The minimum is not 576 bytes.  The minimum maximum-datagram-size is 576
octets (bytes).  That is to say, if a host is going to set a maximum,
that maximum must be at least 576 octets.

Real-world maximum datagram sizes tend to be in the 8192 to 65536 byte
range, but some single-user implementations can't handle more than 1460
bytes.  Only a few are limited to 576 bytes.

I'm not aware of a minimum datagram length, so I'd guess it is 20
octets, which is enough for an IP header and nothing else.  The minimum
_useful_ datagram is obviously a little larger.

	Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 22:11:51 GMT
From:      injc@obelix.rz.tu-clausthal.de (Joerg Czeranski)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: cslip-2.6:  sliplogin[223]: I_PUSH: Not ow

Erik M. Bataller (bataller@afya.acs.uwosh.edu) wrote:
: I keep getting this messsage from cslip when I login:
: 
: 	Aug 11 18:29:03 afya sliplogin[14606]: I_PUSH: Not owner

It could mean, that sliplogin doesn't have root-permission.
'Not owner' is the error code commonly used for such a situation.

joerg

--
Joerg Czeranski                EMail czeranski@rz.tu-clausthal.de
Osteroeder Strasse 55          SMTP  injc@[139.174.2.10]
W-3392 Clausthal-Zellerfeld    Voice (at work)  +49-5323-72-3896
Germany                        Voice (at home)  +49-5323-78858

To obtain PGP public key, finger injc@sun.rz.tu-clausthal.de, or email me.

At any given site for any given application or feature, there's someone
who knows more about it than the support staff.  Finding that person is
the first step to take to diagnose any given problem.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Aug 1993 23:00:51 GMT
From:      jobson@pbj.sybase.com (Christopher Jobson)
To:        comp.protocols.tcp-ip
Subject:   Re: Stupid TCP/keepalive question

You will probably find that the keepalive test doesn't kick in until somewhere
around 2 hours have expired ... It depends on the o/s, and how the o/s is
configured. Some systems allow you to set it to any value you want ...

-- 

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

 Chris Jobson                                    Email:       jobson@sybase.com
 Sybase Europe B.V.,
 Sybase House,                                   Voice:       +44-(0)628-597263
 Bell Street, Maidenhead,                        Switchboard: +44-(0)628-597100
 Berkshire.   SL6 1XW                            Fax:         +44-(0)628-28844
 United Kingdom.


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 00:07:43 GMT
From:      adam@franz.com (Adam T. Dingle)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   SUMMARY: Performance data for PPP/SLIP


Many thanks to everyone who responded to my request about file transfer
performance over PPP/SLIP.  Many people reported real live throughput
of 90-95% of the effective bandwidth; others explained why such throughput
is expected given the protocol encoding.  For details, see the messages
which were posted in response to my posting.

Thanks again.

Adam Dingle
adam@franz.com


-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 02:12:31 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MINIMUM IP DATAGRAM SIZE

In article <24u66e$m3u@carroll2.cc.edu> pwickman@carroll2.cc.edu (Paul Wickman) writes:
>
>	Why is the minimum IP datagram size 576 bytes?

It isn't.  The minimum IP datagram size is much smaller than that,
rather less than 100 octets.  

Are you perhaps referring to the minimum MTU size or the minimum size
IP datagram that all systems must be able to reassemble from fragments
or what ?  

Ran
atkinson@itd.nrl.navy.mil




-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 02:46:54 GMT
From:      jsl@world.std.com (Jonathan S Levinson)
To:        misc.books.technical,comp.protocols.tcp-ip,comp.dcom.lans,comp.sys.sequent,comp.sys.sun.admin
Subject:   Re: OSI books sought

Marshall T. Rose - The Open Book is a good solid description of the protocols.
It has witty asides to liven the text.

OSI Explained by John Henshall and Sandy Shaw is a useful overview.

I don't know of any books on administering OSI, all my experience is
through books, though.

-- 
-------------------------------------------------------------------------
Jonathan Samuel Levinson - jsl@world.std.com    phone: (617) 492 - 8860
Computer Corporation of America                 fax:   (617) 497 - 1072
4 Cambridge Center                              Cambridge MA 02142

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 08:49 EST
From:      sysdhw@atscv1.gsfc.nasa.gov (WiseGuy)
To:        comp.protocols.tcp-ip
Subject:   Unregistered Class A network

There are some people who are thinking of using an unregistered Class A
address for their IP network.  I am not a fan of this idea.  A direct
connection from the Internet would then be unlikely ;-), but they would
then have all of the addresses they could possibly need.

I'm looking for some good PLUSES and MINUSES to pass along to them (to
help them in the decision making process).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
David Weissman - Corporate WAN/LAN Networking

AlliedSignal Technical Services Corp.        Internet -
One Bendix Road,   Dept. 976                       sysdhw@atscv1.gsfc.nasa.gov
Columbia, Maryland 21045-1897                AlliedSignal Aeronet  - 
(410) 964-7909     FAX - (410) 730-6775            ATSCV1::SYSDHW

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 11:46:09 GMT
From:      evansmp@aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: tracing an IP#??

In article <24bvdm$b7f@news.u.washington.edu> dadler@u.washington.edu (David A. Adler) writes:

>Hi,
>This group was suggested to me for my question - I hope this is  
>appropriate. I administer a gopher hole. I have noticed in the log of  
>accesses a strange IP# that seems to be downloading the same directory  
>multiple times a day for the last 2 weeks. I am curious and somewhat  
>concerned about this so I tried identifying machine BUT finger @IP#,  
>whois, traceroute, nslookup all fail to find any info - results like  
>unknown host, etc. Does any one have any further suggestions to trace this  
>IP#? Appreciate any email suggestions.
>Thanks,

Look up the network part of the IP number, this should give you an
idea of the site.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 12:07:24 GMT
From:      robert@pinus.slu.se (Robert Olsson)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Performance data for PPP/SLIP?

>
>Running PPP on a null-modem cable between a SPARCstation-1 and a
>Sun-4/110, connecting the native serial ports at 38400, FTP reported
>3.7-3.8 Kbytes/sec.  Over a pair of V.32bis/V.42/V.42bis modems with
>DTEs running at 38400, FTP reports a little over 2Kbytes/sec for
>binary data (/vmunix) or a little over 3Kbytes/sec for text data
>(/usr/dict/words).  Your numbers will vary with the compressibility of
>your data.
>
>--
>Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
>1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
>bob@MorningStar.Com                                   +1 614 459 5054 (FAX)


	Over 2 kbyte/s must be very good figure. V.32bis gives 14400 bps
	without compression.

	I got 1.2 kbyte/s w V.32bis with archive compressed with gzip
	== very good compression almost nothing to do for the modem
	compression. A ruff calculation: 1.2 * 1024 * 10 = 12480 bps.


	I can see on the Modem LEDs that transmission stops after about
	30 s waits a couple of seconds a then resumes again. Can anyone
	explain this behaivor?

	The equipment used is Cisco cs-500, decstation 500/20 with
	cslip. FTP taget in the example above was sun ss1+.


				Robert Olsson

	

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 13:22:15 GMT
From:      larry@gator.oau.org (Larry D Snyder)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

jeffa@comtch.computech.spk.wa.us (Jeff Albrecht) writes:


>appear. I can't seem to abort the session either. I can 
>rlogin to other hosts when I'm on the system from modem. 
>It's just when I call in on a modem and try to telnet out to 
>another system that I get hung. Seems odd that I can rlogin 
>to remote hosts successfully when connected to the 
>originating system via modem but not via telnet.

I've noticed the same thing when connecting via my buddies machines
(and he runs ISC as well).  Using rlogin solved this problem. 


-- 
Larry Snyder                                    Internet: larry@gator.oau.org
Orlando, Florida                            UUCP: ..!uunet!tarpit!gator!larry

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 21:42:24 -0500
From:      karl@genesis.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <MCCARTY.93Aug19211953@aphid.add.itg.ti.com>,
Rick McCarty <mccarty@add.itg.ti.com> wrote:
>In article <19AUG199308492969@atscv1.gsfc.nasa.gov> sysdhw@atscv1.gsfc.nasa.gov (WiseGuy) writes:
>
>   >There are some people who are thinking of using an unregistered Class A
>   >address for their IP network.  I am not a fan of this idea.  A direct
>   >connection from the Internet would then be unlikely ;-), but they would
>   >then have all of the addresses they could possibly need.
>
>I seem to recall hearing a tale of some (I think it was a) LARGE oil
>company that did something along this line.  And apparently now they are
>paying for it.

Note that class A addresses are <impossible> to get nowdays.  At least I
think they're impossible.  I've been told so :-)

--
Karl Denninger (karl@genesis.MCS.COM) 	| You can never please everyone except
Modem Access: [+1 312 248-0900]		| by bankrupting yourself.
Voice & FAX: [+1 312 248-8649]		| Internet in Chicago; a MCSNET first!

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 13:29:33 GMT
From:      vijay@hicomb.hi.com (Vijay Kumar)
To:        comp.protocols.tcp-ip
Subject:   WHOIS/NICKNAME server


I am trying to figure out the default server name to query name information
(WHOIS/NICKNAME) and looked at RFC954. By reading the document, I understand
that the whois server is on the machine SRI-NIC (26.0.0.73 or 10.0.0.51)
which are unreachable. By looking at the source code for whois (netprog/whois.c)
it looks like nic.ddn.mil is the default server node. Can someone shed some
light on this? Thanks in advance.

Vijay



-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 13:43:27 GMT
From:      jstewart@excelsior.uucp (John W. Stewart III)
To:        comp.protocols.tcp-ip
Subject:   Re: Draft-rfc(s)

In article <1993Aug18.091247.9008@random.ccs.northeastern.edu>,
Ehab Salem Al-Shaer <ehab@ccs.northeastern.edu> wrote:
>I know how to get an RFC documnet from the existing FTP servers BUT
>I don not know where I could find the DRAFT RFC(s) !?
>
>Does any body know how/where I could find Draft RFC ?!

There is no such thing as a "Draft RFC", but if you're talking
about Internet-Drafts, you can get them from any of the IETF
Shadow Directories (ds.internic.net, ftp.nisc.sri.com,
munnari.oz.au, nic.nordu.net) in the /internet-drafts
directory.

Good luck.

/jws

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 13:46:43 GMT
From:      John Mackin <john@civil.su.oz.au>
To:        su.net,aus.wanted,comp.protocols.tcp-ip,comp.protocols.misc,comp.sources.wanted
Subject:   Wanted: Source to `Single-Line' BOOTP daemon

There are at least two kinds of BOOTP daemon for UNIX extant.

One kind, the `CMU daemon,' uses a bootptab format with
entries that are similar to termcap entries.  The source for
that one, in versions 2.0 and 2.1, is readily available for
anonymous FTP from many different places.

I am after the other kind -- the kind that uses a single-line
entry for each host to boot, where the entries look like this:

#
# host          htype         haddr                 iaddr        file
#

X-J05-344-0       1     00:00:A7:00:6F:89       129.78.142.221  Xncd19r

I have not been able to find sources anywhere for a UNIX bootpd
which uses this format in the bootptab file.  (One part of
the documentation for the CMU bootpd implies that versions
earlier than 2.0 used a different bootptab format.  It may
be that what I am really after is a pre-2.0 version of the
CMU bootpd.)

You might well ask why I want this, since this kind of BOOTP server
is necessarily less flexible than the other kind.  Well, that's
the format that the bootpd binary distributed with Ultrix uses,
and I have an automatic suite to construct my bootptab file
in that format from other information, and I don't really have
either the time or the inclination to change that to construct
the bootptab file in the other format, and the DEC-supplied
Ultrix bootpd has a bug that I'd like to fix, and could fix
easily enough if I had the source...

Please reply by e-mail; I will summarise if I receive any
positive responses.

-- 
John Mackin <john@civil.su.oz.au>
Knox's box is a 286.                 Fox in Socks does hacks and tricks
Knox's box is hard to fix.           To fix poor Knox's box for kicks.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 14:44:00 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS/NICKNAME server

Note the date on RFC-954.  At that time the DDN Network Information Center
(nic.ddn.mil) was operated under contract to the Defence Communications Agency
by SRI International.  SRI named its machine "SRI-NIC" rather than "DDN-NIC"
for historic reasons.  A couple of years ago, SRI lost the renewal contract
to operate the DDN NIC and so the reference to nic.ddn.mil is correct and
the reference to sri-nic is out of date.  Old-timers will note that the
SRI-NIC address (10.0.0.51) is on the now defunct ARPAnet.

Note that nic.ddn.mil currently only has information on users of the Defence
Data Network (DDN).  The new InterNIC, operated under contract to NSF by
a commercial for-profit consortium, has some whois services for folks who
aren't DDN users.  However, the InterNIC has been very restrictive in the
whois services offered and a large segment of the Internet community is unhappy
with their attitude. 

Ran



-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 93 21:43:52 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Application Standard for Keepalive?

I've been following this newsgroup for about a month, and have found it very
interesting. It seems to be very good at solving people's implementation
problems, but not as good on moving the vendors toward simpler solutions to
these problems, saving future generations the trouble of encountering them.

Case in point is the recurring discussions on keepalive. Obviously, many people
expect their servers to be able to detect connection failure, and expect the
help of the implementation in solving this frequent problem. Apparently, it's
not implemented in any useful manner in most current implementations.

I've picked up from this newsgroup the fact (?) that the original designers of
TCP/IP were dealing with low-speed links at the time of the design, and
therefore couldn't waste scarce network bandwidth on packets which contain no
data (keepalives). In many applications today, network bandwidth isn't as
scarce as the resources being tied up waiting for a PC to reappear (with its
state intact, no less!).

Besides, if an application sends data on a broken connection, this will be
detected and reported: if it has something to say, it will find out there is no
way to say it. If it has nothing to say, why does it care?

In one application I worked on recently, it cares a great deal. The application
was a print server, and frequently had thousands of blocks of disk space, and
tens of K of memory tied up in resources dedicated to a particular connection,
in addition to the memory and other resources used to "maintain" the
connection. This kind of application needs to be able to free these resources
in a timely manner so that these resources will be available to users who
haven't yet turned their PCs off. :-)

Of course, each application can solve this problem in its own way. But why
reinvent the wheel with each new client-server application? Client-server is
accellerating, and so is "open systems". These two trends collide at TCP/IP, so
there will be an increasing number of surprised (aghast?) implementers.

Are there so many different parameters in the handling of connection failure
detection that most implemenations couldn't easily implement this function? In
fact, is there any parameter other than "maximum time a connection can be dead
without my knowing about it?"


Recognizing that most TCP/IP usage is on Unix-based operating systems, or on
systems emulating the Unix sockets interface, I wonder if there is a current
POSIX standard for network I/O, and whether this standard requires an
implemenation permit the application to set and modify keepalives? If there is
no such standard, perhaps this newsgroup can help create one; if the standard
doesn't require an implementation to implement keepalive, why doesn't it? Can
we change that, and  how?

If the standard does require it how is it specified? I want to kick my vendors
until they implement it!


John Saunders
saunders@eisner.decus.org

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1993 02:57:31 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug20.054400.9656@leland.stanford.edu>,
 schemers@leland.Stanford.EDU (Roland Schemers) wrote:
>We are starting to plan for the day when we do have to give back
>our class A. Hopefully we won't have to, with almost 18,000
>assigned IP addresses :-)

With the upcoming deployment of CIDR, which is going to make us all
classless :-), you could probably give back the majority of your
class A without renumbering at all.

For 18,000 hosts, assuming 18 hosts per subnet and that subnets are
class-C-sized, they would all still fit into 4 class-B-sized chunks.
Now even if you do keep another 50 of the remaining 254 class-B-sized
chunks inside your class A, there are still a good 200 class-B-sized
chunks you could give back to the new CIDR classless pool... :-)

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 15:22:07 GMT
From:      jzinky@BBN.COM ()
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Quality of Service Measurements

I am looking for a way to remotely collect the "Quality of Service" (QOS)
that a host is getting from the network, such as those in X.3.102.
(end-to-end Delay, max throughput, drop rate, power point, etc)

Basically, the host has an agent that is collecting these end-to-end
network performance metrics and allows the network management system
to query for the measurements. 

Here are some possibilities for collecting QOS information.

1) SNMP HOST MIBs
I found the follow MIBS, but none specify collecting QOS
metrics.

A) MIB-II 
  has a TCP section that at least tells you which connections are
  up, but it does not even count events let alone delay.

B) draft-ietf-hostmib-resources-03.txt
 Host configuration

C) draft-hardcastle-app-monitormib-00.txt
 Example of how to monitor an application (mail system) 

D) OSF DCE RFC 32
Requirements for collecting RPC performance. (very close, but I am
more interested in the transport layer.)

*** Is there a MIB that address Quality Of Service?


2) REMOTE PING SERVER
*** Is there a version of ping or traceroute that can be remote controlled?


3) VENDORS CUSTOM EXTENSIONS
*** Do vendors like SUN or HP have RPC mechanisms for remotely monitoring
their workstations?


4) PASSIVE ETHERNET AGENT that tracks TCP connections.
Standard RMON does not have measurements above the MAC layer. 
*** Has RMON been extended to make higher layer performance measurements? 
(For example Trakker)


5) APPLICATION INSTRUMENTATION:
Even more bazaar, I cannot find any way that an application can get at
TCP's Round Trip Time Measurements without poking around in the Unix
kernel (/usr/include/netinet/tcp.h). 

*** Is poking the kernel the standard way for an application to discover
its round trip time?

*** Is there a group that is interested in collecting and analyzing
QOS metrics, i.e  end-to-end network performance metrics?


thanks
zinky

P.S please send a copy of the responses to jzinky@bbn.com and I will
summarize them and repost.


John Zinky
BBN Communications
150 CambridgePark Drive (20/3E)
Cambridge MA 02140

Internet: jzinky@bbn.com
Phone:    617-873-2561 
Fax:      617-873-8202


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1993 03:24:15 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <ccooperCC0rCs.719@netcom.com>, ccooper@netcom.com (Chris Cooper)
 wrote:
>Is it possible to use BOOTP to dynamically assign an address from a pool
>of IP addresses (say 1000 of them) to avoid giving each customer a static
>address?

Yes, many dial-in servers could associate a single IP address to each
of its serial ports, so depending on which modem answers the call the
caller would get the IP address of the serial port which the answering
modem is attached to.  For some dial-in servers you can make this the
default but still allow the user to use his/her own static IP address
if one was allocated to him/her.

>Does the customer lose anything with this approach?

Yes, he/she loses his/her own *unique* IP address :-), and the IP
address can now only be mapped back to a dial-in server port rather
than an individual user.  e.g. dialin-1-5.domain vs. user-name.domain .

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>


-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 16:07:37 GMT
From:      sbonar@boi.hp.com (Scott Bonar)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,ieee.pcnfs
Subject:   Printing Problems w/PC-NFS 5.0 and ODI

I am having problems printing to network printers when I use PC-NFS 5.0 and
the ODI driver under Windows 3.1.  When I use plain PC-NFS everything works
correcly.  Does anyone have any suggestions?

Thanks in advance.

Scott Bonar
Hewlett-Packard
sbonar@hpdmd48.boi.hp.com



-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 16:15:08 GMT
From:      jim@ribit.tadpole.com (Jim Thompson)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Performance data for PPP/SLIP?

In article <1993Aug19.120724.1865@pinus.slu.se> robert@pinus.slu.se (Robert Olsson) writes:
>
>	Over 2 kbyte/s must be very good figure. V.32bis gives 14400 bps
>	without compression.
>
>	I got 1.2 kbyte/s w V.32bis with archive compressed with gzip
>	== very good compression almost nothing to do for the modem
>	compression. A ruff calculation: 1.2 * 1024 * 10 = 12480 bps.

Um, that should be 1.2 * 1024 * 8 (9830 bps).
V.42 cuts out the start/stop bits, so you get back to 8 bits/char.

Note that 14400 bps / 8 bpc == 1800 cps.

>	I can see on the Modem LEDs that transmission stops after about
>	30 s waits a couple of seconds a then resumes again. Can anyone
>	explain this behaivor?

Yer decstation blew a character, and everything came to a stop.  TCP
eventually opened up the link again.

Jim

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 93 21:19:53
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <19AUG199308492969@atscv1.gsfc.nasa.gov> sysdhw@atscv1.gsfc.nasa.gov (WiseGuy) writes:

   >There are some people who are thinking of using an unregistered Class A
   >address for their IP network.  I am not a fan of this idea.  A direct
   >connection from the Internet would then be unlikely ;-), but they would
   >then have all of the addresses they could possibly need.

I seem to recall hearing a tale of some (I think it was a) LARGE oil
company that did something along this line.  And apparently now they are
paying for it.

Assigned IP addresses, while not the most plentiful commodity these days
(relatively speaking), are still easy enough to obtain.  IMHO, it
frankly borders on madness to not use registered addresses these days.
It may not make so much difference right now if one assumes that an
Internet connection could still be had using a firewall to provide the
needed buffer, but with the kind of access capabilities we're likely to
see popping up in the future, not having a registered address might
become a real liability, making it difficult for the organization to
take advantage of them.  If this organization is of any significant
size, it'd behoove whoever is involved in making such decisions to
consider the potential consequences down the road.  Readdressing a large
organization is no fun at all.

--RJMc

===========================================================================
Rick McCarty                                         Texas Instruments Inc.
mccarty@add.itg.ti.com                               Austin, Texas
===========================================================================

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 16:32:05 GMT
From:      hearn@minotaur.dra.hmg.gb (Dave Hearn)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

WiseGuy (sysdhw@atscv1.gsfc.nasa.gov) wrote:
: There are some people who are thinking of using an unregistered Class A
: address for their IP network.  I am not a fan of this idea.  A direct
: connection from the Internet would then be unlikely ;-), but they would
: then have all of the addresses they could possibly need.
 
: I'm looking for some good PLUSES and MINUSES to pass along to them (to
: help them in the decision making process).
: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: David Weissman - Corporate WAN/LAN Networking
 
: AlliedSignal Technical Services Corp.        Internet -
: One Bendix Road,   Dept. 976                 sysdhw@atscv1.gsfc.nasa.gov
: Columbia, Maryland 21045-1897                AlliedSignal Aeronet  - 
: (410) 964-7909     FAX - (410) 730-6775            ATSCV1::SYSDHW


Well,

they could do that.. but then .. I assume they never ever want to be connected
to the net in the future..  Forever is a long time!

I would hate to be the guy who had to administer a massive overnight 
reassignment of Internet addresses across such a net. They sure would have to 
if they chose to follow the unassigned class A net route.


Dave 

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 17:27:58 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.mail.misc,comp.mail.elm,comp.mail.mush,comp.protocols.tcp-ip,gnu.emacs.vm.info
Subject:   POP/IMAP client code for elm/vm/mush ???

I was wondering about the availability of POP2/POP3, or preferably IMAP,
extensions for any of these mailers *for Unix*:

	Elm2 4.xx
	Mush 7.??.??
	Emacs vm-5.??

I am aware of the IMAP client mailers (Pine, MM), patches for BSD Mail,
POP for MH, some POP elisp code that may or may not work with vm.

I am looking for anything specifically suitable to one of the above
mentioned mailers, if available (I have looked at a few FAQs, but either
the info I am looking for is not there or I missed it).

Please provide many references, I shall summarize. Thanks!


-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 18:02:34 GMT
From:      wls@magrathea.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Which host address was used?

I'm having a problem related to host computers with multiple interfaces,
running Ultrix 4.3.  Specifically, it's with "tftp"/"tftpd" (I know,
this is the TCP group, but it seemed a close fit).  The problem is that
"tftp" to one host address works, but "tftp" to another address for
the same host doesn't work.  Since this happens with many different
"tftp" versions, I'm concentrating on "tftpd".  I've tracked it down to
the point where "tftpd" is trying to "recv" an ACK from the remote side,
but either gets a "connection refused" or times out, which seems to be
caused by an earlier "bind" assigning the connection to an address
different from the one the remote "tftp" is using.  I've verified this by
hard-coding a different address into the "bind" - That address then works,
but then other addresses do not.  [Is this a bug, possibly Ultrix-only?] 

Anyways, the easiest fix seems to be to "bind" to the same address the
incoming "tftp" request was originally directed to, except that I can't
find a way to get that information.  The "getsockname" call on the
incoming socket yields zero, since it wasn't bound, and the "recvfrom"
call only gets me the FROM address, and I want the TO address, ie which
of my host addresses was used by the remote side to send me the message.
Have I missed an important call in the network maze??

Failing that, I could find all of the interfaces, "bind" a socket to
each, and then "select" to get the right one.  All together now:  YUCK!

Any helpful hints to a relative novice at the nutworking stuff??

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

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 18:08:20 GMT
From:      abbott@pixel.kodak.com (Terry Abbott)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip,IPX and decnet

Is there a product or products that I can run on an intel processor to
allow tcp/ip, IPX/SPX and decnet at the same time?

Terry Abbott (abbott@pixel.kodak.com)
Eastman Kodak

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 15:01:02 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

Lee Chee Siong (cslee@pds.nchu.edu.tw) wrote:
:   There is a program call PDIPX that can handle both TCPIP & IPX.

Yes, and it is made by Intel, and it should work well if it was not broken...
:-)
 Better stick with ipxtcp.com, which works.
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 18:21:43 GMT
From:      cox@software.org (Guy Cox)
To:        protocols.tcp-ip,protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet,comp.dcom.lans,comp.dcon.lans.misc
Subject:   KA9Q on Everex Speedlink Cards HELP!!!!


I am trying to get the KA9Q NOS to work with a couple of old Everex
ethernet cards. I have a packet driver from their BBS that says it
support ftp, so I am assuming that it does all of TCP/IP as well.
EV2015.EXE is used for the 8-bit card and FTPSLINK.EXE is being used
for the 16-bit card. I have both cards installed and checked out.
The packet drivers are installed at 0x60 on both machines.

Things that I have done with KA9Q:
1) set the hostname, IP's ( nothing wrong with 123.4.5.6 is there?).
	since I am not leaving my site.
2) created an arp entry for each node on each node with the respective
	ethernet addresses.
2) attached packet e1 on the 0x60 sw/interrupt with an IP address for
	each node.
3) started telnet, ftp, rip, etc.
4) added a route for each of the foreign nodes to the local.
5) set the netmask for e1 to 0xffffff00 and/or 0xffffffff ( tried both ).

What I get:
1) ifconfig show the correct IP address for each node in the entry for e1
2) I can telnet and ftp from each node to itself
	 ( the traffic goes to loopback 127.0.0.1).

3) When I ping the remote nodes I get traffic sent from the local and
	received on the remote as indicated by running iconfig on
	the local and the remote.
4) The nodenames are correctly resolved
	 ( monument -> 123.4.5.6, clunker -> 123.4.5.7

What I don't get:
1) A rtt from the ping ( works OK when I self ping the node ).
2) Telnet or FTP prompts.


----- QUESTIONS -----
1) Is there a packet driver for the Everex that may be better documented
	than the one that I have?


2) What configurable items could I change to perhaps get the existing
	packet driver to work with KA9Q ( I thought the interface 
	to the packet driver was "standardized".
 

-- 
//
// Having abandoned my search for the TRUTH I'll settle for a good fantasy.
//


-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 18:27:09 GMT
From:      cox@software.org (Guy Cox)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.misc
Subject:   KA9Q on Everex SpeedLink ??? HELP

I am trying to get the KA9Q NOS to work with a couple of old Everex
ethernet cards. I have a packet driver from their BBS that says it
support ftp, so I am assuming that it does all of TCP/IP as well.
EV2015.EXE is used for the 8-bit card and FTPSLINK.EXE is being used
for the 16-bit card. I have both cards installed and checked out.
The packet drivers are installed at 0x60 on both machines.

Things that I have done with KA9Q:
1) set the hostname, IP's ( nothing wrong with 123.4.5.6 is there?).
	since I am not leaving my site.
2) created an arp entry for each node on each node with the respective
	ethernet addresses.
2) attached packet e1 on the 0x60 sw/interrupt with an IP address for
	each node.
3) started telnet, ftp, rip, etc.
4) added a route for each of the foreign nodes to the local.
5) set the netmask for e1 to 0xffffff00 and/or 0xffffffff ( tried both ).

What I get:
1) ifconfig show the correct IP address for each node in the entry for e1
2) I can telnet and ftp from each node to itself
	 ( the traffic goes to loopback 127.0.0.1).

3) When I ping the remote nodes I get traffic sent from the local and
	received on the remote as indicated by running iconfig on
	the local and the remote.
4) The nodenames are correctly resolved
	 ( monument -> 123.4.5.6, clunker -> 123.4.5.7

What I don't get:
1) A rtt from the ping ( works OK when I self ping the node ).
2) Telnet or FTP prompts.


----- QUESTIONS -----
1) Is there a packet driver for the Everex that may be better documented
	than the one that I have?


2) What configurable items could I change to perhaps get the existing
	packet driver to work with KA9Q ( I thought the interface 
	to the packet driver was "standardized".
 

-- 
//
// Having abandoned my search for the TRUTH I'll settle for a good fantasy.
//


-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 18:29:16 GMT
From:      ccooper@netcom.com (Chris Cooper)
To:        comp.protocols.tcp-ip
Subject:   BOOTP and IP addresses

I just established a dial-in PPP connection to my Service Provider (Netcom)
and they assigned me a static IP address.  I notice that is also possible
to dial in and use BOOTP to assign an address dynamically.  My question is:

Suppose I wanted to establish a large network, as a Service Provider, and
all of my customers would dial in to the servers via PPP.  Assume that I
wanted to plan for 100,000 or more customers.  If I had to assign each
one a separate IP address, that would be unwieldy, and the world would
run out of valid IP addresses sooner rather than later.

Is it possible to use BOOTP to dynamically assign an address from a pool
of IP addresses (say 1000 of them) to avoid giving each customer a static
address? Does the customer lose anything with this approach?

Chris Cooper

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 93 23:47:21
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <251dmg$ber@genesis.MCS.COM> karl@genesis.MCS.COM (Karl Denninger) writes:

   >Note that class A addresses are <impossible> to get nowdays.  At least I
   >think they're impossible.  I've been told so :-)

I think there may be a few unassigned Class A's left, but I believe
these days only an act of the All-Mighty could get you one.

IMHO, Class A's were a MAJOR mistake to have created in the first place
- but hindsight's 20-20, as they say...  There are few to no
organizations that can't get along without what a Class B provides.
Some larger organizations might require multiple B's, but NEVER 250 some
odd worth.

Hmm...  Maybe we should start a campaign to get those Class A's back! ;-)
OK MIT, cough it up... :-)

--RJMc


-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 20:07:19 GMT
From:      rbalko@cbnewsk.cb.att.com (robert.a.balko)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI From RV.3.2 -> RV.4.0

I've set up a client/server model (using TLI)
between UNIX machines, one running release 3.2
the other with release 4.0.

When the 4.0 calls 3.2 everything works fine,
but if I reverse the software, I get a system error (t_errno=8).

I know they (the MIGHTY they) changed everything
around for 4.0, but why doesn't the listen service
'hear' my cries??

I have registered the service, have the right address,
have root permission, etc.

Any Ideas?

Rob Balko
rbalko@attmail.com
!oac!rbalko



-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 20:30:36 GMT
From:      fitzy@titan.ucs.umass.edu (JOSEPH E FITZGERALD)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,ieee.pcnfs
Subject:   Re: Printing Problems w/PC-NFS 5.0 and ODI

Scott Bonar (sbonar@boi.hp.com) wrote:
: I am having problems printing to network printers when I use PC-NFS 5.0 and
: the ODI driver under Windows 3.1.  When I use plain PC-NFS everything works
: correcly.  Does anyone have any suggestions?

You need to re-attach your pc-nfs print devices after load netx...  I think
that'll solve your problem.

Joe Fitzgerald
fitzy@titan.ucs.umass.edu




-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1993 20:55:27 GMT
From:      Tom Lunzer <lunzer@sri.com>
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   AFP printing over TCP/IP

Dose anybody know how to remotely print an Advanced Functions Printing
(AFP) document created on an MVS mainframe over a TCP/IP network?  

Most of documentation I have seen, says its possible, but then the
documents only describe how to configure a Print Services Facilities/2
(as OS/2 print server) using an SNA connection to the mainframe--not a
TCP/IP connection.  Some of the discussions, I have had with the local
IBM technical center, say the it works but they cannot explain what
software is used on the mainframes.  For example, is the mainframe using
TCP/IP!s !lpr! support?  Also, the tech center many of the AFP features
are not supported (such as overlays, simplex/duplex switching)--is this
correct?

Any help would be greatly appreciated!!

Tom Lunzer
Internet: Lunzer@SRI.com
Office: 415-859-4599
Fax: 415-326-5512
MCI Mail: TLUNZER/442-8758

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 93 22:29:44 GMT
From:      mi-rb@starless.utah.edu (Ragula Bhaskar)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: AFP printing over TCP/IP


1.  Is there a TCP/IP stack available in Public domain for embedded 
system applications? If there is, can someone please tell the 
ftp site address and the directory where the file(s) can be found.

2.  I tried to ftp KA9Q from ucsd.edu. But I could not figure out where 
the files were. Can someone tell me the directory path. I also need the ftp 
site and dir path for NCSA TCP/IP stack.

Thanks for the help.

Bhaskar
mi-rb@mines.utah.edu



-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Aug 1993 22:30:27 GMT
From:      goldstein@carafe.enet.dec.com (Fred R. Goldstein)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Strange giant packets in a LAN


One other possibility...

If you have any PeeCees on the net running Netware, you may find
some of them violating the Ethernet packet size limit.  Some Ethernet
card vendors provide drivers that support up to 4K bytes/frame. Sure
it's "illegal" but it "improves performance".

<Lecture on "selfish optimization" omitted.> 
---
Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 00:07:36 GMT
From:      cdb21@cas.org ()
To:        comp.protocols.tcp-ip
Subject:   IPX-TCP/IP gateways?


We are planning to develop a client application to run om a PC in Novell
networks that will communicate with a remote TCP/IP server.  We are aware
that you can put TCP/IP on the PC and this would be our preferred approach,
but we expect there may be cases where the client site does not wish to
put TCP/IP on their Novell for whatever reason (memory limits on PC, etc.).
So we must account for the possibility we may need to develop an IPX client.
Are there any IPX-TCP/IP gateways commercially available?

I'd also be interested in hearing from anyone who thinks this concern is
not warranted.


Thanks.
-- 
Carl D. Bloomfield                                 email:  cdb21@cas.org
Chemical Abstracts Service                         phone:  614-447-3600 (3319)
2540 Olentangy River Rd.                           fax:    614-447-3697
Columbus, Ohio 43210

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 00:33:02 GMT
From:      rawn@Seagull.RTD.COM (Rawn Shah)
To:        comp.protocols.tcp-ip
Subject:   Re: MINIMUM IP DATAGRAM SIZE

From article <CBzI4v.H9t@ra.nrl.navy.mil>, by atkinson@itd.nrl.navy.mil (Ran Atkinson):
> In article <24u66e$m3u@carroll2.cc.edu> pwickman@carroll2.cc.edu (Paul Wickman) writes:
>>
>>	Why is the minimum IP datagram size 576 bytes?
> 
> It isn't.  The minimum IP datagram size is much smaller than that,
> rather less than 100 octets.  

Agreed. I thought the minimum was 40 octets. (IP header only)
> 
> Are you perhaps referring to the minimum MTU size or the minimum size
> IP datagram that all systems must be able to reassemble from fragments
> or what ?  

What he meant by 576 "bytes" is probably the smallest maximum segment size
(MSS) limit for LANs.

> 
> Ran
> atkinson@itd.nrl.navy.mil
> 
> 
> 
-- 
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695
-------------------------------------------------------------------------------

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 01:41:40 GMT
From:      dwing@uh01.colorado.edu (Dan Wing)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip,IPX and decnet

In article <abbott-190893140340@159.56.3.20>, abbott@pixel.kodak.com (Terry 
Abbott) writes:

>Is there a product or products that I can run on an intel processor to
>allow tcp/ip, IPX/SPX and decnet at the same time?

Do you want to run an operating system, too, or just networking protocols?  
:-)

The following vendors supply DECnet for many different types of computer 
systems from HPs, Unixs, PCs, Macs, and others.  As to getting TCP/IP and 
IPX/SPX all running at the same time, it would really depend on which OS 
you wanted to run (MS-DOS, DR-DOS, OS/2, Unix, etc.) and if you could get 
all those protocols loaded and running -- for example, I doubt DOS could
handle it!

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet

-----

Ki Research                              
6760 Alexander Bell Dr.
Columbia, MD  21046
800-945-4454

Thursby Software Systems                 
5840 W. Interstate 20, Suite 100
Arlington, TX  76017
817-478-5070

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 02:31:07 GMT
From:      lparsons@exlog.com (Lee Parsons)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug19.163205.20462@ajax.rsre.mod.uk> hearn@minotaur.dra.hmg.gb (Dave Hearn) writes:
>WiseGuy (sysdhw@atscv1.gsfc.nasa.gov) wrote:
>> There are some people who are thinking of using an unregistered Class A
>> address for their IP network.  I am not a fan of this idea.  A direct
>> connection from the Internet would then be unlikely ;-), but they would
>> then have all of the addresses they could possibly need.
 
>> I'm looking for some good PLUSES and MINUSES to pass along to them (to
>> help them in the decision making process).
>
>they could do that.. but then .. I assume they never ever want to be connected
>to the net in the future..  Forever is a long time!
>
>I would hate to be the guy who had to administer a massive overnight 
>reassignment of Internet addresses across such a net. They sure would have to 
>if they chose to follow the unassigned class A net route.

That, is ofcourse, the only techinical reason for not doing it. The fear that
at somepoint in the future you will have to break everything for a week
just to do what you should have done the first time. (I have been able to 
avoid 2 illegal class A to legal class B changes so far! I was sick that 
day :-})

Given that your internet address is nasa.gov though I would think this
gives you another approach. I'm guessing you are talking about a gov
entity or a contractor for a gov entity.

If that is true is seems unimmaginable that this group would not need
to access the I-net at some time in the future. and that using an unregistered
address would be in violation of some rule some where.

If that is not true, you may still have a chance. If you can find out 
who owns the Address that they plan to use, what would happen if in the
middle of a meeting you asked "Gee I wonder what XYZ Company would 
think about us using their Address. Since is IS assigned by the 
Government of these United States of America (is true? oh well they 
wont know the difference) maybe we should think about this first. Isn't
that like using someones Social Security Number?"

After they spend 45 minutes figuring out its not a problem, tell them 
that the matter should be sent to the legal department for an opinion.
By the time they get done with it the Internet wont use IP addresses
anymore. :-)

Actually I'm only 1/2 joking here. It depends entirely on how straight
and uptight the suits at your org are. If you even hint to them that 
they should go your way because the alternative is unethical/inapproriate
you have already won.
-- 
Regards, 

Lee E. Parsons                  		Baker Hughes Inteq, Inc
Oracle Database Administrator 			lparsons@exlog.com 

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 08:10:07
From:      tabusdal@ulrik.uio.no (Tor Abusdal)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP performance on Gb/s networks

Does anyone have any numbers for the expected performance of NFS and TCP/IP
over networks with a raw speed of 1Gb/s? I am particularly interested in SunOS
and Solaris 2.x as platforms.
At what raw network speed does the limiting factor become OS+TCP overhead? I'm
finding it difficult to obtain measured performance data for FDDI/CDDI and ATM.
Do the current TCP implementations in SunOS and Solaris do header prediction?
Is there any PD SW that includes header prediction, TCP window scaling
(RFC1323) and/or other aids to high performance?
With thanks in advance for any help,

Ron Jones
(c/o tabusdal@ulrik.uio.no, fax: +47 22 41 32 10)

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1993 10:05 EST
From:      sysdhw@atscv1.gsfc.nasa.gov (WiseGuy)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <MCCARTY.93Aug19234721@aphid.add.itg.ti.com>, mccarty@add.itg.ti.com (Rick McCarty) writes...
>In article <251dmg$ber@genesis.MCS.COM> karl@genesis.MCS.COM (Karl Denninger) writes:
> 
>   >Note that class A addresses are <impossible> to get nowdays.  At least I
>   >think they're impossible.  I've been told so :-)
> 
>I think there may be a few unassigned Class A's left, but I believe
>these days only an act of the All-Mighty could get you one.

I think there are 7 left.  I heard this: When a company asked for one 
of those Class A address, the NIC asked them how many IP nodes they would
have, the company answered 100,000.  The NIC said 'not a chance'.....
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
David Weissman - Corporate WAN/LAN Networking

AlliedSignal Technical Services Corp.        Internet -
One Bendix Road,   Dept. 976                       sysdhw@atscv1.gsfc.nasa.gov
Columbia, Maryland 21045-1897                AlliedSignal Aeronet  - 
(410) 964-7909     FAX - (410) 730-6775            ATSCV1::SYSDHW

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 05:44:00 GMT
From:      schemers@leland.Stanford.EDU (Roland Schemers)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <MCCARTY.93Aug19234721@aphid.add.itg.ti.com> mccarty@add.itg.ti.com (Rick McCarty) writes:
>
>Hmm...  Maybe we should start a campaign to get those Class A's back! ;-)
>OK MIT, cough it up... :-)
>

Hey, knock that stuff off! 

Roland

ps. (36.x.x.x) :-)

pps. We are starting to plan for the day when we do have to give back
     our class A. Hopefully we won't have to, with almost 18,000
     assigned IP addresses :-)

-- 
Roland J. Schemers III            |    Networking Systems 
Systems Programmer                |    414 Sweet Hall  +1 (415) 723-6740 
Distributed Systems Operations    |    Stanford, CA 94305-3090
Stanford University               |    schemers@Slapshot.Stanford.EDU 

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 08:41:28 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
>In one application I worked on recently, it cares a great deal. The application
>was a print server, and frequently had thousands of blocks of disk space, and
>tens of K of memory tied up in resources dedicated to a particular connection,
>in addition to the memory and other resources used to "maintain" the
>connection. This kind of application needs to be able to free these resources
>in a timely manner so that these resources will be available to users who
>haven't yet turned their PCs off. :-)

The point has always been and remains today that those resources are
every bit as valuable no matter *why* the client stopped talking.  The
TCP keepalive feature only detects a single cause of the failure:
disrupted TCP communications.  So although keepalives reduce number of
problems, they do not eliminate them all.  A simple timer is at least
as easy to use on most systems, and it provides a simpler mechanism
for detecting a stalled connection in general including the cases
where communications with the remote TCP are still fine.

						don provan
						donp@novell.com

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 08:55:45 GMT
From:      keogh@sse.ie (Paul Keogh)
To:        comp.protocols.tcp-ip
Subject:   TLI access to TCP/IP

Hi,

I am, for a number of perverse reasons, accessing TCP/IP services via the TLI
interface on a SCO 386 machine. Loopback and localhost works OK, but when I
try to contact other TCP/IP servers on my LAN, I get an error from t_connect
with a terse message of "Invalid argument".

The arg. to t_connect() is just a bcopy() of the sockaddr struct - this struct
is valid because I can replace the TLI i/f with a BSD socket interface at this
cut and all works fine.

Any ideas on how I might solve (or even elict more information) on this error ?

Thanx,
Paul Keogh
-- 
Paul Keogh, 				// 
SSE 					//
Dublin, Ireland.			//
					//

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 14:25:04 CDT
From:      schaubert@turtle.fisher.com
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <ccooperCC0rCs.719@netcom.com>, ccooper@netcom.com (Chris Cooper) writes:
> 
> Is it possible to use BOOTP to dynamically assign an address from a pool
> of IP addresses (say 1000 of them) to avoid giving each customer a static
> address? Does the customer lose anything with this approach?
> 
> Chris Cooper

I have no idea if this can be supported with standard bootp but I have
been considering the same problem (Issuing IP numbers at the
BOOTP server).

I figure if my BOOTP clients use the vendor specific area to identify
themselves as needing an IP address assigned even if they do NOT
have their physical address found in the bootptab file, then the
bootp server should be able to assign them an IP address.  As far
as I know this would be an extension to the way BOOTP servers
work now.

Can someone much more knowledgeable about BOOTP's current state
comment on whether such a scheme has been proposed or implemented?

thanks
Joel
schaubert@fisher.com


-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 21:43:04 -0600
From:      "Karl Finkemeyer" <p00122@psilink.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP over X.25 network?

Sounds disappointing. And telnet wouldn't help us much, either, since
it's a client-server application where two programs are talking to each
other.

Is there really no way to convert TCP/IP into the serial bitstream that
the X.25 PAD requires?

Karl Finkemeyer
p00122@psilink.com

>One solution is a pad to telnet converter.  cisco makes such a box and
>calls it a "protocol translator".
>
>IP over X.25 is a no-fun job, one that you really don't want to do in 232
>PCs.
>
>Tony Li
>cisco engineering
 

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 21:49:19 -0600
From:      "Karl Finkemeyer" <p00122@psilink.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP over X.25 network?

Thanks for the messages! 

Is it really impossible to have a pure software solution with TCP/IP
requests coming from the application and the bitstream for X.25 going
out over the serial link to the PAD?

Or is there something I misunderstand completely??

Karl Finkemeyer
p00122@psilink.com

>In article <2954786058.1.p00122@psilink.com> you write:
>>What software packet driver can we use to encapsulate TCP/IP traffic
>>for transmission over an existing X.25 network?
>
>	Here's some previous postings from the net that may help ...
>
>					alan
>______________________________________________________________________
>
>Article: 17396 of comp.protocols.tcp-ip
>Newsgroups: comp.protocols.tcp-ip
>From: WhiskerP@lgwct.logica.com (Peter Whisker)
>Subject: Re: ip over x.25
>Organization: Logica Defence and Civil Government Ltd.
>Date: Fri, 23 Jul 1993 09:15:02 GMT
>
>In article <1993Jul21.162758.14030@serveme.chi.il.us> ke9zd@gagme.chi.il.us (James D. Barlow) writes:
>>From: ke9zd@gagme.chi.il.us (James D. Barlow)
>>Subject: ip over x.25
>>Date: Wed, 21 Jul 1993 16:27:58 GMT
 
>>Howdy,
 
>>i'm looking forw a way to do tcp/ip over x.2 frames, asynch link.
 
>>hopefully, a commercially supported product.  
 
>>the platform is Interactive unix 5.3.2.
 
>>Thanks in advance for any help you may be able to offer.
 
>>--
>>jim@ke9zd.chi.il.us
>
>It is possible to get a product in the UK which does this. Contact
>unipalm@unipalm.co.uk (phone + 44 223 250100, fax +44 223 250101).
>
>They market a PC card from Software Forge which provides a TCP/IP packet
>driver interface to X.25 with leased line or autodial.
>
>Software Forge are also developing an ISDN interface (I believe).
>
>The idea is that when your IP product (PC/TCP, PC/NFS etc) opens a TCP/IP
>session, the card sets up the X.25 link for you.
>
>It is compatible with RFC 1356.
>
>This info was gathered for a recent bid, but I don't guarantee its accuracy
>nor do I work for any of the companies concerned.
>
>Peter Whisker
>
>Newsgroups: comp.protocols.tcp-ip
>From: trk110@aixrs2.hrz.uni-essen.de (Jacek Chmielniak)
>Subject: Re: TCP/IP over X.25 - Help
>Message-ID: <CAtCI4.479@uni-essen.de>
>Date: Tue, 27 Jul 1993 07:51:40 GMT
>X-Newsreader: Tin 1.1 PL4
>Lines: 20
>
>mike@charnock.demon.co.uk (Mike Charnock) writes:
>: 
>: 
>: 
>: We need to run TCP/IP on the PS/2, co-existing with their 5250 connection
>: to an AS/400 across the SDLC and X.25, and establish a VT220 session over
>: TCP/IP to the VAX.  The VAX is not ours, so we can't load anything onto it -
>: it already has TCP/IP.
>: 
>
>i am running OS/2 2.0 with tcp/ip 1.2.1 (this is version for 1.3 but 
>"refreshed" for 2.0) it has optional part X.25. This part coexists with
>Communication Mgr. You can run ip over x.25 with this package.
>Documentation is not briliant, but you can make it.
>
>jacek
>------------------------------------------------------------------------------
>Jacek Chmielniak                               e-mail: trk110@hrz.uni-essen.de
>Uniklinikum Essen                              tel. +49-201-877.0200
>Germany                                        fax. +49-201-723.4694
>
>Newsgroups: comp.protocols.tcp-ip
>From: dcarr@gandalf.ca (Dave Carr)
>Subject: Re: ** What is better TCP/IP or X.25 ?**
>Message-ID: <1993Mar19.161223.17084@gandalf.ca>
>Organization: Gandalf Data Ltd.
>Date: Fri, 19 Mar 1993 16:12:23 GMT
>Lines: 20
>
>In <JIM.93Mar16115242@hunter.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>
>>In article <1993Mar15.134621.36@mvax.uakom.cs> weis@mvax.uakom.cs writes:
 
>>   We have problem. We have some LAN (ethernet) in different towns.
>>   Which protocol will be used ? X.25 or TCP/IP ?
>>   Which is better and why ?
 
>>If the Czech or Slovak PTT only provides X.25, all is not lost. It is
>>possible to run IP over X.25. There's even an RFC which describes how
>>to do this. However, this not ideal because of X.25 packet charges and
>>wasted bandwidth. You have TCP headers inside IP headers inside X.25
>>headers inside HDLC headers....
>
>No, you can buy a gateway that converts between TCP/IP and X.25.  Then,
>the overhead is a lot LOWER with X.25.  We just happen to make such a box. 
>-- 
>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. 
>
>-- 
>Alan Strassberg   alan@lscruz.scf.lmsc.lockheed.com    (408) 425-6139
>Lockheed, Santa Cruz, California.


-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 21:51:26 -0600
From:      "Karl Finkemeyer" <p00122@psilink.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP over X.25 network?

Frank,

the replies so far have all been in the newsgroup here (your's is the
4th reply).

If you find a solution, please let me know. I promise to do the same.

Karl Finkemeyer
p00122@psilink.com

>DATE:   Fri, 20 Aug 93 15:19:08 EDT
>FROM:   Frank Brock <frankb@epenviron.eapi.com>
>
>In comp.protocols.tcp-ip you write:
>
>i would *really* like to hear about the responsesw you get.  we have a
>similar situation w/ pc's talking over rs232-x.25-HP DTC terminal 
>servers.  would like the pcs to do ppp over the 232 to a unix box.
>
>look forward to hearing about the responses.  thanks much.
>
>frank brock
>
>>What software packet driver can we use to encapsulate TCP/IP traffic
>>for transmission over an existing X.25 network?
 
>>We have:
>> 1) An existing client-server application using TCP/IP on an Ethernet-LAN
>>    with MS-Windows clients and Unix server.
>> 2) An existing X.25 network with 232 'remote' PCs running a dumb 
>>    terminal simulator (PTC) talking to an IBM 3090 mainframe.
 
>>We would like to make 1) available to the 232 remote locations through
>>the existing X.25 network by encapsulating the TCP/IP traffic. At the 
>>server site we will use several Eicon cards attached to a Novell server
>>(which is linked via Ethernet LAN to the Unix servers). 
 
>>We don't want to buy an Eicon card for every one of the 232 remote PCs,
>>so we are looking for a cheaper solution for getting the TCP/IP traffic
>>through the PC's serial port to the X.25 PAD.
 
>>I know very little about X.25, so it's not even clear to me if a regular
>>SLIP or PPP driver would already do the trick or not.
 
>>We are currently (on the LAN) using Wollongong's PATHWAY TCP/IP package,
>>but the remote PCs could conceivably run something else, as long as it
>>provides TCP/IP services to the PowerBuilder application - and connects
>>to the X.25 network through the PC's serial port.
 
>>Can anyone help - or at least explain to me how TCP/IP over X.25 is usually
>>done?
 
>>Karl Finkemeyer
>>p00122@psilink.com


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 16:51:48
From:      MVICKERS@fhcrc.org (Mark F. Vickers)
To:        comp.protocols.tcp-ip
Subject:   Will ping work with the wrong frame type.

If one node is configured with a frame type of 802.3 another with Ethernet_II 
can the successfully ping each other.



Thank you.

Mark F. Vickers                  Fred Hutchinson Cancer Research Center
mvickers@cclink.fhcrc.org        1124 Columbia Street, MP-1002
Voice: (206) 667-5742            Seattle, WA 98104
Fax: (206) 667-5530
  
The above material above is the opinion of the SOB who snuck into my
office and used my PC. It has no warrantee ether expressed or implied!!!! 

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 12:14:52 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI access to TCP/IP

In article <CC1vH1.9tJ@sse.ie>, keogh@sse.ie (Paul Keogh) writes:
|> Hi,
|> 
|> I am, for a number of perverse reasons, accessing TCP/IP services via the TLI
|> interface on a SCO 386 machine. Loopback and localhost works OK, but when I
|> try to contact other TCP/IP servers on my LAN, I get an error from t_connect
|> with a terse message of "Invalid argument".
|> 
|> The arg. to t_connect() is just a bcopy() of the sockaddr struct - this struct
|> is valid because I can replace the TLI i/f with a BSD socket interface at this
|> cut and all works fine.
|> 
|> Any ideas on how I might solve (or even elict more information) on this error ?

This should be a t_call structure, not just a sockaddr --

	struct t_call tcall;
	struct sockaddr_in sin;

	sin.sin_family = AF_INET;
	sin.sin_addr.s_addr = htonl(0x7F000001);
	sin.sin_port = htons(portnumber);
	tcall.addr.len = sizeof(sin);
	tcall.addr.buf = (char *)&sin;
	tcall.opt.len = tcall.udata.len = 0;
	tcall.opt.buf = tcall.udata.buf = NULL;
	tcall.sequence = 0;

	if (t_connect(s,&tcall,(struct t_call *)NULL) < 0) {
		if (t_errno == TLOOK) {
			i = t_look(s);
...

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 13:31:22 GMT
From:      cox@software.org (Guy Cox)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.lans.misc
Subject:   Was Everex Help



> I am trying to get the KA9Q NOS to work with a couple of old Everex
> ethernet cards. I have a packet driver from their BBS that says it
> support ftp, so I am assuming that it does all of TCP/IP as well.
> EV2015.EXE is used for the 8-bit card and FTPSLINK.EXE is being used
> for the 16-bit card. I have both cards installed and checked out.
> The packet drivers are installed at 0x60 on both machines.
> 
> Things that I have done with KA9Q:
> 1) set the hostname, IP's ( nothing wrong with 123.4.5.6 is there?).
> 	since I am not leaving my site.
> 2) created an arp entry for each node on each node with the respective
> 	ethernet addresses.
> 2) attached packet e1 on the 0x60 sw/interrupt with an IP address for
> 	each node.
> 3) started telnet, ftp, rip, etc.
> 4) added a route for each of the foreign nodes to the local.
> 5) set the netmask for e1 to 0xffffff00 and/or 0xffffffff ( tried both ).
> 
> What I get:
> 1) ifconfig show the correct IP address for each node in the entry for e1
> 2) I can telnet and ftp from each node to itself
> 	 ( the traffic goes to loopback 127.0.0.1).
> 
> 3) When I ping the remote nodes I get traffic sent from the local and
> 	received on the remote as indicated by running iconfig on
> 	the local and the remote.
> 4) The nodenames are correctly resolved
> 	 ( monument -> 123.4.5.6, clunker -> 123.4.5.7
> 
> What I don't get:
> 1) A rtt from the ping ( works OK when I self ping the node ).
> 2) Telnet or FTP prompts.
> 
> 
> ----- QUESTIONS -----
> 1) Is there a packet driver for the Everex that may be better documented
> 	than the one that I have?
> 
> 
> 2) What configurable items could I change to perhaps get the existing
> 	packet driver to work with KA9Q ( I thought the interface 
> 	to the packet driver was "standardized".
>  
> 

It not seems that the cards are talking at the IP level. If I do an ip status
in KA9 I see the message traffic, the length of the transmission though is 0.

What's the next step?



-- 
//
// Having abandoned my search for the TRUTH I'll settle for a good fantasy.
//


-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 13:32:52 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   BBN && 192.1.1 network

Is it any surprise that BBN has the first few class-C networks?  :)

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

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 14:03:08 GMT
From:      my@berlioz.nsc.com (Mike Yip)
To:        alt.winsock,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.win32,comp.protocols.tcp-ip,comp.os.ms-windows.nt.misc
Subject:   Using select() call for receiving datagram (UDP)

Hi there,

I am trying to use the select() call on FTP Software Inc's winsock and
it kept returning 0 even I am sending more UDP packets to the station.

I first setup a socket to receive UDP datagrams by doing ...
	// build s_local structure here
	s = socket(AF_INET, SOCK_DGRAM, 0);
	bind(s, &s_local, sizeof(s_local));
	FD_ZERO(&fd_struct);
	FD_SET(s, &fd_struct);
then, I try to read datagrams at every timer event by doing ...
	while (select(0, &fd_struct, NULL, NULL, &waitTime)>0)
		recvfrom(s, buf, bufLength, 0, NULL, NULL);

The problem is that select() kept returning 0.  And I never get to
read the incoming packets.  I even try to change the waitTime to a 
longer time, but select() seems to return right away with zero also.

Can please anyone help?  My setup is ...
	Dell 486-66 with NE2000 compatible Ethernet cards
	DOS, FTP Software Inc's TCP/IP Software, MS Window 3.1, winsock.dll.

Please reply to my@berlioz.nsc.com or tchan@berlioz.nsc.com.

-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 	Of course, this is my own opinion!
| 	I don't get paid enough to speak for my company.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 14:13:41 GMT
From:      tskrishn@rs6000.cmp.ilstu.edu (T.S.V. Krishnan)
To:        comp.protocols.tcp-ip
Subject:   Problem with x windows under os/2 - help

	I run Xwindows from a os/2 machine.  When I start X windows I get the 
following message:
Cannot convert String
	"-ibm--medium-r-medium--20-14-100-100-c-90-*:"t

After this my key board does not work.   I am not able to type any thing
I know it is to do something with fonts.  but I am not sure what is to be
done.  Please help

Krishnan

tskrishn@rs6000.cmp.ilstu.edu
Thanks


-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1993 14:25:06 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug20.084128.22735@novell.com> donp@novell.com (don provan) writes:
>In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
>>In one application I worked on recently, it cares a great deal. The application
>>was a print server, and frequently had thousands of blocks of disk space, and
>>tens of K of memory tied up in resources dedicated to a particular connection,
>>in addition to the memory and other resources used to "maintain" the
>>connection. This kind of application needs to be able to free these resources
>>in a timely manner so that these resources will be available to users who
>>haven't yet turned their PCs off. :-)
>
>The point has always been and remains today that those resources are
>every bit as valuable no matter *why* the client stopped talking.  The
>TCP keepalive feature only detects a single cause of the failure:
>disrupted TCP communications.  So although keepalives reduce number of
>problems, they do not eliminate them all.  A simple timer is at least
>as easy to use on most systems, and it provides a simpler mechanism
>for detecting a stalled connection in general including the cases
>where communications with the remote TCP are still fine.
>

I'm not a genius of TCP, but (speaking from an application developer's
viewpoint) what I think saunders@eisner.decus.org really wants is OSI
transport-level functionality (the idea is that communication is interrupted,
alarms go off, someone fixes the problem, and application-level connections
never see the problem UNLESS the application tries to use the connection
while communication is interrupted.

What I think Don is saying is that (in environments he is familiar with)
actually, the same person will do the same thing if the application reports
a communication error as he/she will do if the "transport functionality"
reports a communication error, and the application has to be able to handle
the case of an unresponsive peer application anyway, so TCP keepalive
is just one more event, with little value for the user or the application
developer.

All that said, I have to say that TCP keepalive, as defined today, fails
a basic test for any facility -- is it intuitive? -- and maybe we SHOULD
think about changing its role, if the alternative is that every SINGLE
person developing his/her first TCP application posts a question about 
"how come I don't ever see keepalive failures", followed by at least one 
answer of "because they're probably happening every couple of hours at most", 
followed by at least one of two postings -- "how do I change the default value"
and/or "we need to change TCP keepalives" --, all to comp.protocols.tcp-ip. 
As the number of application developers increases, this won't scale -- same as
IP addressing.

Spencer
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1993 14:48:15 GMT
From:      paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CCSO)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

schemers@leland.Stanford.EDU (Roland Schemers) writes:

>pps. We are starting to plan for the day when we do have to give back
>     our class A. Hopefully we won't have to, with almost 18,000
>     assigned IP addresses :-)

I'd look more closely at OSPF and variable length subnets.  With it we
have over 12,000 assigned addresses under 128.174.0.0 .  There are still
some 20-odd 254 host subnets free as well.  If those are depleted, then
there are a lot of extant subnets that could be compressed to 126 or 62
host subnets with minor pain.  Always encourage people to number from
the beginning of their address range on up.  Bits can be stolen later
w.o. a flag day.

/pbp
-- 
As CSO, Service was our middle name.  Now as CCSO, it's next to last.
	-- Anonymous	(btw, :-) for the humor-impaired)

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 14:53:54 GMT
From:      jepperso@vdoe386.vak12ed.edu (Jay Epperson)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login


Subject: Re: telnet failure under modem login
Newsgroups: comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Organization: Virginia's Public Education Network (Richmond)
References: <1993Aug18.143612.1137@comtch.computech.spk.wa.us>

For what it's worth, we have a com server running Interactive and servicing
six incoming lines on a rotary.  A major function is access to an Internet
feed for telnet/rlogin to other systems/networks.  Seems to work fine.

"This message constructed of recycled bits."

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 14:55:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

In article <TABUSDAL.93Aug20081007@ulrik.uio.no>, tabusdal@ulrik.uio.no (Tor Abusdal) writes:
> Does anyone have any numbers for the expected performance of NFS and TCP/IP
> over networks with a raw speed of 1Gb/s? I am particularly interested in SunOS
> and Solaris 2.x as platforms.
> At what raw network speed does the limiting factor become OS+TCP overhead? I'm
> finding it difficult to obtain measured performance data for FDDI/CDDI and ATM.
> Do the current TCP implementations in SunOS and Solaris do header prediction?
> Is there any PD SW that includes header prediction, TCP window scaling
> (RFC1323) and/or other aids to high performance?
> With thanks in advance for any help,
> 
> Ron Jones
> (c/o tabusdal@ulrik.uio.no, fax: +47 22 41 32 10)



One way to answer such questions is to ask the vendor that makes the
platforms you want about the performance they get on lower speed media.
Ask your Sun sales organization about FDDI.

As for TCP/IP overhead, it seems to be universally agreed by those who
plausibly claim to know about such things that TCP/IP works fine on
Gbit/sec media.  The protocol processing for each TCP/IP packet can be
done in less than 200 instructions (Van Jacobson's "squashed stack")
and enough data cache faulting to get 40 bytes of data.  The cache
faults are often the bottleneck on modern CPU's, those that can execute
those 200 instructions in about 1 microsecond.

Header prediction has been in the redistributable 4.3BSD source for
several years.  Thomas Skibo's TCP-LW code is available somewhere--Indiana?


Vernon Schryver,  vjs@sgi.com

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 15:27:24 GMT
From:      eialbur@sgies9.sdrc.com (Ron Albury)
To:        alt.winsock,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.win32,comp.protocols.tcp-ip,comp.os.ms-windows.nt.misc
Subject:   Re: Using select() call for receiving datagram (UDP)

FTP's winsock has a number of bugs.  I just downloaded the alpha5 dll from
their BBS, and it seems to have fixed most of my problems.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 1993 03:19:37 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <jttu26m@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com
 (Vernon Schryver) wrote:
>In article <2528of$66v@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam)
> writes:
>> In article <ccooperCC0rCs.719@netcom.com>, ccooper@netcom.com (Chris Cooper)
>>  wrote:
>> >Does the customer lose anything with this approach?
>> 
>> Yes, he/she loses his/her own *unique* IP address :-), ...
>
>Why does the customer's machine lose its own, unique IP address?  
>That one end of a PPP or SLIP link is constrained to the the terminal
>server's chosen number does not constraing the IP address of the other
>end of the point-to-point link.

Because in a typical terminal server which also support SLIP/PPP
(like a Cisco or an Annex), the IP address it assigns to a serial
port is actually for the far-end (user-end) of the serial line.

If the machine calling in has another network interface (e.g. an
Ethernet interface) in addition to its serial interface, then that
interface can be used to hold an unique IP address, but if the
remote machine is a PC with just a serial port and a modem, then
it is stuck with using the IP address that the terminal server thinks
it should be using.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>


-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 15:41:25 GMT
From:      nick@quay.ie (Nick Hilliard)
To:        comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   [Q] SLIP into a Sun box?

Howdy all,

I'm making vague attempts at the moment to set up a Sun as a SLIP server. Is
there any package which will do this automatically/with minimal fuss/bother?

What I'm doing at the moment (or at least trying to do) is to hack the csn
slip package so that a client can log in to a special SLIP a/c which starts
up the slip module on the Sun. This, unfortunately, hasn't met with much
success to date :-(

So, any ideas?  Anyone done this sort fo thing before?

Nick
-- 
| Nick Hilliard                  | e-mail:   nick@quay.ie                   |
| Quay Financial Software,       | Phone:    [+353] 1 6612377               |
| Ferry House, Lower Mount St,   | Fax:      [+353] 1 6607592               |
| Dublin 2, Ireland.             | Opinions: I think; therefore I disclaim. |

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 22:55:42 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug20.084128.22735@novell.com>, donp@novell.com (don provan) writes:
> In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
>>In one application I worked on recently, it cares a great deal. The application
>>was a print server, and frequently had thousands of blocks of disk space, and
>>tens of K of memory tied up in resources dedicated to a particular connection,
>>in addition to the memory and other resources used to "maintain" the
>>connection. This kind of application needs to be able to free these resources
>>in a timely manner so that these resources will be available to users who
>>haven't yet turned their PCs off. :-)
> 
> The point has always been and remains today that those resources are
> every bit as valuable no matter *why* the client stopped talking.  The
> TCP keepalive feature only detects a single cause of the failure:
> disrupted TCP communications.  So although keepalives reduce number of
> problems, they do not eliminate them all.  A simple timer is at least
> as easy to use on most systems, and it provides a simpler mechanism
> for detecting a stalled connection in general including the cases
> where communications with the remote TCP are still fine.
> 

What kind of "simple timer" do you mean? Could you give an example?

> 						don provan
> 						donp@novell.com

John Saunders
saunders@eisner.decus.org

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 16:20:09 GMT
From:      jwl@jlumley.hpl.hp.com (John Lumley)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

In article <TABUSDAL.93Aug20081007@ulrik.uio.no>, tabusdal@ulrik.uio.no (Tor Abusdal) writes:
> Does anyone have any numbers for the expected performance of NFS and TCP/IP
> over networks with a raw speed of 1Gb/s? I am particularly interested in SunOS
> and Solaris 2.x as platforms.
>....

Some of the issues involved are examined in the July 93 issue of
IEEE Network on end-system support for high-speed networks. For the
near-term it's reasonably clear that the bus/cache/memory bottlenecks
on workstations will limit progress to high-throughput O(500 Mb/s)
though decreasing latency towards 100us will be far more susceptible
to software progress.

I would have thought it premature to make any detailed estimates of
throughput, except that at present workstations attached to Gb/s
networks should perform >100Mb/s but <<1 Gb/s, with perhaps
200-300 Mb/s a realistic target for common high-end machines in late
94/early 95. (And we do mean high-end machines O(100+ MIPS))

------------------------------------------------------------------
John Lumley                      | Network Technology Dept.
Hewlett-Packard Laboratories     | Phone:  +44 272 228743
Filton Road, Stoke Gifford       | E-mail: jwl@hplb.hpl.hp.com
BRISTOL BS12 6QZ                 | Fax:    +44 272 228924
U.K.                             | Telnet: 312 8743


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 23:05:22 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <252ms2$23e@crchh327.bnr.ca>, dawkins@bnr.ca (Spencer Dawkins) writes:
> In article <1993Aug20.084128.22735@novell.com> donp@novell.com (don provan) writes:
>>In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
>>>In one application I worked on recently, it cares a great deal. The application
>>>was a print server, and frequently had thousands of blocks of disk space, and
>>>tens of K of memory tied up in resources dedicated to a particular connection,
>>>in addition to the memory and other resources used to "maintain" the
>>>connection. This kind of application needs to be able to free these resources
>>>in a timely manner so that these resources will be available to users who
>>>haven't yet turned their PCs off. :-)
>>
>>The point has always been and remains today that those resources are
>>every bit as valuable no matter *why* the client stopped talking.  The
>>TCP keepalive feature only detects a single cause of the failure:
>>disrupted TCP communications.  So although keepalives reduce number of
>>problems, they do not eliminate them all.  A simple timer is at least
>>as easy to use on most systems, and it provides a simpler mechanism
>>for detecting a stalled connection in general including the cases
>>where communications with the remote TCP are still fine.
>>
> 
> I'm not a genius of TCP, but (speaking from an application developer's
> viewpoint) what I think saunders@eisner.decus.org really wants is OSI
> transport-level functionality (the idea is that communication is interrupted,
> alarms go off, someone fixes the problem, and application-level connections
> never see the problem UNLESS the application tries to use the connection
> while communication is interrupted.
> 

Actually, I don't think I want that functionality. What I want is that, with
some per-server granularity, the application be notified that the connection
has broken. The application would then _not_ reestablish the session, but would
free resources which had been allocated to the session.

> What I think Don is saying is that (in environments he is familiar with)
> actually, the same person will do the same thing if the application reports
> a communication error as he/she will do if the "transport functionality"
> reports a communication error, and the application has to be able to handle
> the case of an unresponsive peer application anyway, so TCP keepalive
> is just one more event, with little value for the user or the application
> developer.

Huh? I'm taking the case where the server is driven entirely from the client,
and so will not detect "unresponsive client" except through notification that
the transport session is gone. I agree that he will find out if he writes
something, but what if he has nothing to write? Should he wait two hours? Not
in _my_ app.

> 
> All that said, I have to say that TCP keepalive, as defined today, fails
> a basic test for any facility -- is it intuitive?

My intuition told me that the transport would tell me when the connection I
asked it to make goes away. My intuition did not lead me to suspect that I'd
have to wait two hours to see this happen.

> 
> Spencer
> -- 
> ------------------------------------------------------------------------------
> -  Spencer Dawkins			Bell-Northern Research	             -
> -  (214) 684-4827			P.O. Box 833871                      -
> -  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -


John Saunders
saunders@eisner.decus.org

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 23:12:18 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <JAZZ.93Aug20125443@jazz.hal.com>, jazz@hal.com (Jason Zions) writes:
> In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
> 
>    Recognizing that most TCP/IP usage is on Unix-based operating systems, or
>    on systems emulating the Unix sockets interface, I wonder if there is a
>    current POSIX standard for network I/O, and whether this standard
>    requires an implemenation permit the application to set and modify
>    keepalives? If there is no such standard, perhaps this newsgroup can help
>    create one; if the standard doesn't require an implementation to
>    implement keepalive, why doesn't it? Can we change that, and how?
> 
> There is a POSIX standard under development which addresses APIs for network
> communication; the project is IEEE P1003.12. Fortuitously, the ballot group
> for that standard is being formed; contact the IEEE Standards Department
> *immediately* if you wish to join that ballot group, as ballot group
> formation closes August 30. The responsible person is Anna Kaczmarek at
> (908) 562-3811.

Great, they _would_ pick the one week this year I'll be on vacation!

> 
> The current draft of P1003.12 does not address the issue of keepalives and
> peer death detection for several reasons. First, 1003.12 is an API standard;
> it doesn't directly standardize transports, protocols, or any of that noise,
> and is intended to be protocol independent. Second, there is no existing
> practice of an interface which allows an application to adjust keepalive
> timeouts; the current policy of POSIX working groups is to avoid invention
> and standardize existing practice.
> 

As to existing practice, I believe that the AppleTalk ATP protocol has an
ability like this as of Phase II. This might not be an actual keepalive,
though, and I'm not sure if Apple exposes this in the API, so I'm willing to
believe there's no existing practice. Presumably, the existing practice is for
everyone to re-invent the wheel...

> 
> Jason Zions

John Saunders
saunders@eisner.decus.org

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 17:03:59 GMT
From:      dmurphy@ithaca.Eng.Sandy.Novell.COM (David Murphy)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip,IPX and decnet

In article <1993Aug20.014140.3146@colorado.edu> dwing@uh01.colorado.edu writes:
>In article <abbott-190893140340@159.56.3.20>, abbott@pixel.kodak.com (Terry 
>Abbott) writes:
>
>>Is there a product or products that I can run on an intel processor to
>>allow tcp/ip, IPX/SPX and decnet at the same time?
>
>Do you want to run an operating system, too, or just networking protocols?  
>:-)
>
>The following vendors supply DECnet for many different types of computer 
>systems from HPs, Unixs, PCs, Macs, and others.  As to getting TCP/IP and 
>IPX/SPX all running at the same time, it would really depend on which OS 
>you wanted to run (MS-DOS, DR-DOS, OS/2, Unix, etc.) and if you could get 
>all those protocols loaded and running -- for example, I doubt DOS could
>handle it!
>
>-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet
>


u can do this with ODI, in DOS or OS/2 using ODINSUP for the NDIS DECNet Stack
and TCP/IP over ODI or TCP/IP over NDIS using ODINSUP, and DOS can handle it.

This is one of the reasons for ODINSUP's orig. development.


David_Murphy@novell.com         All opinions are my own, not the employer's
                                And I am not a support person either, so 
                                support questions should go to support people.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 17:28:42 GMT
From:      bounds@gulaam.glv.com (Frank Bounds)
To:        comp.protocols.tcp-ip
Subject:   PSI as an Internet provider


Anyone have experience using PSI as an internet provider? Any
comments? Good, bad or so so experiences? We have narrowed down to
a couple of providers in the Ralegh, NC area. A provider that has
connections to the east coast CIX is desirable. Thanks in advance!

--
                                                        ___
                                                       |___|
                                      +----------------||-----++
                                      | Frank Bounds   ||     ||
                                     /| bounds@gulaam.glv.com ||
                                    | | ENCOMPASS             ||
                                    | | Cary, North Carolina  ||
                                  --| +-----------------------++
                                  --| |-----------------------/

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 17:37:21 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

We asked for a class A and were promptly refused.  Getting multiple class B's
at one time is about as hard.  We hope to be able to get a class B for each
continent.  If I can't get them, there has been a certain contingent internally
that has been pushing for using unregistered space.  Basically, the IP number
crunch is causing me internal political squabbles.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 18:25:47 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

In article <jtqoif4@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>As for TCP/IP overhead, it seems to be universally agreed by those who
>plausibly claim to know about such things that TCP/IP works fine on
>Gbit/sec media.

  I am told (and have good reason to believe) that there exist sites
which run TCP/IP at about 800 Mbps.  Dave Borman has gotten it running
quite fast on TCP/IP/HiPPi, but I don't recall his most recent exact
figure.

  I am not even slightly worried about running IP/ATM at OC-48 speeds,
which are over a Gigabit/second.  Other aspects of ATM remain
worrisome to me, but not the high speed TCP/IP processing aspect.

Ran
atkinson@itd.nrl.navy.mil




-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 18:31:35 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <2528of$66v@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam) writes:
> In article <ccooperCC0rCs.719@netcom.com>, ccooper@netcom.com (Chris Cooper)
>  wrote:
> >Is it possible to use BOOTP to dynamically assign an address from a pool
> >of IP addresses (say 1000 of them) to avoid giving each customer a static
> >address?
> 
> Yes, many dial-in servers could associate a single IP address to each
> of its serial ports, so depending on which modem answers the call the
> caller would get the IP address of the serial port which the answering
> modem is attached to.  For some dial-in servers you can make this the
> default but still allow the user to use his/her own static IP address
> if one was allocated to him/her.
> 
> >Does the customer lose anything with this approach?
> 
> Yes, he/she loses his/her own *unique* IP address :-), and the IP
> address can now only be mapped back to a dial-in server port rather
> than an individual user.  e.g. dialin-1-5.domain vs. user-name.domain .
> 
> ...Sam
> -- 
> <skl@Connectivity.com> -- Connectivity Technology Inc.


Why does the customer's machine lose its own, unique IP address?  
That one end of a PPP or SLIP link is constrained to the the terminal
server's chosen number does not constraing the IP address of the other
end of the point-to-point link.  As long as all of the terminal servers
look to the rest of the Internet as if they are in the same place (e.g.
same subnet), everything should work fine.

Except for routing issues, this works for me with the SLIP and PPP code
I use, with one end fixed and the other varying among a bunch of 
different network numbers.


Vernon Schryver,  vjs@sgi.com

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1993 18:54:42 GMT
From:      jazz@hal.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:

   Recognizing that most TCP/IP usage is on Unix-based operating systems, or
   on systems emulating the Unix sockets interface, I wonder if there is a
   current POSIX standard for network I/O, and whether this standard
   requires an implemenation permit the application to set and modify
   keepalives? If there is no such standard, perhaps this newsgroup can help
   create one; if the standard doesn't require an implementation to
   implement keepalive, why doesn't it? Can we change that, and how?

There is a POSIX standard under development which addresses APIs for network
communication; the project is IEEE P1003.12. Fortuitously, the ballot group
for that standard is being formed; contact the IEEE Standards Department
*immediately* if you wish to join that ballot group, as ballot group
formation closes August 30. The responsible person is Anna Kaczmarek at
(908) 562-3811.

The current draft of P1003.12 does not address the issue of keepalives and
peer death detection for several reasons. First, 1003.12 is an API standard;
it doesn't directly standardize transports, protocols, or any of that noise,
and is intended to be protocol independent. Second, there is no existing
practice of an interface which allows an application to adjust keepalive
timeouts; the current policy of POSIX working groups is to avoid invention
and standardize existing practice.

I am not the chair of P1003.12, and I cannot make drafts, mailings, etc.
available to anyone. Contact the IEEE Standards Department to join the
ballot group; contact the IEEE-CS to obtain drafts, to get contact info for
the working group, etc.

Jason Zions

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 19:05:11 GMT
From:      suma@fedfil.UUCP (Suma Vasudevan)
To:        comp.protocols.tcp-ip
Subject:   To read a TCP/IP feed on unix



Hi,

I looking for some directions in writing a program to capture a TCP/IP
based T1 line data feed coming to a unix machine. 
(The data comes in continously in bandwidth about 50-150MB/hr.)
Is there any FTP site I can get source which does similar things?

Another Question I have is, is there any limitations on the volume of 
data a unix system can hold?

Thanks in advance,

Suma.

Suma@fedfil.com



-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 19:11:10 GMT
From:      Greg Tilford <gtilford@lobby.ti.com>
To:        comp.protocols.tcp-ip
Subject:   Internet Dial-up


Does anyone have a list of companies (or just a company that they are happy 
wity) that provide service for dial-up Internet access?  I want more than just 
E-mail, such as the ability to read/post to news groups, Telnet, FTP, etc...

Thanks in advance, 

Greg Tilford
E-mail: gtilford@lobby.ti.com

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 19:32:46 GMT
From:      usramasa@uncc.edu (Usharani Ramasamy)
To:        comp.protocols.tcp-ip
Subject:   TLI ERROR



Hi ---

I have problem in establishing connection between server and client using TLI.

Following is the source code for server and client. I don't see
any reason why the connection is not established everytime I run the
program..

The fun part is sometimes the connection gets through. Most of the
times error message is from the client side. Very few times the error
message is from the server side..

Server side error mesg..
=======================

t_accept failed for fd: System error: Protocol error.

Client side error mesg..
======================

t_connect failed for fd: System error: Protocol error.


I am executing the programs on SPARC station IPC, SPARC station2 running
 Sun OS release 4.1.3


For testing the code
====================

How to compile?

cc server.c -lnsl -o server
cc client.c -lnsl -o client

command line syntax:-

For example:

server ws134 
client ws134

                        SERVER CODE
                        ============

#include <stdio.h>
#include <tiuser.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <stropts.h>
#include <signal.h>
#include <netdb.h>
#include <sys/time.h>

#define SERV_TCP_PORT 10494
#define DEV_TCP "/dev/tcp"



extern int t_errno;



main(argc, argv)
int argc;
char *argv[];
{
      int  listen_fd;
      struct sockaddr_in  serv_addr;
      struct t_info info;
      struct t_bind *req;
      struct t_call *call;

      struct hostent *hp, *gethostbyname();

         if(argc < 2)
          {
            printf("Incorrect arguments on the command line\n");
            exit(1);
          }
 
         hp= gethostbyname(argv[1]);
 
         if (hp == 0)
           {
              fprintf(stderr, "%s: unknown server", argv[1]);
              exit(3);
           }
 
         if ((listen_fd = t_open("/dev/tcp", O_RDWR, &info)) < 0)
           {
              t_error("t_open failed for listen_fd");
              exit(1);
           }
        printf("service type is %ld\n", info.servtype);
 
 
        bzero ((char *) &serv_addr, sizeof(serv_addr));
        serv_addr.sin_family            = AF_INET;
        serv_addr.sin_port              = htons(SERV_TCP_PORT);
 
        memcpy (( char *) &serv_addr.sin_addr,
                    hp->h_addr, hp->h_length);
 
       if (( req = (struct t_bind *)t_alloc(listen_fd,
                     T_BIND, T_ALL)) == NULL)
         {
           t_error("t_alloc failed");
           exit(4);
         }
 
       req->addr.len    = sizeof(struct sockaddr_in);
       req->qlen        = 1;
 
       req->addr.buf = (char *)&serv_addr;
 
       if(t_getstate(listen_fd) == T_UNBND)
         printf("Transport_endpoint is unbound\n");
 
 
       printf("service type is %ld\n", info.servtype);
 
      if (t_bind(listen_fd, req,  req ) < 0)
         {
              t_error("server: can't bind local address");
              exit(4);
         }
 
            printf("after calling t_bind\n");
 
 
       if(t_getstate(listen_fd) != T_UNBND)
         printf("Transport_endpoint is bound\n");

 
      if (( call = (struct t_call *) t_alloc(listen_fd,
                     T_CALL, T_ALL)) == NULL)
         {
            t_error("t_alloc of t_call structure failed");
            exit(5);
         }
 
       if(t_getstate(listen_fd) == T_IDLE)
         printf("Transport_endpoint is idle\n");
 
 
     if (t_listen(listen_fd, call) < 0)
        {
         {
          t_error("server: t_listen error");
          exit(6);
        }
 
 
       if(t_getstate(listen_fd) == T_INCON)
         printf("Incoming connection pending\n");
 
 
        if( t_accept(listen_fd,listen_fd,call) < 0)
           {
             t_error("t_accept failed");
             exit(10);
           }
 
       if(t_getstate(listen_fd) == T_DATAXFER)
         printf("data transfer\n");
 
}


             
                    CLIENT CODE
                   ===============

 #include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <tiuser.h>
#include <stropts.h>
#include <netdb.h>
#include <sys/time.h>


#define SERV_TCP_PORT 10494
#define DEV_TCP "/dev/tcp"



main(argc, argv)
int argc;
char *argv[];


{

         int fd;
         int nbytes;
         int flags = 0;
         struct t_call *sndcall;
         extern int t_errno;
         struct sockaddr_in   serv_addr;
         struct t_info info;
         struct t_bind request;
         struct t_discon *discon;

         struct hostent *hp, *gethostbyname();

         if (argc < 2)
            {
                printf("Incorrect arguments on the command line\n");
                exit(1);
            }
         hp= gethostbyname(argv[1]);
 
 
         if (hp == 0)
           {
              fprintf(stderr, "%s: unknown host", argv[1]);
              exit(3);
           }
 
 
         if ((fd = t_open("/dev/tcp", O_RDWR, &info )) < 0)
           {
               t_error("t_open failed");
               exit(1);
           }
     printf("service type is %ld\n", info.servtype);
 
 
         if (t_bind(fd, NULL, NULL) < 0)
           {
              t_error("t_bind failed");
              exit(2);
          }
 
        printf("after calling t_bind\n");
      serv_addr.sin_family            = AF_INET;

      serv_addr.sin_port              = htons(SERV_TCP_PORT);
      memcpy (( char *) &serv_addr.sin_addr, hp->h_addr, hp->h_length);
 
         if (( sndcall = (struct t_call *)t_alloc(fd, T_CALL, T_ALL)) == NULL)
              {
                 t_error("t_alloc failed");
                 exit(3);
              }
 
 
      sndcall->addr.len    = sizeof(serv_addr);
      sndcall->addr.buf    = (char *) &serv_addr;
 
 
       if(t_getstate(fd) == T_IDLE)
         printf("TEP is idle\n");
 
        printf("before calling t_connect\n");
 
            if(t_connect(fd, sndcall,NULL) < 0)
            {
              printf("Error # =%d, t_getstate = %d\n",       t_errno,t_getstate(fd));
              t_error("t_connect failed for fd");
              exit(4);
            }
 
         if(t_getstate(fd) == T_DATAXFER)
         {
          printf("connected to %s\n", argv[1]);
          printf("data transfer\n");
         }
 
 
}


I don't see any reason why proper handshaking is not taking place
in this case. 

Would someone help me?

Thanks in advance,

Best regards,
usha





-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 19:38:23 GMT
From:      kunkee@nmti.com (randy kunkee)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <1993Aug20.145354.21675@vdoe386.vak12ed.edu> jepperso@vdoe386.vak12ed.edu (Jay Epperson) writes:
>
>Subject: Re: telnet failure under modem login
>Newsgroups: comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
>Organization: Virginia's Public Education Network (Richmond)
>References: <1993Aug18.143612.1137@comtch.computech.spk.wa.us>
>
>For what it's worth, we have a com server running Interactive and servicing
>six incoming lines on a rotary.  A major function is access to an Internet
>feed for telnet/rlogin to other systems/networks.  Seems to work fine.
>
>"This message constructed of recycled bits."

I just set up a customer to dial in to our system, and he had the
same problem.  This is an old problem, I had just forgotten about
it.  It's a bug in the driver for the Digiboard (pc/8e) that we have.
We tried a later driver from Digiboard, but it was even worse (crashed
the system frequently).  This is on a 386 with Intel SVR3.2 Unix.
Rlogin works, but telnet does not.

Perhaps you do not have a Digiboard, and the original poster with the
problem does, or different versions of the driver (and O/S) are involved.
-- 
Randy Kunkee
Network Management Technology, Incorporated
1601 Industrial Blvd.  Sugar Land, TX 77478
+1 713 274 5132

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 19:42:25 GMT
From:      doug@happy.vf.ge.com (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <2528of$66v@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam) writes:
> In article <ccooperCC0rCs.719@netcom.com>, ccooper@netcom.com (Chris Cooper)
>  wrote:
> >Is it possible to use BOOTP to dynamically assign an address from a pool
> >of IP addresses (say 1000 of them) to avoid giving each customer a static
> >address?
> 
> Yes, many dial-in servers could associate a single IP address to each
> of its serial ports, so depending on which modem answers the call the
> caller would get the IP address of the serial port which the answering
> modem is attached to.  For some dial-in servers you can make this the
> default but still allow the user to use his/her own static IP address
> if one was allocated to him/her.
> 

Wait a second..  The original poster asked specifically about BOOTP.
While many dial in servers may be able to do it, BOOTP can't as far
as I know. At least nothing in the version of BOOTP that I have indicates
anything about dynamic IP address assignment.  I would LOVE to be 
proven wrong on this because we were looking for similar functionality
out of BOOTP.


-- 
_____________________________________________________________
Doug Hughes
System/Net Admin - Martin Marietta Aerospace, Valley Forge, PA
doug@happy.vf.ge.com	or	doug@land.vf.ge.com

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 21:00:10 GMT
From:      guyh@hpubvwa.nsr.hp.com (Guy Hyde)
To:        comp.protocols.tcp-ip
Subject:   Re: A new tool for managing network variables like TCP max window size

Jon Kay (jkay@cs.ucsd.edu) wrote:

: 			NETCONFIG
 
: 	Netconfig is a program intended to make management of
: network configuration options such as TCP maximum window size a part
>
>  stuff deleted
>
 
: LOCATION
 
: Netconfig is available for anonymous FTP at:
 
: ucsd.edu:pub/csl/netconfig/netconfig.tar.Z
>
>  stuff deleted
>

Jon,

I would like to access this tool, however I cannot ftp
to your source system. Would you be so kind as
to post the full IP address. Thanks very much.




-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 21:15:29 GMT
From:      bill@frog.uucp (buick)
To:        comp.protocols.tcp-ip
Subject:   Re: PSI as an Internet provider

In article <1993Aug20.172842.3257@glv.uucp> bounds@gulaam.glv.com (Frank Bounds) writes:
>
>Anyone have experience using PSI as an internet provider? Any
>comments? Good, bad or so so experiences? We have narrowed down to
>a couple of providers in the Ralegh, NC area. A provider that has
>connections to the east coast CIX is desirable. Thanks in advance!

We have been using them for about 3-4 months.  We picked them and their
host-dial interface because they were the cheapest way to get connected.

We had to come up with slip ourselves and write a special program to
dial-up and set up the ip addresses.  (They give us a different one
each time.)  Sometimes it seems like mail take too long to get to us,
but I cannot blame them for that (other things could be at fault).

We continue to use a closer (and cheaper) line for our newsfeed.

It seems to work.  We are basically happy with the results.
-- 

bill masek		charles river data systems, inc
(617) 275-4565 (h)	(508) 626-1122 (w)
mit-eddie!frog!bill	bill@cr.com

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 93 22:53:35 GMT
From:      sysmgr@wittenberg.edu
To:        comp.protocols.tcp-ip
Subject:   BOOTP and dynamic IP addresses

> 
> Wait a second..  The original poster asked specifically about BOOTP.
> While many dial in servers may be able to do it, BOOTP can't as far
> as I know. At least nothing in the version of BOOTP that I have indicates
> anything about dynamic IP address assignment.  I would LOVE to be 
> proven wrong on this because we were looking for similar functionality
> out of BOOTP.
> 
> 
> -- 
> _____________________________________________________________
> Doug Hughes
> System/Net Admin - Martin Marietta Aerospace, Valley Forge, PA
> doug@happy.vf.ge.com	or	doug@land.vf.ge.com

I was attempting to get KA9Q running it's BOOTP server at one time.  It came 
with no documentation (that I could find), so it was (extremely) rough
impelementing it.  Every time it saw a request, it logged an error something
like "no dynip addresses available".  There is a "dynamic IP" configuration
directive; perhaps this is what you are looking for?  I am only guessing.
You might want to look into KA9Q.  It runs on MS-DOS.  It's free to educational
institutions.  I'm not sure what the policy is for commercial sites.

Kevin Yoders
Wittenberg University

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 1993 23:14:03 GMT
From:      alan@ernest.itg.ti.com (Alan Edmonds)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <id.H1X11.852@nmti.com>, randy kunkee <kunkee@nmti.com> wrote:
>In article <1993Aug20.145354.21675@vdoe386.vak12ed.edu> jepperso@vdoe386.vak12ed.edu (Jay Epperson) writes:
>>
>>Subject: Re: telnet failure under modem login
>>Newsgroups: comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
>>Organization: Virginia's Public Education Network (Richmond)
>>References: <1993Aug18.143612.1137@comtch.computech.spk.wa.us>
>>
>>For what it's worth, we have a com server running Interactive and servicing
>>six incoming lines on a rotary.  A major function is access to an Internet
>>feed for telnet/rlogin to other systems/networks.  Seems to work fine.
>>
>I just set up a customer to dial in to our system, and he had the
>same problem.  This is an old problem, I had just forgotten about
>it.  It's a bug in the driver for the Digiboard (pc/8e) that we have.
>We tried a later driver from Digiboard, but it was even worse (crashed
>the system frequently).  This is on a 386 with Intel SVR3.2 Unix.
>Rlogin works, but telnet does not.
>Perhaps you do not have a Digiboard, and the original poster with the
>problem does, or different versions of the driver (and O/S) are involved.

I have the same problem with ISC 2.2 w/o a Digibored.  I remember seeing 
a note on comp.sys.sysv386 about the problem being a bug in the telent
program not properly picking up the stty settings.  A 'workaround' is
to rlogin to yourself then telnet away.

If you find a better solution, please pass it along (or post).

-- 
Alan Edmonds                                     Texas Instruments, Inc.
I don't speak for TI; TI doesn't speak for me    M/S 8515
Work phone: (214)575-6427                        6620 Chase Oaks Blvd.
Email: edmonds@lobby.ti.com                      Plano, Texas  75023

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Aug 93 23:30:50 GMT
From:      nboddie@nyx.cs.du.edu (Jonny Quest)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Dial-up

Greg Tilford <gtilford@lobby.ti.com> writes:


>Does anyone have a list of companies (or just a company that they are happy 
>wity) that provide service for dial-up Internet access?  I want more than just 
>E-mail, such as the ability to read/post to news groups, Telnet, FTP, etc...
 
>Thanks in advance, 
 
>Greg Tilford
>E-mail: gtilford@lobby.ti.com

Try Colorado Supernet - (303)273-3471

They have it all...


-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 00:19:36 GMT
From:      ldg@scott.skidmore.edu (Leo D. Geoffrion)
To:        comp.protocols.tcp-ip
Subject:   Re: PSI as an Internet provider

We've been a customer since '89 via NYSERNet.  PSI's support has been
excellent. Their SNMP management is superb.  They've always been very
fast to fix any problems that arise. 

I remember, for example, when our line went down during a protracted
strike by the local telephone company.  They somehow got the line
repaired within a day!

As a small school, it has been very convenient to have a service where
they maintain everything from the AUI outward.  It's expensive, but
not as bad as having to maintain your own networking experts.

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

In article <1993Aug20.172842.3257@glv.uucp>,
Frank Bounds <bounds@gulaam.glv.com> wrote:
>
>Anyone have experience using PSI as an internet provider? Any
>comments? Good, bad or so so experiences? We have narrowed down to
>a couple of providers in the Ralegh, NC area. A provider that has
>connections to the east coast CIX is desirable. Thanks in advance!
>


-- 
Leo Geoffrion, Skidmore College Computer Services, Saratoga Springs, NY 12866
EMAIL: ldg@scott.skidmore.edu   VOICE: (518) 584-5000 Ext. 2919


-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 93 01:40:58 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

In article <jtqoif4@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <TABUSDAL.93Aug20081007@ulrik.uio.no>, tabusdal@ulrik.uio.no (Tor Abusdal) writes:
>> Does anyone have any numbers for the expected performance of NFS and TCP/IP
>> over networks with a raw speed of 1Gb/s? I am particularly interested in SunOS
>> and Solaris 2.x as platforms.
>> At what raw network speed does the limiting factor become OS+TCP overhead? I'm
>> finding it difficult to obtain measured performance data for FDDI/CDDI and ATM.
>> Do the current TCP implementations in SunOS and Solaris do header prediction?
>> Is there any PD SW that includes header prediction, TCP window scaling
>> (RFC1323) and/or other aids to high performance?
>> With thanks in advance for any help,
>> 
>> Ron Jones
>> (c/o tabusdal@ulrik.uio.no, fax: +47 22 41 32 10)
>
> [ stuff deleted]
>
>As for TCP/IP overhead, it seems to be universally agreed by those who
>plausibly claim to know about such things that TCP/IP works fine on
>Gbit/sec media.  The protocol processing for each TCP/IP packet can be
>done in less than 200 instructions (Van Jacobson's "squashed stack")
>and enough data cache faulting to get 40 bytes of data.  The cache
>faults are often the bottleneck on modern CPU's, those that can execute
>those 200 instructions in about 1 microsecond.
>
> [more stuff deleted]

We have done some tests using Cray Y-MPs over HIPPI (800 Mbps) networks,
which is as close as you are likely to get to a gigabit for a little
while yet.  We are currently testing a HIPPI/SONET (OC-12C) interface.
The performance numbers seem to correlate to our earlier tests, at least
enough to make it seem worth wile posting in response.

First, tune your host.  The two biggest issues we saw here are big (BIG)
MTU size (at least 32k).  Also, you need to make the window large.  We
found that performance didn't increase much for window sizes much over
about 750-800k, but you for sure will want 512k.  This means window
scaling is a necessity.

Lastly, make sure you have enough memory (boy, this sounds stupid, but
it probably needs to be said).  Remember that the TCP window mbufs need
to be kernel memory (you don't want them swapped out),  so rebuild your
kernel to support this.  In our recent tests, we found throughput
actually FELL when we increased the window over 256k; the reason was
that all the users were competing for mbufs, and we got swapped out.

I guess that the point of this rather rambling message is that (1) you 
need to tune the system, (2) expect to do a fair amount of testing to
determine your system's performance, and (3) don't expect much info from
your vendor (Cray excepted) - you're in terra incognita.

OBTW, our performance dropped slightly over SONET ... not surprising
when you consider that HIPPI is 800 Mbps and OC-12 is 622 (actually
589).

- Ted

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

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 02:24:42 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <1993Aug20.194225.6698@knight.vf.ge.com>, doug@happy.vf.ge.com (Doug Hughes) writes:
> 
> Wait a second..  The original poster asked specifically about BOOTP.
> While many dial in servers may be able to do it, BOOTP can't as far
> as I know. At least nothing in the version of BOOTP that I have indicates
> anything about dynamic IP address assignment.  I would LOVE to be 
> proven wrong on this because we were looking for similar functionality
> out of BOOTP.


Bootp, as in RFC-951 and successors, is a simple protocol in which one
machine asks another various questions, including "since my MAC address
is a:b:c:d:e:f, what is my IP address?"

The protocol says nothing about how the server figures out answers, or
whether the server consistently answers the same question with the same
answer.  It's a straight forward bit of coding to take your favorite
bootp server and make it allocate IP addresses.  Of course, there are
some nontrivial policy issues, like "how long do you associate a given
(MAC,IP) address pair?", and "how soon if ever do you add the IP
address and hostname to network databases?", and "what if the client is
an old client that with a new ethernet board?", and "what does the user
interface for specifying the space of IP addresses look like?", and
"how do a large number of servers allocate from the same space, and not
mess up in the face of network partitions?"


I don't know how you would encapsulate raw BOOP packets for IP address
assignment on a serial line, which is how I read the original question.
(Yes, of course, a bootp forwarder's IP or UDP/IP packets would go over
just fine.)  More important, I can't imagine why you would want to,
given the IP address negotiation mechanism in PPP.  Just have the PPP
code on the server do the work and tell the leaf the answer using the
normal IPCP chit-chat.


Vernon Schryver,  vjs@sgi.com

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 03:49:10 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI access to TCP/IP

In article <CC1vH1.9tJ@sse.ie> keogh@sse.ie (Paul Keogh) writes:
>Loopback and localhost works OK, but when I
>try to contact other TCP/IP servers on my LAN, I get an error from t_connect
>with a terse message of "Invalid argument".
>
>The arg. to t_connect() is just a bcopy() of the sockaddr struct - this struct
>is valid because I can replace the TLI i/f with a BSD socket interface at this
>cut and all works fine.

Alas, it is not that simple.  TLI uses a generic address structure called a
netbuf to hold addresses, and the netbuf is passed to t_connect via the t_call
argument (potentially in addition to options and initial data to be sent with
the connection request).  You need to do something like:

	struct sockaddr_in sin;
	struct t_call tc;

	/* TCP doesn't support options on connect */
	call.opt.len = call.opt.maxlen = call.opt.buf = 0;

	/* no data sent on connect in TCP */
	call.data.len = call.data.maxlen = call.data.buf = 0;

	call.addr.buf = (char *)&sin;
	call.addr.len = call.addr.maxlen = sizeof(sin);
	sin.sin_family = AF_INET;
	sin.sin_port = htons(MY_PORT);
	sin.sin_addr.s_addr = htonl(MY_ADDR);

	r = t_connect(fd, &tc, &tc);

	if (r < 0) {
		if (t_errno == TSYSERR) {
			perror("t_connect");
		} else {
 t_error("t_connect");
		}
	}

You can also use t_alloc to acquire call structures with memory pre-allocated
for addresses, which is probably a better way to do it in practice.  That would
look something like:

	struct t_call *tc;
	struct sockaddr_in *sin;

	tc = (struct t_call *) t_alloc(fd, T_CALL, T_ADDR);
	if (tc == (struct t_call *) 0) {
		perror("t_alloc");
		exit(1);
	}

	sin = (struct sockaddr_in *)call->addr.buf;
	sin->sin_family = AF_INET;
	sin->sin_port = htons(MY_PORT);
	sin->sin_addr.s_addr = htonl(MY_ADDR);

	r = t_connect(fd, tc, tc);
	etc...

Note that I just typed this in off the top of my head, so I may have gotten
a detail or two wrong.  Check out the manual entries for the nitty-gritty.

Good luck,
-- Steve
-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 13:40:27 GMT
From:      larry@gator.oau.org (Larry D Snyder)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

alan@ernest.itg.ti.com (Alan Edmonds) writes:

>I have the same problem with ISC 2.2 w/o a Digibored.  I remember seeing 
>a note on comp.sys.sysv386 about the problem being a bug in the telent
>program not properly picking up the stty settings.  A 'workaround' is
>to rlogin to yourself then telnet away.

Maybe you could try resetting the stty settings prior to using telnet -
or better yet, replace telnet with something from the public domain (or GNU)
archives?

-- 
Larry Snyder                                    Internet: larry@gator.oau.org
Orlando, Florida                            UUCP: ..!uunet!tarpit!gator!larry

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 16:46:21 GMT
From:      timbuck@borg.lib.vt.edu (Tim Buck)
To:        comp.protocols.tcp-ip,comp.unix.pc-clone.32bit
Subject:   Need help building rdist on ISC 3.0

I've been trying (unsuccessfully) to build rdist version 6.1 beta on
Interactive (ISC) SysVR3.2 version 3.0.

Has anyone done this?  If so, would you give me some clues about how to
do it?

Thanks.
-- 

Tim Buck			"Have an excruciatingly pleasant day."
timbuck@borg.lib.vt.edu 	---- (Standard disclaimers apply) ----

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 16:51:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <254srp$dmo@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam) writes:
...

> >> Yes, he/she loses his/her own *unique* IP address :-), ...
> >
> >Why does the customer's machine lose its own, unique IP address?  
> >That one end of a PPP or SLIP link is constrained to the the terminal
> >server's chosen number does not constraing the IP address of the other
> >end of the point-to-point link.
> 
> Because in a typical terminal server which also support SLIP/PPP
> (like a Cisco or an Annex), the IP address it assigns to a serial
> port is actually for the far-end (user-end) of the serial line.

That seems like a dumb way to do things, at least with PPP where
you could force the remote address only when necessary, but I
believe you that some do it that way.

> If the machine calling in has another network interface (e.g. an
> Ethernet interface) in addition to its serial interface, then that
> interface can be used to hold an unique IP address, but if the
> remote machine is a PC with just a serial port and a modem, then
> it is stuck with using the IP address that the terminal server thinks
> it should be using.

It seems like that most people who have their own IP networks will
have a private LAN.

The cost of adding an ethernet to such a machine is rather low,
about $138 and a thinnet terminator.  An ethernet with a single
host works fine.

If the user machine does not have an ethernet, but does have BSD style
network code, it should be able to either use the private IP address
for the loopback interface, or make the IP address an alias on
either the SLIP or PPP or the loopback interface.


Vernon Schryver, vjs@sgi.com

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 18:52:08 GMT
From:      danny@dragon.stgt.sub.org (Daniel T. Schwager)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP traffic/control program


Hi all,

can somebody tell me, where i can find a program, which
measures (log, filter, show, count...) the packets on
 a) IP Level
 b) Ethernet Level (raw ethernet frames)

Thanks

Danny
-- 
                       ,,,
                      (^ ^)               
------------------oOO--(_)--OOo-----------------------
                                                 Danny

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 21:14:44 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <251dmg$ber@genesis.MCS.COM> karl@genesis.MCS.COM (Karl
Denninger) writes: 
>Note that class A addresses are <impossible> to get nowdays.  At least I
>think they're impossible.  I've been told so :-)

No, it is still possible to get a class A address.  The numbers of
class A networks has been growning slowly over the last few years, if
the posted census is any indication.  It is quite hard, however, to
justify the actual need for one.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Aug 1993 21:22:36 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug20.023107.23959@exlog.com> lparsons@exlog.com (Lee
Parsons) writes: 
>After they spend 45 minutes figuring out its not a problem, tell them 
>that the matter should be sent to the legal department for an opinion.

Actually, when the school I went to hooked onto the internet, they
were using someone else's number.  I think that it took less than a
day (or was it only a few hours) for their internet connection to get
yanked pending their upgrade to new, unused IP numbers.  If you
connect to the internet with bogus IP addresses, it will bite you
ASAP.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 02:18:29 GMT
From:      cej@world.std.com (Craig E Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug20.173721.27387@mmm.mmm.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
>We asked for a class A and were promptly refused.  Getting multiple class B's
>at one time is about as hard.  We hope to be able to get a class B for each
>continent.  If I can't get them, there has been a certain contingent internally
>that has been pushing for using unregistered space.  Basically, the IP number
>crunch is causing me internal political squabbles.
>
>--
>Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
>3M IT Network Services			AT&T:	 +1 612 736 7122
>St. Paul, MN				FAX:	 +1 612 736 7689

There's really only one situation where you *might* get away with
using an unregistered class A:

a. You must use a class A which you are unlikely ever to have to talk
to.  Nets 126 (marsnet) and net 10 (the old ARPA net) are just about the
only two candidates.

b. You must use an applications-level, non-fowarding firewall, such
as ANS' Interlock.  The firewall would provide mapping (for each application)
between internal addresses and connections, and external ones.

Note that this situation creates a very definite "everything which is
not specifically legal is prohibited" situation.  This makes it hard
to use new protocols such as gopher, WAIS, [you name it], etc.
-- 
Craig Jackson
cej@world.std.com

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 03:23:36 GMT
From:      btrent@triticom.com (Barry Trent)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Dial-up

In article <1993Aug20.171009.8352@pan.mc.ti.com> Greg Tilford <gtilford@lobby.ti.com> writes:
>From: Greg Tilford <gtilford@lobby.ti.com>
>Subject: Internet Dial-up
>Date: Fri, 20 Aug 1993 19:11:10 GMT


>Does anyone have a list of companies (or just a company that they are happy 
>wity) that provide service for dial-up Internet access?  I want more than just 
>E-mail, such as the ability to read/post to news groups, Telnet, FTP, etc...
 
>Thanks in advance, 
 
>Greg Tilford
>E-mail: gtilford@lobby.ti.com

I dial the internet using slip via MR.NET (Minnesota Regional Network) and I 
get it all, from mail thru news to ftp, gopher, telnet and wais.  Not sure if 
this helps you where you live, but it sure works for me and mine... 
+-----------------------------------------------------------+
| Barry A. Trent            Of course I'm the center of     |
| Triticom                  the universe -- aren't you?     |
| Box 444180                                                |
| Eden Prairie, MN 55344   (The usual disclaimers apply)    |
| 612-937-0772                                              |
+-----------------------------------------------------------+

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 05:09:25 GMT
From:      qualtrak@netcom.com (Qual Trak)
To:        comp.protocols.tcp-ip,comp.protocols.tcip-ip.ibmpc
Subject:   NCSA Telnet <-> SCO (not happening)

I'm trying to get my PC's talking to a SCO server via NCSA telnet
version 2.2d or 2.3 (I can't be sure which at the moment)

They talk ok to all the sparks and and HP 9000 on the same network
I can ping the telnet server from the SCO box - I can telnet SCO 25
and talk to sendmail - It's just that the SCO box will not hook up.

Has anyone else seen this? If so - is there a solution?
+----                                                              ----+
John Birchfield - QualTrak Corp (408) 748-9500 x 141
3160 De La Cruz Blvd., Suite 206, Santa Clara, CA  95054
jb@QualTrak.COM
+----                                                              ----+




-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 05:23:12 GMT
From:      robertsr@helios.usq.EDU.AU (roger roberts)
To:        comp.protocols.tcp-ip
Subject:   HELP WITH IBM PC TCP-IP TOOLS

I am a newcomer to TCP-IP but have had complete success with the installation
of three IBM PC based network traffic monitoring applications.
The machine I have is a HP Vectra 386 and a 3COM 3C503 Lan card useing the
10BaseT port.

I would like to obtain an application (PC based) which will notify me of
common network errors eg. duplicate IP addresses , oversize packets etc.
Also I am looking for an application which will perform a traceroute 
function and show the time taken between each hop.

If anybody could assist me with my request for information I would be
most grateful.

Thank-you,

Roger Roberts
University of Southern Queensland
Toowoomba
Queensland
Australia

E-Mail : robertsr@helios.usq.edu.au

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1993 12:46:24 -0400
From:      ceb@access.digex.net (C. E. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Will ping work with the wrong frame type.

You cannot send messages between differing frame types on Ethernet.
The receiving network interface card will reject or ignore frame types
that is has not been programmed to recognize.

Normally TCP/IP traffic uses the Ethernet-II framing but systems (including
your NW server) can be configured to run TCP/IP over either 802.3
or Ethernet-II frames.  A working NET.CFG file for IPX over 802.3 and 
TCP/IP over Ethernet-II using a SMC WD8003 card is included below.


			/ceb\


Link Support
	Buffers 8 1500
	MemPool 4096

Link Driver SMCPLUS
	Protocol IPX 0 ETHERNET_802.3    
	Frame ETHERNET_802.3     
	Frame Ethernet_II        
	Port #1 280 20
	Mem #1 000D0000 2000/10
	Int #1 3

Protocol TCPIP
	PATH SCRIPT     C:\NET\SCRIPT
	PATH PROFILE    C:\NET\PROFILE
	PATH LWP_CFG    C:\NET\HSTACC
	PATH TCP_CFG    C:\NET\TCP
	ip_netmask      255.255.255.0
	ip_address      198.175.225.3
	ip_router       198.175.225.1
	tcp_sockets     8
	udp_sockets     8
	raw_sockets     1
	nb_sessions     4
	nb_commands     8
	nb_adapter      0
	nb_domain       


-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1993 12:54:49 -0400
From:      ceb@access.digex.net (C. E. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Which Novell frame type to use


Use Ethernet_II for the TCP/IP traffic.  Check the warnings about TCP/IP 
and Ethernet_II frames when connecting to Vaxen.  It's somewhere in the 
NW 3.11 TCP Supervisor's manual but I don't have a copy with me to quote from.  Good luck.

			/ceb\

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 07:15:43 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <id.H1X11.852@nmti.com> kunkee@nmti.com (randy kunkee) writes:
>In article <1993Aug20.145354.21675@vdoe386.vak12ed.edu> jepperso@vdoe386.vak12ed.edu (Jay Epperson) writes:
>>
>>Subject: Re: telnet failure under modem login
>>Newsgroups: comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
>>Organization: Virginia's Public Education Network (Richmond)
>>References: <1993Aug18.143612.1137@comtch.computech.spk.wa.us>
>>
>>For what it's worth, we have a com server running Interactive and servicing
>>six incoming lines on a rotary.  A major function is access to an Internet
>>feed for telnet/rlogin to other systems/networks.  Seems to work fine.
>>
>>"This message constructed of recycled bits."
>
>I just set up a customer to dial in to our system, and he had the
>same problem.  This is an old problem, I had just forgotten about
>it.  It's a bug in the driver for the Digiboard (pc/8e) that we have.
>We tried a later driver from Digiboard, but it was even worse (crashed
>the system frequently).  This is on a 386 with Intel SVR3.2 Unix.
>Rlogin works, but telnet does not.
>
>Perhaps you do not have a Digiboard, and the original poster with the
>problem does, or different versions of the driver (and O/S) are involved.

If you set cooked mode off on the Digiboard, then all will work.  I
had this problem, called Digi, asked tech support, they told me what
to do, and it worked.

Jim
-- 
INTERNET:   jdeitch@jadpc.jd.com
UUCP:	    nosc!jadpc!jdeitch
FIDONET:    Jim_Deitch@f723.n202.z1.fidonet.org  (1:202/723)

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 07:17:36 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <CC2z7F.8xv@ernest.itg.ti.com> alan@ernest.itg.ti.com (Alan Edmonds) writes:
>In article <id.H1X11.852@nmti.com>, randy kunkee <kunkee@nmti.com> wrote:
>>In article <1993Aug20.145354.21675@vdoe386.vak12ed.edu> jepperso@vdoe386.vak12ed.edu (Jay Epperson) writes:
>>>
>>>Subject: Re: telnet failure under modem login
>>>Newsgroups: comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
>>>Organization: Virginia's Public Education Network (Richmond)
>>>References: <1993Aug18.143612.1137@comtch.computech.spk.wa.us>
>>>
>>>For what it's worth, we have a com server running Interactive and servicing
>>>six incoming lines on a rotary.  A major function is access to an Internet
>>>feed for telnet/rlogin to other systems/networks.  Seems to work fine.
>>>
>>I just set up a customer to dial in to our system, and he had the
>>same problem.  This is an old problem, I had just forgotten about
>>it.  It's a bug in the driver for the Digiboard (pc/8e) that we have.
>>We tried a later driver from Digiboard, but it was even worse (crashed
>>the system frequently).  This is on a 386 with Intel SVR3.2 Unix.
>>Rlogin works, but telnet does not.
>>Perhaps you do not have a Digiboard, and the original poster with the
>>problem does, or different versions of the driver (and O/S) are involved.
>
>I have the same problem with ISC 2.2 w/o a Digibored.  I remember seeing 
>a note on comp.sys.sysv386 about the problem being a bug in the telent
>program not properly picking up the stty settings.  A 'workaround' is
>to rlogin to yourself then telnet away.
>
>If you find a better solution, please pass it along (or post).
>

Alan,
   Are you by chance using the FAS drivers under ISC, and calling in
on a FAS port?  This was the only time I saw this problem.  Fix was to
upgrade to the latest version of FAS.

Jim
-- 
INTERNET:   jdeitch@jadpc.jd.com
UUCP:	    nosc!jadpc!jdeitch
FIDONET:    Jim_Deitch@f723.n202.z1.fidonet.org  (1:202/723)

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 14:37:13 GMT
From:      hearn@minotaur.dra.hmg.gb (Dave Hearn)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Dial-up


Hi,

if my memory still serves me correctly, the latest list of public access
suppliers is called PDIAL013.TXT - maybe you should do an archie search for
it?

Dave



Barry Trent (btrent@triticom.com) wrote:
: In article <1993Aug20.171009.8352@pan.mc.ti.com> Greg Tilford <gtilford@lobby.ti.com> writes:
: >From: Greg Tilford <gtilford@lobby.ti.com>
: >Subject: Internet Dial-up
: >Date: Fri, 20 Aug 1993 19:11:10 GMT


: >Does anyone have a list of companies (or just a company that they are happy 
: >wity) that provide service for dial-up Internet access?  I want more than just 
: >E-mail, such as the ability to read/post to news groups, Telnet, FTP, etc...
 
: >Thanks in advance, 
 
: >Greg Tilford
: >E-mail: gtilford@lobby.ti.com
 
: I dial the internet using slip via MR.NET (Minnesota Regional Network) and I 
: get it all, from mail thru news to ftp, gopher, telnet and wais.  Not sure if 
: this helps you where you live, but it sure works for me and mine... 
: +-----------------------------------------------------------+
: | Barry A. Trent            Of course I'm the center of     |
: | Triticom                  the universe -- aren't you?     |
: | Box 444180                                                |
: | Eden Prairie, MN 55344   (The usual disclaimers apply)    |
: | 612-937-0772                                              |
 +-----------------------------------------------------------+

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 1993 18:29:47 GMT
From:      danny@dragon.stgt.sub.org (Daniel T. Schwager)
To:        comp.protocols.tcp-ip
Subject:   ka9q special source question

Hi all,

i try to port ka9q (nos) to a new platform. At the moment, i have a
look at the source code, to understand the data-flow through all 
modules. But on one place, there is a call to a subroutine, i couldn't
believe, that this is true:

Send a IP-Packet (UDP):

- modul udp.c 	   send_udp(...) /*send a UDP datagram */
		   {
		     .....
		     ip_send(...);
		     return;
		   }

- Module ip.c      ip_send (...) 
		   {
                        ....	
			net_route(...);
			return;
		   }


- Module iface.c   net_route(...)
		   {
		     .....
		     enqueue(&Hopper,bp);   /* put mbuf (data) into Hopper 
					    for network task returns 0 if OK
		     return;
  		   }

  Here is the first problem: I intend to _SEND_ an ip-packet, but 
  the Hopper is a receive queue:
     config.c:65: struct mbuf *Hopper;    /* Queue of incoming packets */

  Now, the Hopper-queue with my data will be emptying through a
  daemons, another task with the name 'network'.

-  Module iface.c
   network(...)
   {
	....
        bp = dequeue(&Hopper);      /*get one data-packet*/
        ....
	(*ift->rcvf)(ifp,bp);	    /*call a device dependent _RECEIVE_ routine
        ....
   }

So, in my opinion, in the module ip.c (function send_ip) is a wrong call,
i showed above. Not 'net_route' should be called, but ip_route!!
When ip route is called, the data-flow will go fine ! (But i know,
thousands of people use this program without problems ....)

Are there same ka9q-wize to help me to solve this disagreement ??
Maybe somebody could mail me the email-address of the author from
ka9q, Phil Karn.


Thanks and tschau

Danny


-- 
                       ,,,
                      (^ ^)               
------------------oOO--(_)--OOo-----------------------
                                                 Danny

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 93 03:52:58
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <259l30INNodn@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

   >While this may have been part of the justification, it's not the whole
   >reason.  TCP/IP was designed to be robust in the face of network errors.
   >This is why TCP/IP is based on packet switching rather than circuit
   >switching.
   >
   >Everyone who assumes that connections will break immediately is basing
   >their expectations on the way telephones work.  They're used to the call
   >dropping as a result of any failure.  This is actually an indication of an
   >*unreliable* system.  If you accidentally unplug your phone during a call,
   >wouldn't it be preferable that plugging it back in would let you continue
   >the conversation?  This is what TCP/IP attempts to do.
   >
   >The telephone analogy to the PC being turned off is one of the conversants
   >dying.  The telephone system doesn't drop the call when this happens.

I generally agree with what you say.  I actually don't think keepalives
are where the real issue lies (at least with myself it isn't).  I
believe the main issue should be whether a system reacts reasonably and
consistently with respect to the application when a definite disconnect
occurs (note that this is not necessarily the same as TCP internal
consistency).

As a programmer, if the other end of a connection goes away, from my
perspective the very next I/O operation on that connection should FAIL
and I should not need to play games on every I/O operation to figure out
if my connection is up.  In other words, when I write() to a dropped
connection I want my SIGPIPE NOW, not on the next write.  Or when I
read() from a dropped connection, I want a -1 return code NOW, not a 0.

Regards,

Rick

===========================================================================
Rick McCarty                                         Texas Instruments Inc.
mccarty@add.itg.ti.com                               Austin, Texas
===========================================================================

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Aug 93 23:54:35 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet <-> SCO (not happening)


In article <qualtrakCC5ABp.92z@netcom.com> jb@QualTrak.COM writes:
>I'm trying to get my PC's talking to a SCO server via NCSA telnet
>version 2.2d or 2.3 (I can't be sure which at the moment)
>
>They talk ok to all the sparks and and HP 9000 on the same network
>I can ping the telnet server from the SCO box - I can telnet SCO 25
>and talk to sendmail - It's just that the SCO box will not hook up.
>
>Has anyone else seen this? If so - is there a solution?
>+----                                                              ----+
>John Birchfield - QualTrak Corp (408) 748-9500 x 141
>3160 De La Cruz Blvd., Suite 206, Santa Clara, CA  95054
>jb@QualTrak.COM
>+----                                                              ----+
>
>
>

Yes I have seen this.  On SCO XENIX 2.3.2/2.3.3 with TCP/IP 1.01(I think.)  It
was several years ago. 

No I never found a solution other than to switch to CUTCP (now at Rutgers vice
Clarkson).  It had something to do with some of the protocol negotiation (for
the terminal I think).  I picked on SCO for a while but finally just moved to
CUTCP.

Cliff

-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
cliffb@cjbsys.bdb.com


-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 03:47:33 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        alt.winsock,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.win32,comp.protocols.tcp-ip,comp.os.ms-windows.nt.misc
Subject:   Re: Using select() call for receiving datagram (UDP)

In article <1993Aug20.140308.25734@berlioz.nsc.com> my@berlioz.nsc.com (Mike Yip) writes:
>Hi there,
>
>I am trying to use the select() call on FTP Software Inc's winsock and
>it kept returning 0 even I am sending more UDP packets to the station.
>
>I first setup a socket to receive UDP datagrams by doing ...
>	// build s_local structure here
>	s = socket(AF_INET, SOCK_DGRAM, 0);
>	bind(s, &s_local, sizeof(s_local));
>	FD_ZERO(&fd_struct);
>	FD_SET(s, &fd_struct);
>then, I try to read datagrams at every timer event by doing ...
>	while (select(0, &fd_struct, NULL, NULL, &waitTime)>0)

	This should be select(s+1, ... ) otherwise select will alway
	return as it doesn't have to do anything.

	Mark.

>		recvfrom(s, buf, bufLength, 0, NULL, NULL);
>
>The problem is that select() kept returning 0.  And I never get to
>read the incoming packets.  I even try to change the waitTime to a 
>longer time, but select() seems to return right away with zero also.
>
>Can please anyone help?  My setup is ...
>	Dell 486-66 with NE2000 compatible Ethernet cards
>	DOS, FTP Software Inc's TCP/IP Software, MS Window 3.1, winsock.dll.
>
>Please reply to my@berlioz.nsc.com or tchan@berlioz.nsc.com.
>
>-- 
>| Michael Yip			Email: my@berlioz.nsc.com
>| National Semiconductor Corp	Voice: (408) 721-5148
>| 	Of course, this is my own opinion!
>| 	I don't get paid enough to speak for my company.



-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 03:55:06 GMT
From:      bernadet@hatch.socal.com (Mike Bernadett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

> In <TABUSDAL.93Aug20081007@ulrik.uio.no>, tabusdal@ulrik.uio.no (Tor Abusdal)
> writes:
>> 
>> Does anyone have any numbers for the expected performance of NFS and TCP/IP
>> over networks with a raw speed of 1Gb/s? I am particularly interested
>> in SunOS
>> and Solaris 2.x as platforms.
>> At what raw network speed does the limiting factor become OS+TCP overhead?
>> I'm
>> finding it difficult to obtain measured performance data for FDDI/CDDI and
>> ATM.
>> Do the current TCP implementations in SunOS and Solaris do header prediction?
>> Is there any PD SW that includes header prediction, TCP window scaling
>> (RFC1323) and/or other aids to high performance?
>> With thanks in advance for any help,
>> 
>> Ron Jones
>> (c/o tabusdal@ulrik.uio.no, fax: +47 22 41 32 10)
>> 
> 
> In <1993Aug21.014058.3815@ns.network.com>, dotytr@nscultrix2.network.com
> (Ted Doty) writes:
> 
  [stuff deleted]

> First, tune your host.  The two biggest issues we saw here are big (BIG)
> MTU size (at least 32k).  Also, you need to make the window large.  We
> found that performance didn't increase much for window sizes much over
> about 750-800k, but you for sure will want 512k.  This means window
> scaling is a necessity.
> 
> Lastly, make sure you have enough memory (boy, this sounds stupid, but
> it probably needs to be said).  Remember that the TCP window mbufs need
> to be kernel memory (you don't want them swapped out),  so rebuild your
> kernel to support this.  In our recent tests, we found throughput
> actually FELL when we increased the window over 256k; the reason was
> that all the users were competing for mbufs, and we got swapped out.
> 
> [stuff deleted]
> 

Yes, TUNE YOUR HOST !!!!  See Notes at the end of this posting.

Here are some measured numbers with FDDI on Suns:

      Between two Sparc 630 MPs running SunOS
      4.1.3 with dual 40Mhz Cypress processors, standard Sbus FDDI cards
      and 51K (socket) buffers, I can sustain 3.7 MB/sec over FDDI on a TCP
      connection.  CPU utilization is 100%.

      I would expect to do 5 MB or so with a couple dual-SuperSPARC
      workstations running Solaris 2.

      At any rate, you can see the CPU is saturated long before the medium.
      So with a standard Sparc MP configuration you need to allocate about
      three SPARC chips to network processing if you plan to saturate an
      80Mb/sec channel with TCP traffic.  Sun probably decided this was
      easier/more flexible than putting the processing on the FDDI card.

      In this FDDI setup the max. segment size is 4312, since the FDDI MTU is
      4352.  A larger segment size would greatly alleviate the CPU loading if 
      that could be arranged.  It might not be easy to increase the MTU,
      I'm not sure.

      For NFS, READING remote mounted files, throughput is currently
      limited by disk throughput (~2.5 MB/sec. for single SCSI-2 3.5").

      WRITING to a remote mounted file is slow (< 1MB/sec.) due to the lack
      of asynchronous disk writes in standard NFS.

      Notes:
      
      To get decent rates I had to bump up the buffer sizes on the
      connection endpoints (sockets).  In SunOS, for example, the default
      send and receive buffer sizes are 8K each.  For ethernet, the max.
      segment (packet) size is 1496, so with an 8K receive buffer the window
      size is only 5 1496-byte segments!  At a 1MB/sec transmit rate, this
      amount of buffering requires ACKs to come back within roughly 6.7ms to
      maintain continuous transmission.  That's a bit tight considering tcp
      processing is done a couple layers up, in a multitasking multiuser
      kernel, on a general-purpose processor, etc.

      The calls to bump up the buffer sizes are
      setsockopt(socket, SO_RCVBUF, ...) and setsockopt(socket, SO_SNDBUF,
      ...).  -or- you can set a default in the kernel for all TCP sockets
      created on the system.  See /sys/inet/tcp.h (sp?) in SunOS 4.1.X.

      Since on fast media like FDDI, with adequate buffer sizes, the
      bottleneck is usually the CPU, we *may* see some emphasis on on-card
      TCP/IP processing.  On the other hand, since the code is already in
      place running on the CPU, and SMP systems are becoming widespread,
      it may be more cost effective just to slap in a couple extra
      processor modules along with the high speed network card.


-- 
Mike Bernadett   (NIC MB478)                          bernadet@hatch.socal.com

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 93 11:14:24 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <259l30INNodn@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
>>I've picked up from this newsgroup the fact (?) that the original designers of
>>TCP/IP were dealing with low-speed links at the time of the design, and
>>therefore couldn't waste scarce network bandwidth on packets which contain no
>>data (keepalives).
> 
> While this may have been part of the justification, it's not the whole
> reason.  TCP/IP was designed to be robust in the face of network errors.
> This is why TCP/IP is based on packet switching rather than circuit
> switching.
> 
> Everyone who assumes that connections will break immediately is basing
> their expectations on the way telephones work.  They're used to the call
> dropping as a result of any failure.  This is actually an indication of an
> *unreliable* system.  If you accidentally unplug your phone during a call,
> wouldn't it be preferable that plugging it back in would let you continue
> the conversation?  This is what TCP/IP attempts to do.
> 

Be careful with absolutes like "everyone". I believe my expectations are based
on AppleTalk's ATP protocol and Xerox's SPP protocol, and by the feeling that
if the Transport layer informs me when my connection has been established (by
completing my select(), perhaps), then it should also inform me when the
connection breaks. Recognizing that dead connection establishment requires
resources, I'm willing to tell it how important detection is to me, by telling
it the number of round-trip delays during which I'm willing to allow a dead
connection to remain.

Of course I'd like to permit the connection to recover from a network error,
but is it really likely to recover after two hours? And what about applications
where the network is reasonably reliable? They shouldn't have to wait that
long.

> -- 
> Barry Margolin
> System Manager, Thinking Machines Corp.
> 
> barmar@think.com          {uunet,harvard}!think!barmar


John Saunders
saunders@eisner.decus.org

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1993 05:37:36 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug19.214352.375@eisner.decus.org> saunders@eisner.decus.org writes:
>I've picked up from this newsgroup the fact (?) that the original designers of
>TCP/IP were dealing with low-speed links at the time of the design, and
>therefore couldn't waste scarce network bandwidth on packets which contain no
>data (keepalives).

While this may have been part of the justification, it's not the whole
reason.  TCP/IP was designed to be robust in the face of network errors.
This is why TCP/IP is based on packet switching rather than circuit
switching.

Everyone who assumes that connections will break immediately is basing
their expectations on the way telephones work.  They're used to the call
dropping as a result of any failure.  This is actually an indication of an
*unreliable* system.  If you accidentally unplug your phone during a call,
wouldn't it be preferable that plugging it back in would let you continue
the conversation?  This is what TCP/IP attempts to do.

The telephone analogy to the PC being turned off is one of the conversants
dying.  The telephone system doesn't drop the call when this happens.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 93 06:03:38 GMT
From:      esasaki@nyx.cs.du.edu (Eric Sasaki)
To:        comp.org.acm,comp.protocols.tcp-ip
Subject:   TCP/IP Performance Monitoring Summary

Thank you to all who responded to my post concerning TCP/IP performance
monitoring.  The various responses included some advice on how to go about
measurement, specific products, and even offers for consulting and custom
tailored solutions.  I appreciate all of the help, and although I cannot
make a decision on behalf of U S WEST Communications, I will pass your info-
rmation along to those most likely to have the authority to do so.

As a preface to my comments, I would like to clarify what we are trying to do.
I'm afraid that I did not go into enough detail in regards to our specific
requirements in my original post, as evident by some of the responses.  Again,
we are looking for tools and methods that we could use to monitor and measure
performance of a TCP/IP internal data network.  This network, which will have
access to the Internet, will cover the entire 14-state region of U S WEST.
The network is designed to handle all of our internal client needs, including
electronic mail, FTP, telnet, and bulk data transfer, and will eventually
support over 30,000 users on primarily UNIX-based (Sun) platforms.

Obviously, we need to be able to monitor the network and detect performance
problems, as well as gather statistics for utilization and planning purposes.
We currently rely on a hardware/application solution developed by Emcom Corp.
of Texas, which logs all transactions on a statistical sample of dedicated
synchronous user lines and dumps the data to a central host.  The region-
wide data is compiled and reported through SAS.

We realize that in the TCP/IP world monitoring performance will be a much more
difficult task.  Now, simply measuring end-to-end response time will not and
cannot be how we intend to monitor our corporate internet.  However, we have
very little first-hand experience in TCP/IP monitoring, hence my inquiry.

With that, here are the specific suggestions:

HARDWARE:
Network General's Sniffer was mentioned by almost everyone as a good monitoring
device.  We agree--we have been using it for quite some time.  However, we
find the following deficiencies with the Sniffer:

1.) It is primarily a real-time monitoring device in our implementation.  Due
to cost considerations, we use the Sniffer in spot-trouble shooting.  As a
result, we often do not have historical Sniffer recordings to analyze.  It's
a case of closing the barn door after the horse is out.

2.) We would need lots of Sniffers.  To provide comprehensive coverage, we
would need to place a Sniffer on every leg of our net, which is not cost-
effective.

3.) There's no way to collect region-wide data.  Isolated recordings of Sniffer
data do not do us any good.  We really need a formatted daily report on net
performance, broken down into various categories.  The only way to obtain this
via Sniffer is to have a dedicated network for all the Sniffers.

SOFTWARE:
Quite a few packages were suggested, including NetMetrix, ANVL, NetMan,
Etherman, Interman, Packetman, and LANalyzer.  However, all of the packages
monitor the Ethernet segment of the network, not the TCP/IP portion.  We do
recognize the need to look at the Ethernet side of things, but we need a
complete picture of how the network is running.

Again, we also run into the problem of collecting and analyzing the information
we get from remote monitoring sites.  We're talking about literally hundreds
of LANs in perhaps 10 MANs.  We know it is not going to be easy. :)  In fact,
we're not sure if it is even possible.  But we do know that we *must* be able
to troubleshoot problems and provide consistent service.

That's it!  Again, thank yous to everyone who dropped me a note in the past
week or so.  As far as offers for consulting or contracting, I have forwarded
your names and addresses to those who can consider such things.

Also, if you have thought of something new that we could try, or if you didn't
respond earlier, I welcome your ideas.  Our company can use as much input as
possible!  I'll be here until mid-September before I head back to Georgia Tech.  
Warm regards,

Eric Sasaki
Intern, U S WEST Communications, IT Services Sustaining Engineering
(303) 624-3568
esasaki@nyx.cs.du.edu

--
Eric Masao Sasaki     Undergrad INTA, Georgia Tech     gt7294b@prism.gatech.edu
-------------------------------------------------------------------------------
Whoever you are--I have always depended on the kindness of strangers.
			      -- Tennessee Williams, _A_Streetcar_Named_Desire_

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 07:13:15 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug20.225542.388@eisner.decus.org> saunders@eisner.decus.org writes:
>In article <1993Aug20.084128.22735@novell.com>, donp@novell.com (don provan) writes:
>> The point has always been and remains today that those resources are
>> every bit as valuable no matter *why* the client stopped talking.  The
>> TCP keepalive feature only detects a single cause of the failure:
>> disrupted TCP communications.  So although keepalives reduce number of
>> problems, they do not eliminate them all.  A simple timer is at least
>> as easy to use on most systems, and it provides a simpler mechanism
>> for detecting a stalled connection in general including the cases
>> where communications with the remote TCP are still fine.
>> 
>
>What kind of "simple timer" do you mean? Could you give an example?

Sure.  The simplest is a read timeout.  Most TCP/IP implementations
support waiting for data with a timeout using the function "select".
Using such a facility, just add a timeout to each read.  If the
application doesn't receive any data from the client after whatever
timeout you like, it considers the client no longer worth supporting
and recovers all the associated resources.

With timers that aren't tied to the I/O system, it's only a little
more effort, but still fairy straightforward.
						don provan
						donp@novell.com

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 93 13:13:15
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

In article <CC71Jv.C5L@hatch.socal.com> bernadet@hatch.socal.com (Mike Bernadett) writes:

	 >Between two Sparc 630 MPs running SunOS
	 >4.1.3 with dual 40Mhz Cypress processors, standard Sbus FDDI cards
	 >and 51K (socket) buffers, I can sustain 3.7 MB/sec over FDDI on a TCP
	 >connection.  CPU utilization is 100%.
 
	 >I would expect to do 5 MB or so with a couple dual-SuperSPARC
	 >workstations running Solaris 2.

Dunno.  Hardware sounds up to the task of sustaining that kind of throughput.
But I'd be concerned about the Solaris 2 part of the equation. :_) :_) :_)

--RJMc

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1993 16:08:51 -0400
From:      themos@umbc.edu (Mr. Themos Pentakalos)
To:        comp.protocols.tcp-ip
Subject:   CNX Certification

Hi everyone,

Has anybody heard anything about the CNX Certification from Network 
General and Hewlette Packard?

I would like to know what the market things of this certification. Has
it gotten any acceptance yet? It is rather new and I have gotten the
information for it. I am just not sure whether it's worth going for
or not.

Any comments? Please reply directly to  themos@Umbc7.umbc.edu

Thanks a lot,
Themos

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 16:28:37 EDT
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: Wanted: Info on IBM router (6611 model 120)

You might be interested in searching the IBMTCP-L notebook archives
via listserv@pucc.princeton.edu.  Send THIS to it via e-mail --

/* --------------------- clip and save ---------------- */
//ListSrch JOB Echo=no
Database Search DD=Rules OUTLIM=5000
//Rules DD *
S 6611 in ibmtcp-l
index date.8 sender.30 subject.40
print
/*
//  EOJ
/* --------------------- clip and save ---------------- */

/Pete (pmw1@psuvm.psu.edu)
--
Peter M. Weiss         "The 'NET' never sleeps"           +1 814 863 1843
31 Shields Bldg. -- Penn State Univ -- University Park, PA USA 16802-1202

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 13:46:35 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip
Subject:   DNS config & nslookup question


I'm using Dell's SYS V r4 package.

I've configured the DNS files.

When a machine name is used, nslookup finds it and reports the address.

When an address is used to find the machine name,
nslookup always returns the address in brackets,
and does not report the machine name.

Where have I done wrong? I've created the inverse mapping file.

Dean
-- 
  /`-_                                 
 {     }/  Dean.Roth@MIXcom.com         
  \   */   Milwaukee, Wisconsin, U.S.A. 
   |___|                                

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 93 18:48:58
From:      mccarty@add.itg.ti.com (Rick McCarty)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug23.213535.2059@icaen.uiowa.edu> dsiebert@icaen.uiowa.edu (Doug Siebert) writes:

    >Writing to disk gives you an option to wait until I/O is completed
    >(O_SYNC) which can be useful in some circumstances.  It would probably
    >be of benefit for some applications if a similar mechanism was available
    >for network writes.  It could certainly be made more efficient building
    >this into the Unix kernel rather than relying on the application
    >programmer needing to add a separate acknowledgement protocol to his/her
    >program.

Precisely!  Thanks Doug for summing up things up into a nice example.

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 14:04:30 GMT
From:      swn@ocsystems.com
To:        comp.protocols.tcp-ip
Subject:   Re: PSI as an Internet provider

We have been using PSI for our Internet feed for about 6 months.
Our installation went quite well, they even predicted a couple of
problems we would have and told us how to avoid them.  They were
quite helpful with our software setup as well, even when we told
them we were using an IBM PC/RT as a gateway (they didn't laugh
too hard).  They helped us set up our news feed about a month
ago; again, very good service.  Just last week we had to physically
move our gateway computer and we unplugged it.  Within 15 minutes
they were on the phone with us to see if we had a problem they 
could help us with.  We are very happy with PSI.

Steven North 
swn@ocssystem.com


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 16:52:05 GMT
From:      usramasa@uncc.edu (Usharani Ramasamy)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI ERROR


This is is regarding typo-error in my TLI server code 

which I posted on Aug 20th.......


Please ignore open parenthesis after t_listen () call..


Sorry for the error..

Thanks,

usha


-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 17:05:57 GMT
From:      waynej@ncs.com (Wayne Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <ccooperCC0rCs.719@netcom.com> ccooper@netcom.com (Chris Cooper) writes:
>I just established a dial-in PPP connection to my Service Provider (Netcom)
>and they assigned me a static IP address.  I notice that is also possible
>to dial in and use BOOTP to assign an address dynamically.  My question is:

I've been trying to do this with the cisco server at the U of MN, does anyone
have a BOOTP client program that can talk to the bootp server?
-- 
Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
     National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
                                           - Jim Elliott

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 17:40:52 GMT
From:      lpc@dickens.com (Luis P Caamano)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug19.163205.20462@ajax.rsre.mod.uk> hearn@minotaur.dra.hmg.gb (Dave Hearn) writes:
>WiseGuy (sysdhw@atscv1.gsfc.nasa.gov) wrote:
>: There are some people who are thinking of using an unregistered Class A
>: address for their IP network.  I am not a fan of this idea.  A direct
>: connection from the Internet would then be unlikely ;-), but they would
>: then have all of the addresses they could possibly need.
 
>: I'm looking for some good PLUSES and MINUSES to pass along to them (to
>: help them in the decision making process).
>
>
>Well,
>
>they could do that.. but then .. I assume they never ever want to be connected
>to the net in the future..  Forever is a long time!
>
>I would hate to be the guy who had to administer a massive overnight 
>reassignment of Internet addresses across such a net. They sure would have to 
>if they chose to follow the unassigned class A net route.
>
>
>Dave 

I know of a company that, for security reasons, uses an unregistered
class A address on purpose to make sure they never get connected to
the internet.   If they ever need to connect to the Internet, they'll
get a sneaker-net router.


-- 
Luis P. Caamano  (LC2385)              |         lpc@dickens.com
Dickens Data Systems, Inc. Atlanta, GA |         uunet!dickens.com!lpc
---------------------------------------------------------------------------
If I think I know it all, I'll stop learning. -myself
The more I learn, the more I know I know nothing. -somebody else

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1993 18:29:12 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <MCCARTY.93Aug23035258@aphid.add.itg.ti.com> mccarty@add.itg.ti.com (Rick McCarty) writes:
>I generally agree with what you say.  I actually don't think keepalives
>are where the real issue lies (at least with myself it isn't).  I
>believe the main issue should be whether a system reacts reasonably and
>consistently with respect to the application when a definite disconnect
>occurs (note that this is not necessarily the same as TCP internal
>consistency).
>
>As a programmer, if the other end of a connection goes away, from my
>perspective the very next I/O operation on that connection should FAIL

Unfortunately, due to the distributed nature of network processing, this
can be difficult to provide if you also want good performance in the normal
case.  In order to make the write() fail, it has to wait until it gets
either an acknowledgement or a reset, so it will know whether to return
success or failure.  If you're writing across a slow link (satellite,
SLIP/PPP, or any connection with many hops) this delay on every write is
likely to be a major bottleneck in the application.  It mostly negates the
throughput benefit of TCP's sliding window protocol.

This is why lots of things in TCP/IP don't get noticed until one or two
operations later.  It takes a long time (in computer time) to find out the
state of a machine across the network.  So write() just queues the packets
for transmission and returns immediately.  When a timeout occurs or a reset
comes back, the state of the socket is changed and the next operation
fails.

This is similar to operations on disks.  When you write() to a file, the
data is copied to a kernel buffer and a write is queued.  If the disk fails
you may not be notified until you close().

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1993 18:39:09 GMT
From:      Charles Menser <charles@peachnet.edu>
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Wanted: Info on IBM router (6611 model 120)

I am looking for any and all information about IBM's routers, in
particular the 6611 model 120.

- How fast does is forward packets?
- Which network protocols does it support? How many concurrently?
- Which TCP/IP routing protocols does it support?
- Any other information about it.

I would like to hear any views on the product, any problems, etc.

Please reply by mail.

Thanks,
Charles
-----
Charles Menser				"Why did you pour ink on my head?"
News Admin., PechNet				--- Yosemite Sam
charles@peachnet.edu

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 18:52:24 GMT
From:      adams_g@jdola.lanl.gov (Gavin Adams)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   ACK's, but no data sent

I'm getting into the wonderful world of MS Windows TCP/IP programming (via the 
winsock interface), and have run into more problems in one week then I ever 
had under UNIX.  One good thing is I'm getting to learn the lower-level stuff. 
:)

Now for my question/problem:

I trying to write a client application that talks to a proprietary service 
running under SCO UNIX.  I send () the data to the machine, and in it's own 
way it returns the information... after my client sends an ACK,FIN. Here's a 
brief description of what the protocol analyzer is showing on the packets:

Packet#	Client	Server	Description
-------	------	------	-----------
1	SYN
2		SYN,ACK
3	ACK
4	ACK		And sends data ("abcdef")
5		ACK
6	ACK		At this point I select ()
			w/ read and 5 second time-
			out value
7	ACK,FIN		Never got data so connec-
			tion closes
8		ACK
9		ACK,PSH	And returns data ("abcdef")
10		ACK,FIN
11	ACK
12	ACK

Should my client send an ACK,PSH when it sends data?  Does it need to?  Why is 
the server only sending data when a FIN is sent to it?  Is there any way under 
winsock to simulate this?

I took a look at the server, and all they use are read/write statements for 
thier sockets.  All I can use are send/recv function calls.

Thanks in advance for any help you might be able to give me.

--- Gavin

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 93 19:35:46 GMT
From:      egan@cbs.cis.com (Egan F. Ford)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Hubs, which one to use?


I have a TCP/IP network of 2 Servers, 13 workstations and 2 printers all on
10base2 (thin net).  We're moving to a new building with 10baseT wire.  All I
need now are some Ethernet hubs.  Can someone recommend some?  I need to know why
you recommend them, cost, where to get them, quality of documentation,
installation ease, and technical support.


Thanks.


-- 
Egan F. Ford
egan@cbs.cis.com

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 19:46:01 GMT
From:      alan@ernest.itg.ti.com (Alan Edmonds)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <CC5G9C.FM@jadpc.cts.com>, Jim Deitch <jdeitch@jadpc.cts.com> wrote:
>Alan,
>   Are you by chance using the FAS drivers under ISC, and calling in
>on a FAS port?  This was the only time I saw this problem.  Fix was to
>upgrade to the latest version of FAS.

My configuration was with a Comtrol Hostess dumb 4 port card.  I wasn't
using the FAS drivers with it, but a driver supplied by Comtrol.  But,
if upgrading to a different version of FAS fixed it for you, that may
be a key to the problem/fix.  I'll try installing FAS on my standard
tty00/tty01 and see if that fixes things.  BTW, is this wit FAS2.10 
or the now-in-beta FAS 2.11?

-- 
Alan Edmonds                                     Texas Instruments, Inc.
I don't speak for TI; TI doesn't speak for me    M/S 8515
Work phone: (214)575-6427                        6620 Chase Oaks Blvd.
Email: edmonds@lobby.ti.com                      Plano, Texas  75023

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 20:24:57 GMT
From:      mac@mercury.Harris-ATD.com (Mike McDonald)
To:        comp.protocols.tcp-ip
Subject:   PD spanning tree bridge code needed

  I'm in need of a public domain implementation of a bridge that implements a
spanning tree algorithm. This is for use in a network simulator so C code would
be prefered.

  Thanks,

  Mike McDonald				Advanced Technology Dept.	
					Harris Corp.
  Email: mac@trantor.harris-atd.com	M.S. 16-1912
  Voice: (407) 727-5060			P.O. Box 37
  Fax:   (407) 729-3363			Melbourne, Florida 32902


-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 21:35:35 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

barmar@think.com (Barry Margolin) writes:

>In article <MCCARTY.93Aug23035258@aphid.add.itg.ti.com> mccarty@add.itg.ti.com (Rick McCarty) writes:
>>I generally agree with what you say.  I actually don't think keepalives
>>are where the real issue lies (at least with myself it isn't).  I
>>believe the main issue should be whether a system reacts reasonably and
>>consistently with respect to the application when a definite disconnect
>>occurs (note that this is not necessarily the same as TCP internal
>>consistency).
>>
>>As a programmer, if the other end of a connection goes away, from my
>>perspective the very next I/O operation on that connection should FAIL
 
>Unfortunately, due to the distributed nature of network processing, this
>can be difficult to provide if you also want good performance in the normal
>case.  In order to make the write() fail, it has to wait until it gets
>either an acknowledgement or a reset, so it will know whether to return
>success or failure.  If you're writing across a slow link (satellite,
>SLIP/PPP, or any connection with many hops) this delay on every write is
>likely to be a major bottleneck in the application.  It mostly negates the
>throughput benefit of TCP's sliding window protocol.
 
>This is why lots of things in TCP/IP don't get noticed until one or two
>operations later.  It takes a long time (in computer time) to find out the
>state of a machine across the network.  So write() just queues the packets
>for transmission and returns immediately.  When a timeout occurs or a reset
>comes back, the state of the socket is changed and the next operation
>fails.
 
>This is similar to operations on disks.  When you write() to a file, the
>data is copied to a kernel buffer and a write is queued.  If the disk fails
>you may not be notified until you close().


Writing to disk gives you an option to wait until I/O is completed (O_SYNC)
which can be useful in some circumstances.  It would probably be of benefit
for some applications if a similar mechanism was available for network writes.
It could certainly be made more efficient building this into the Unix kernel
rather than relying on the application programmer needing to add a separate
acknowledgement protocol to his/her program.

-- 
Doug Siebert     dsiebert@isca.uiowa.edu
"Had this been an actual emergency, we would have fled in terror, and you would
not have been informed."  --Someone more clever than I

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 22:52:33 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Internet diameter?

RFC-1122 states that a default IP TTL should be "at least big enough for the
Internet diameter, i.e., the longest possible path".  Then it recommends
that it be __twice__ the diameter to allow for growth.

Any idea what the current "diameter" is?

-- Ken Mintz

PS:  I am told that 30 is too low now and that some/many/most systems now
default to 60.  But if 30 is too low now, 60 seems too low, according to the
"twice diameter" recommendation.  Are there systems that default to something
__higher__ than 60?  Which and what?

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Aug 1993 23:49:00 GMT
From:      fcn@ubvax.ub.com (Fredrik Noon)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <MCCARTY.93Aug23035258@aphid.add.itg.ti.com>, mccarty@add.itg.ti.com (Rick McCarty) writes:
> 
> As a programmer, if the other end of a connection goes away, from my
> perspective the very next I/O operation on that connection should FAIL
> and I should not need to play games on every I/O operation to figure out
> if my connection is up.  In other words, when I write() to a dropped
> connection I want my SIGPIPE NOW, not on the next write.  Or when I
> read() from a dropped connection, I want a -1 return code NOW, not a 0.

I think that many of the responses converge to something like this, but I'll say it from my
perspective, having done a fair amount of non-UNIX (PCs, MACs) TCP/IP and OSI implementation:

One may not assume that the Transport layer is executing on the same CPU and/or OS as the peer
application: in a layer X, if one X-entity needs to know if another X-entity is still "alive,"
it *must* communicate directly with that entity.  E.g., Ungermann-Bass makes (well, up until this
month!) 80186 PC adapter cards, and its TCP/IP stacks can (could) run either on-card or on-host
(NDIS).  If the PC application gets fried, and Transport is down on the card, it may quite happily
ACK away with another Transport for quite a while.  One must always keep in mind that it is the
*protocol* which is (supposed to be) system-independent; interfaces and configuration are, as they
say in OSI-Land, "a local matter."

-- Fredrik Noon, fcn@ubvax.ub.com
   (But don't count on me being at this address for long, as I'm looking for a new job!)


-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 93 00:53:35 GMT
From:      varuni@ee.uts.edu.au (Varuni Witana)
To:        comp.protocols.tcp-ip
Subject:   sending >2048 using raw sockets

I need to send FDDI MTU size packets using raw sockets. But there seems to be a
limitation  of 2048 bytes, is there anyway I can overcome this?

Thanks in advance
Varuni Witana
varuni@ee.uts.edu.au

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1993 02:00:37 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet diameter?

KM> == Ken Mintz <mintz@cup.hp.com>

 KM> RFC-1122 states that a default IP TTL should be "at least big enough
 KM> for the Internet diameter, i.e., the longest possible path".  Then it
 KM> recommends that it be __twice__ the diameter to allow for growth.

RFC1340 says:
   The current recommended default time to live (TTL) for the Internet
   Protocol (IP) [45,105] is 64.

That, presumably, takes into account the projected diameter growth; I
rarely if ever have to up the traceroute default TTL of 30.  (Or maybe I'm
just centrally located :)

--
 # Christopher Davis # <ckd@kei.com> # <ckd@eff.org> # [CKD1] # MIME # RIPEM #
``"mail" is an _uncountable_ noun.  Like water, or spam, it is not treated
  grammatically as if it had natural, countable smallest units (except perhaps
  in Monty Python skits).''  -- Alfred Kriman <kriman@acsu.buffalo.edu>

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 02:57:34 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <CC89Kt.Kz5@ernest.itg.ti.com> alan@ernest.itg.ti.com (Alan Edmonds) writes:
>In article <CC5G9C.FM@jadpc.cts.com>, Jim Deitch <jdeitch@jadpc.cts.com> wrote:
>>Alan,
>>   Are you by chance using the FAS drivers under ISC, and calling in
>>on a FAS port?  This was the only time I saw this problem.  Fix was to
>>upgrade to the latest version of FAS.
>
>My configuration was with a Comtrol Hostess dumb 4 port card.  I wasn't
>using the FAS drivers with it, but a driver supplied by Comtrol.  But,
>if upgrading to a different version of FAS fixed it for you, that may
>be a key to the problem/fix.  I'll try installing FAS on my standard
>tty00/tty01 and see if that fixes things.  BTW, is this wit FAS2.10 
>or the now-in-beta FAS 2.11?
>

Could be the same problem.  I was using FAS 2.08 (If I remeber right)
when I asked Uwe about the problem.  He said that part of it was due
to the fact that there are about 3 different sleeps in ISC.  Whatever
he changed in the newer release worked.  If you have the option in
your Comtrol driver, turn off cooked mode.  I had a similar problem
with a Digi COM8/i driver and this was the fix.  You might want to ask
Uwe for specifics on the FAS problem.

Jim
-- 
INTERNET:   jdeitch@jadpc.jd.com
UUCP:	    nosc!jadpc!jdeitch
FIDONET:    Jim_Deitch@f723.n202.z1.fidonet.org  (1:202/723)

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 03:49:42 GMT
From:      btrent@triticom.com (Barry Trent)
To:        comp.org.acm,comp.protocols.tcp-ip
Subject:   Re: TCP/IP Performance Monitoring Summary

In article <1993Aug23.060338.26192@mnemosyne.cs.du.edu> esasaki@nyx.cs.du.edu (Eric Sasaki) writes:
>From: esasaki@nyx.cs.du.edu (Eric Sasaki)
>Subject: TCP/IP Performance Monitoring Summary
 
>2.) We would need lots of Sniffers.  To provide comprehensive coverage, we
>would need to place a Sniffer on every leg of our net, which is not cost-
>effective.

There are alternatives... For example, my firm makes a software-based analyzer 
which can convert capture files to/from Sniffer (and other) formats.  Thus, if 
Sniffer is your "master analyzer" of choice, you might still be able to afford 
to have lots of "probes" which were copies of our (or someone elses) software. 
Our software for Ethernet, called LANdecoder/e, costs less than $1k. It does a 
lot more than I have just described, but that is one of it's functions...

Be glad to send you more info, or you can download demos from our BBS at 
612-829-0135.
+-----------------------------------------------------------+
| Barry A. Trent            Of course I'm the center of     |
| Triticom                  the universe -- aren't you?     |
| Box 444180                                                |
| Eden Prairie, MN 55344   (The usual disclaimers apply)    |
| 612-937-0772                                              |
+-----------------------------------------------------------+

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1993 06:51:02 GMT
From:      bindi@ewd.dsto.gov.au (Bindi Harding)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Information please?

Hi everybody...

I'm looking for some information (fairly explanatory stuff) about TCP/IP,
and I know there's an ftp site _somewhere_ although I'm not sure where.

Could somebody out there give me a hint please? :-)

Also, I'm looking at implementing the sliding window protocol in C.  How
easy or difficult is this, and are there any major problems I may come across
that I should know about?

Any help appreciated with a smile. <smile>

Bindi

-- 
Bindi Harding                       E-mail: bindi@ewd.dsto.gov.au
Electronic Warfare Division         Phone: (08) 259 5952
DSTO Salisbury, South Australia

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1993 09:53:31 GMT
From:      rudi@chem.rug.nl (Rudi van Drunen)
To:        comp.protocols.tcp-ip
Subject:   DNS for PC

Hi all !!

I'm not sure if this is the correct newsgroup for this, but anyways:
I am looking for a (preferably Public DOMAIN) program that runs a Domain
Name server on a PC (dos) machine. 

Any hints will be appriciated, please Use E-mail.

rudi

-- 

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

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 93 11:58:25 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

Doug Siebert <dsiebert@icaen.uiowa.edu> writes:

	Writing to disk gives you an option to wait until I/O is
	completed (O_SYNC) which can be useful in some circumstances.
	It would probably be of benefit for some applications if a
	similar mechanism was available for network writes.

Duh?  This is indeed one strategy for cleaning up scarce resources in a
server.  If the server periodically sends out a message to all clients,
you'll find rather quickly which ones are dead.  This is *not* the
problem people are complaining about -- that of the client going away
(by "go away" I mean the protocol stack on the machine, such as when
you powerdown a PC, not where a process or the like is disconnected and
the protocol stack stays active) and the server never "notices" because
there's no data flowing.  This is usually because servers don't
initiate communication, only respond to queries.

The classic tradeoff you (as server implementor) must decide for
yourself is how quickly do you want to reclaim resources in the face of
the possibility that nothing is going on with the connection.  Consider
the case where you say (arbitrailiy) that after 5 minutes of idle time,
you want to try to determine the state of the client connection.  If
you send an application keepalive message, and the client really is
idle (not "gone"), and you just happen to send it while some Jane Blow
somewhere is swapping out the power supply of a router, and it takes
her more than 30 seconds to do it, your keepalive message will time out
and you'll (unnecessarily) tear down the connection.

Whether or not reconnection in the face of a disconnect is a problem to
you (maybe that link is a dial-on-demand PPP link?) the way you answer
the question can get hairy.  Say the first thing that a client does
when they reconnect is to query lots of state.  Now it becomes
"expensive" to reclaim your precious file descriptor ...

-----

Bottom line: the kernel doesn't ask you to do scheduling (though with
the proliferation of threads ... :-(), don't ask the kernel to write
your application.

/jordan

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1993 12:30:58 GMT
From:      cr@cs.strath.ac.uk (Chris Reid)
To:        comp.protocols.tcp-ip
Subject:   Sockets: how much can I send?


Hi all,

Does anybody know how to find out how much data I can send
over a SOCK_STREAM socket without getting a EWOULDBLOCK error?
[The socket is set to non-blocking IO.] I thought this could
be done with some ioctl() call (like NIOREAD), but haven't
found anything in the manual.

I'd appreciate responses via e-mail.

Thanks in advance,

Chris

+-----------------------------------------------------------------+
|Chris Reid			       e-mail: cr@cs.strath.ac.uk |
|Dept. Computer Science, Strathclyde University, Glasgow, Scotland|
+-----------------------------------------------------------------+

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1993 20:08:23 -0400
From:      masato@access.digex.net (J M Thompson)
To:        comp.protocols.tcp-ip,comp.protocols.time.ntp
Subject:   NTP for IBM MVS/ESA environment

I am looking for an implementation of Network Time Protocol (NTP)
(public domain or otherwise) for an IBM MVS/ESA system.  IBM's 
MVS/TCP/IP program product is on the MVS system.  As I understand it,
IBM does not currently have an implementation of NTP in the current version,
and it is questionable if there will be a NTP in the next release.

If a full implementation is not available, I am willing to settle for
the MVS host serving as a time server and other UNIX-based systems
setting their times to MVS.  It is also not required that the 
MVS host sync with an external time source.  I just need to keep
the MVS and UNIX systems in our internal network time synchronized.

To help prevent news group clutter, email response to me and I will
summarize for the news group as appropriate.

-- 
---------------------------------------------------------------------
Jim Thompson                     
email: masato@access.digex.com  
daytime phone: 703-759-8252    

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 93 13:31:54 GMT
From:      a20@nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug23.174052.26662@dickens.com> lpc@dickens.com (Luis P Caamano) writes:
>In article <1993Aug19.163205.20462@ajax.rsre.mod.uk> hearn@minotaur.dra.hmg.gb (Dave Hearn) writes:
>>WiseGuy (sysdhw@atscv1.gsfc.nasa.gov) wrote:
>>: There are some people who are thinking of using an unregistered Class A
>>: address for their IP network.  I am not a fan of this idea.  A direct
>>: connection from the Internet would then be unlikely ;-), but they would
>>: then have all of the addresses they could possibly need.
 
>>: I'm looking for some good PLUSES and MINUSES to pass along to them (to
>>: help them in the decision making process).
>>
>>
>>Well,
>>
>>they could do that.. but then .. I assume they never ever want to be connected
>>to the net in the future..  Forever is a long time!
>>
>>I would hate to be the guy who had to administer a massive overnight 
>>reassignment of Internet addresses across such a net. They sure would have to 
>>if they chose to follow the unassigned class A net route.

Hmm, if they choose to use an unregistered class A address, then they
probably are reasonably sure they do not want to connect. If they would want
to connect it would be highly unlikely that they would connect with ALL their
machines. What's against just splitting of a few machines on a different
official class C to do all the Internetworking they need (simple firewall
machines) and route all stuff from there on onto their internal net ? Of
course that would mean that you cannot use straight IP from all the
"unregistered" machines, but most companies do not allow straight IP from all
their machines anyway, and it would imply that they can never talk to the
"official owner" of that class A, but if you pick your A carefully, that
should not be too much of a problem either.

I find it a good way to save some of the precious IP address space ...
The one thing is that one should understand all the consequences of making
this step. It has been suggested before that we should reserve a class A,
some Bs and some Cs exactly for this purpose, ie everyone can use these
networks wherever they want, but they should NEVER be routed on the Internet.

Not an easy decision, but certainly an option ...

Marten Terpstra
RIPE Network Coordination Centre

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1993 20:51:50 -0400
From:      philip@charon.citicorp.com (Philip Gladstone)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS for PC

Moore / Jason David (ISE) (u912015@student.canberra.edu.au) wrote:
: In article <25coer$a4m@rugch4.chem.rug.nl> rudi@chem.rug.nl (Rudi van Drunen) writes:
: >Hi all !!
: >
: >I'm not sure if this is the correct newsgroup for this, but anyways:
: >I am looking for a (preferably Public DOMAIN) program that runs a Domain
: >Name server on a PC (dos) machine. 
: >
 
: Actually......If anyone answers this can you cover me on it as well....I
: would be very interested in something like this.....

I use Linux running on an old 386 running bind-4.9 to provide a cheap
nameserver (zero cost for software). Note that Linux has to run on 386
or better. A 40 Meg disk is more than enough. 4 Megs is more than enough.

Philip
-- 
Philip Gladstone - Consultant
Citicorp Global Information Network
I don't speak for Citicorp. I presume that somebody else does!

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 14:18:44 GMT
From:      jzwiebel@pgl-devsvr.page.mmc.com (John Zwiebel 303-977-1480)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: Q using cisco slip

Wayne:

I had a lot of trouble getting SLIP to run through my cicso server.  It wasn't
 really cisco's fault or the fault of anyone else for that matter, it was just
 that different aspects of SLIP from different vendors were configured to work
 differently.

I'm assuming from portions of your article that your portmaster is a shared 
network modem.  (Meaning it has an address of 159.182.42.15 because you have
several hosts on that network that access the modem via the network rather
than through serial lines)  In other words, you're trying to use your modem/
cisco combination to connect two networks together.  If so then perhaps you require
the cisco to have the "ip route 159.182.0.0 134.85.101.42" (thru 134.85.101.56)
configured on each cisco line.  I say "perhaps" because my manual states "In the
gateway server model, each SLIP line has its own network or subnet number."
The way the IP addresses are allocated to each line you don't have a separate
subnet so perhaps the cisco your connected to is still using the terminal
server model rather than the gateway server model.

The bootp suggestion is the way I was able to get my stuff to work.  MacSLIP
can send a BootP requests and understands the reply.  It then configures 
MacTCP/IP correctly.  I have my trouter set up with specific IP addresses on
each line (line your cisco) but not "slip dedicated" like your cisco may be.  In 
either case, the cisco also pumps out an ASCII text string with the serial
lines IP address.  If you don't have BootP perhaps you can write a script that
takes advantage of this.

I'm sure you noticed that I said MacSLIP.  SLIP is also available for PC's 
from FTP software however, my DOS guru's couldn't get it to work.  My cisco
serial lines are on a rotary modem dial-back so there is no guarantee that
you will connect to any particular line.  It seems that the FTP software can
only configure an IP address during system boot (There are 4 large books that
come with this software and it is very difficult to figure out what they want
you to do - not that the MacSLIP documentation is much better but at least 
it was only 20 pages).  To make slip connections one guru would call in, figure
out which line had called back, reboot his computer with the IP address of the
next line and hope no one else had called in during that interval.

TACAS is suppose to permit the cisco to dynamically configure its IP address.
We tried to get it to run on the RS6000 but it very quickly grew to being
a bigger problem than the one we were trying to solve.

I hope all this is helpful.  If someone out there knows something about 
configuring the FTP software to use BootP (or some other method), please let
me know.

John Zwiebel

In article <1993Aug17.144131.17281@ncs.com>, waynej@ncs.com (Wayne Johnson) writes:
|> I am trying to set up an internet interface for my group.  It involved 
|> connecting our Livingston Portmaster modem server, which supports a slip
|> mode, to a cisco server at the U of MN.
|> 
|> The problem I seem to be getting is that the cisco is assuming we have an
|> internet address of 134.85.101.42 thru 134.85.101.56 depending on what phone
|> port we get in on.  
|> 
|> By using the help command on the cisco I see that there is a address 
|> specification on the slip command.  Does this allow be to define the ip address
|> for my end of the link?  It does not seem to work if I try it.  Is there some
|> magical incantation I need to do first?  Is there a way to override the ip 
|> address that the cisco will give me?
|> 
|> The folks at Mr.Net suggested that we do a bootp request to find out what
|> the address is that the cisco expects us to be.  This would be fine if we had
|> any software that does a bootp REQUEST (Our AIX systems already have bootpd).
|> 
|> I don't think this will help much since I beleive our portmaster requires us
|> to use a single ip address (159.182.42.15).
|> 
|> The folks at Livingston are too busy at this point to do any research on
|> using the cisco for us.  Anyone have a cisco slip server users manual they
|> can email me?
|> 
|> Thanks for any help you can give.
|> -- 
|> Wayne D. T. Johnson       Internet: waynej@ncs.com      Phone: (612) 830-7880
|>      National Computer Systems, 4401 West 76th Street,  Edina, Mn.  55435 
|> "He is no fool, who gives up what he cannot keep, for what he cannot lose"
|>                                            - Jim Elliott

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 93 14:19:02 GMT
From:      jeffa@comtch.iea.com (Jeff Albrecht)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Summary: telnet failure under modem login

Jeff Albrecht (jeffa@comtch.computech.spk.wa.us) wrote:

Hi 

I lurk in newsgroups a lot. I often see questions I'd like to see the 
answers to, but the answers go to the poster via mail. Here's a summary
on a recent question I had for any other lurkers out there.

Thanks to all that replied to my original inquiry. I've solved the problem.
one thing I left out of the original post was the type of I/O I'm using.
A DigiBoard PC8e with drivers version 4.7.2 Several people suggested I rlogin 
into the site I'm calling from and then telnet out. This worked! But not
to elagent. After that I moved one of the modems from the PC8e to the 
standard tty00 line. If I called in on that line I could telnet out to other
systems. So I went on a quest for drivers for my Digi. I called DigiBoard
tech support who pointed me to their bbs, and supplied an ftp site
ftp.digibd.com. The ftp site is just starting up. The drivers I found seemed
to be corupted. At any rate by this time one more person wrote to tell me
they had a similar problem and that DigiBoard tech support had them turn off
fastcook. I did this by entering the command: 'ditty -fastcook < /dev/cui1a'
This did the trick. I can call in on the modem and telnet out now.

Here is the winning excerpt from comp.unix.sys5.r3:

(Thanks Jim)

From: jdeitch@jadpc.cts.com (Jim Deitch)

If you set cooked mode off on the Digiboard, then all will work.  I
had this problem, called Digi, asked tech support, they told me what
to do, and it worked.

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

Thanks to all.

Here's what I found in the mail:

From: alan@ernest.itg.ti.com (Alan Edmonds)

I was told a long time ago this was a bug in telnet not properly picking
up the term settings.  The solution is to rlogin into yourself, then you
can telnet out to your hearts desire.  For example, if you dial into
a machine called 'smokey', just rlogin smokey, then you telnet without any
problems.  I hope this helps.

From: tarpit!towers.rn.com!davidh@osceola.cs.ucf.edu (David Holland)

>Is anyone out there logging into Interactive SVR3 by modem 
>and telneting out successfully?

Sure... just re-rlogin to the same machine again.. THEN you can telnet
out... (annoying ain't it?) 

>From what I've heard its a bug in Interactive.. I know it 
still exists in version 2.2, but I'm not certain about
3.x.

From: kent@humu.nosc.mil (Kent K. Kuriyama)

I've encountered this same problem on a VAX VMS system running Wollongong
TCP/IP.  The problem is transient and I would be very interested in 
hearing responses you get.

Thanks.

From: quest1!jrm@mailhost.ecn.uoknor.edu (John Moyer)

I am not certain, but you may be able to solve your problem by looking
at whether all data paths are 8 bit and what happens to Xon and Xoff.

If the modem login is 7 data bits with parity,
  stty cs8 -parenb
and then change your communications software to 8 bits no parity also.

Turn off Xon/Xoff flow control in your communications software and try
using stty to turn it off or set the characters to something different
on the modem line on the computer.

I hope this helps.  I haven't used ISC Unix in a long time.

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

c ya...

-- 
Jeffrey H. Albrecht                jeffa@comtch.computech.spk.wa.us
Spokane, WA

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 17:17:53 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <2403@nikhefh.nikhef.nl> a20@nikhef.nl (Marten Terpstra) writes:
>   machines. What's against just splitting of a few machines on a different
>   official class C to do all the Internetworking they need (simple firewall
>   machines) and route all stuff from there on onto their internal net ? Of
>   course that would mean that you cannot use straight IP from all the
>   "unregistered" machines, but most companies do not allow straight IP from all
>   their machines anyway, and it would imply that they can never talk to the
>   "official owner" of that class A, but if you pick your A carefully, that
>   should not be too much of a problem either.




Don't forget the firewall has to resolve addresses.
The firewall must be able to address all legal hosts, including all on
any registered class A address. Now how does it handle connected from
the internal, illegal, class A address? It can't.

You would either have to use a double firewall system, with each
firewall unaware of the "other" Class A address, or use an unused (or unconnected)
Class A address that has no conflicts. Of course, how can you
guarantee this address will be unused?


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

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 93 18:29:34 GMT
From:      briana@tau-ceti.isc-br.com (Brian W. Antoine)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

Bruce Barnett (barnett@grymoire.crd.ge.com) wrote:
: In article <2403@nikhefh.nikhef.nl> a20@nikhef.nl (Marten Terpstra) writes:
: >   machines. What's against just splitting of a few machines on a different
: >   official class C to do all the Internetworking they need (simple firewall
: >   machines) and route all stuff from there on onto their internal net ? Of
: >   course that would mean that you cannot use straight IP from all the
: >   "unregistered" machines, but most companies do not allow straight IP from all
: >   their machines anyway, and it would imply that they can never talk to the
: >   "official owner" of that class A, but if you pick your A carefully, that
: >   should not be too much of a problem either.
: Don't forget the firewall has to resolve addresses.
: The firewall must be able to address all legal hosts, including all on
: any registered class A address. Now how does it handle connected from
: the internal, illegal, class A address? It can't.
 
: You would either have to use a double firewall system, with each
: firewall unaware of the "other" Class A address, or use an unused (or unconnected)
: Class A address that has no conflicts. Of course, how can you
: guarantee this address will be unused?

  If you want to watch the fun happen with unregistered address's.  Thing what
will happen when said customer sends one of the systems you sold them, that
they configured with invalid IP address's, back to you for service.

  In our case, the person who received the system didn't think anything about
hooking it up to our corporate lan and turning it on.  Needless to say all
hell broke loose when someone noticed that we were now broadcasting routes
out the internet link for a very bogus network.

  It isn't just that the customer never plans to connect to the internet.
You have to make sure that none of that customers systems ever make it
someplace where they can get connected.  Service departments within
company's that are attached to the internet get some very interesting
complaints from little things like this.
-- 
Brian W. Antoine   --------|        "Most sane people try to avoid annoying
Olivetti North AM   ||   *             wizards, what's your excuse?"
E. 22425 Appleway   ||   |/\
Spokane, WA 99220   ||   `7l==  *  *  *  *  *  *  *  (*)            "Ribbit!"
                   ====  / l   briana@tau-ceti.isc-br.com

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 93 18:46:47 GMT
From:      andyni@microsoft.com (Andrew Nicholson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP performance on Gb/s networks

 >Between two Sparc 630 MPs running SunOS
 >4.1.3 with dual 40Mhz Cypress processors, standard Sbus FDDI cards
 >and 51K (socket) buffers, I can sustain 3.7 MB/sec over FDDI on a TCP
 >connection.  CPU utilization is 100%.
 
 >I would expect to do 5 MB or so with a couple dual-SuperSPARC
 >workstations running Solaris 2.

Not too long ago when I worked at Cray Research, we were able to run
TCP/IP at over 1Gbps using the TCP expanded window option and large
(63k) packets.  Of course, a lot of other optimizations are present
in the Cray Research TCP/IP code as well.  The socket buffers were
in the 300k range.  Correctly tuned, it was also possible to achieve
around 97% of theoretical media throughput over a HIPPI channel.

Just a reminder that TCP/IP is not inherently slow ....

Andy Nicholson
andyni@microsoft.com	I speak for myself



-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 19:41:31 GMT
From:      jzwiebel@page.mmc.com (John Zwiebel 303-977-1480)
To:        comp.protocols.tcp-ip
Subject:   ICMP Type15/16 & ARP

This is a question of theory vs practical application. I may state some opinions
that may sound rather strongly held but I'm just trying to discover an answer
that makes sense so I can query my vendor about his implementation.

Type 15/16 are ICMP information request and reply packets.  When properly used 
it is possible to obtain the IP network number or subnet number.  I have a test
tool that is used to test umbilical cords.  The tool (called a SMUTT) can be moved to plug
into several different IP networks.  It is totally self-contained except that
it does not know its IP address when first turned on.  The IP address is 
the _only_ configuration information I need from the network.  Unlike most 
diskless hosts (this one does have a disk by the way) the SMUTT moves around
quite regularly.  

If I used RARP I would have to have rarpd running on a 
number of different hosts using up CPU time I can't spare and requiring close
monitoring of configuration files on each of these hosts.  On some networks
there may not be a host that can act as a RARP server.

If I used BootP, I would have to configure the routers to forward the UDP
broadcast.  I have cisco routers so I can either have the broadcast forwarded
to a specific group of hosts or flooded through out my network.  Trouble is
my network is sometimes connected to a network that has lots of BootP traffic.
I then have to worry about keeping this stuff off of my network.  (Not 
necessarily hard but another opportunity to mess up)

This leaves ICMP Information request packets.  RFC1009 states that a router 
may implement this.  RFC1122 states that a host should not implement this.
(BTW cisco does implement it, thank you very much)  (RFC 792 describes its use)

My "host" vendor used to implement Information Request Packets.  Then he 
changed his operating system.  Type 15/16 packets are still implemented but
unless there is an entry in the ARP cache for the SMUTT, the host only responds
with an ARP request packet.  The vendor cited RFC1122 saying there is no
requirement to perform.

Well, this brings up several questions.  I have some discussion for each of them
but I'll list the questions first.

1) when is a host really a gateway?
2) does it make sense for any system (host or gateway) to send an ARP request
	in response to a ICMP information request packet since the system
	sending the request doesn't know its IP address, which is the reason
	it is sending the request?
3) should only ARP packets be used to populate the ARP cache?  Should only
	ARP responses be used?
4) The OSI model is a model so...
	a) how distinct should each layer be from the other?
	b) If ARP is wholly a data link layer process does it really
		have to have knowledge of IP for the host (gateway) to
		effectively implement ICMP Information Requests?
5) Comer states in his book that Type 15/16 is obsolete.  Is this opinion
	or fact?  If opinion, is it because RARP and BOOTP are generally 
	better at providing a diskless node with its IP address?  (I agree)
	Or is it because Type 15/16 may cause problems on the network?  What
	are these? (I've seen some that are quite attrocious but that is, I
	believe, due to poor implementation.) 
6) If Comer's book is fact, is the IETF actually considering doing away with
	type 15/16?  (I'm missing some information in the rfc-by-title.txt
	rfc-index.txt & std-index.txt downloaded from nic.ddn.mil that
	would lead me to the RFC that dumps this type).
7) What is the correct way for any host (gateway) to respond to a type 15?


My vendor wants to claim he's a host and not a gateway, yet if I put two
interfaces on it, it will route packets.  By default it comes up with 
"ipForwarding" and "ipRedirects" set - even though routed and gated are not
running and it the "host" has only one interface.  (BTW if you have ipRedirects
on you can get bursts of traffic if you happen to use an IP broadcast address
of 147.105.101.255.  I'm talking hundreds of packets on a network that has no
more than 15 hosts on it.)  So is my vendor trying to "have it both ways" 
being a gateway when it is convenient and a host when I point out to him I 
believe he made an error.  

Next point, if a host or system on the internet respond to a type 15 with a 
type 16 under _any_ conditions then it must, by definition, be a gateway.  
Although RFC1009 says a gateway _may_ respond to type15, if it isn't done
correctly (to be defined), then is it right for the vendor to point to rfc1122
and tell me to keep up with the standards?  (Yeah, they pissed me off - sadly
that happens too easily when one reads Email or for that matter a news group.
I apologize to those of you who take offense at my tone.)

Question 2 answers itself, but let us review it.  A type 15 PDU had a destination address of 0.0.0.0 meaning "this network" and a source address of 
"0.0.0.xxx" (in my case 0.0.0.155).  The response in a type 16 PDU fills in the
missing network information for the requesting host.  (There are some other 
fields but they are not important).  The RFC doesn't address how this packet
is suppose to be returned.  I mean the type of packet it is suppose to be returned in.  Under the "old" implementation my vendor used an ethernet
broadcast packet followed by a directed ethernet packet that used the SMUTTS
hardware address.

The enet broadcast is probably the reason why type15/16 should be done away
with.  Broadcasts going everywhere.  I can see how this would cause _major_
problems on a bridged network with hundreds of attached systems that all 
respond to the ICMP request.  A huge spike in bandwidth usage.

Cisco responds only with a directed Type16 packet.  (Makes sense to me but I
probably don't have the historical perspective to appreciate what's going on)

This leads us to Question 3.  I haven't determined whether cisco uses the 
incoming Type15 packet to put an entry into the arp cache; processes type 15
packets separately; or passes the hardware address up to the IP (network) layer
to build the Type 16 response.  I do know they do not send out an arp request.

The vendor in question doesn't send out an arp request either in his "old" OS.
At least I did not capture any arp packets nor did my test tool show up in the
vendor's arp cache with an "arp -a" (although I've found this command to be
very unreliable).  So where did they get the hardware address?

So is it acceptable to populate the arp cache with hardware/ip address pairs
from received packets?  Would doing this cause problems with CPU usage or
perhaps routing packets through the protocol stack since ARP is ethertype 0806
while IP is 0800?  How does this relate to question 4?

The vendor brought up BSD-reno 
>The substantive problem here is that the MAC info is gone by the time
> we do ICMP processing.  This behavior is straight from BSD Reno and
> traditional ISO "layered" architecture.  I don't know how Cisco did it
> unless they modified their interface/driver layer to do ARP in the case
> where you have an incoming ICMP broadcast.  This means if/driver needs
> to know about IP which contradicts principles in both the RFCs and BSD
> Reno.

Does ICMP type 15/16 have to be implemented so that it cotradicts the layering
principles of the OSI model?  I don't believe so if every IP/enet address pair
from a received packet is sent to the ARP cache.  (How about just broadcast 
packets to cut down on the processing?  Aren't we going to have to use this
pair soon anyway?)  Which then brings me back to question 3.  The network layer
could update the ARP cache also couldn't it?  After all, IP depends on the
date link layer address to work.  If the two layers knew nothing about one
another then they couldn't work together.  How was it determined which layer
would be responsible for updating the arp cache?  (Since arp can be used by 
other protocols than IP it makes sense that the data link layer should do it,
but does that mean it can't [or shouldn't] be done by the network layer?)

The rest of the questions don't require any discussion other than asking them. 

One last one, is there any one that might care about this that won't be reading
it in this discussion group?

I'll be happy to try to summarize E-mail unless you want to put in a post here.

John Zwiebel

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 93 21:59:47 GMT
From:      u912015@student.canberra.edu.au (Moore / Jason David (ISE))
To:        comp.protocols.tcp-ip
Subject:   Re: DNS for PC

In article <25coer$a4m@rugch4.chem.rug.nl> rudi@chem.rug.nl (Rudi van Drunen) writes:
>Hi all !!
>
>I'm not sure if this is the correct newsgroup for this, but anyways:
>I am looking for a (preferably Public DOMAIN) program that runs a Domain
>Name server on a PC (dos) machine. 
>
>Any hints will be appriciated, please Use E-mail.
>

Actually......If anyone answers this can you cover me on it as well....I
would be very interested in something like this.....


***************************************************************************
* Jason Moore                                                             *
* u912015@student.canberra.edu.au                                         *
* Systems Engineer                                                        *
* Datacraft Australia (Canberra Branch)                                   *
* The opinions expressed here are my own and do not reflect in any way    *
* the viewpoint of Datacraft.                                             *
***************************************************************************




-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 22:31:35 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   APS Alliance Specification?


Does anyone know anything about the Asynchronous Protocol Spec - APS?

APS is being developed by the "APS Alliance", and aims to 
provide a network service over a dial up link using a stripped
down version of X.25 protocol.

I have a draft copy of the spec. and it says that it will be
offered to the "Internet community", which should be interested in
it.   This seems a little odd to me, considering SLIP and PPP.

Can anybody shed any light on this for me? or suggest contacts?


TIA

-- 

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

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Aug 1993 22:47:58 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets: how much can I send?

Chris Reid (cr@cs.strath.ac.uk) wrote:
: Does anybody know how to find out how much data I can send
: over a SOCK_STREAM socket without getting a EWOULDBLOCK error?
: [The socket is set to non-blocking IO.] I thought this could
: be done with some ioctl() call (like NIOREAD), but haven't
: found anything in the manual.

Well, that will depend on the speed of the network/receiver, and the
setting of the socket buffer size. If you assume a network and
receiver of zero bandwidth, then one can "send" ~ SO_SNDBUF bytes
worth of data on a SOCK_STREAM (I assume a TCP BSD socket) socket
before getting EWOULDBLOCK. If you have a network and receiver of
infinite bandwidth, then there would be no limit.

Reality will be somewhere in between...

If you aren't setting SO_SNDBUF yourself, you can retrieve it's
current value with a getsockopt() call...

rick jones
raj@cup.hp.com

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1993 08:30:00 -0400
From:      cross@shetland.ae.eds.com (Jason Cross)
To:        comp.protocols.tcp-ip
Subject:   OSI traffic and the Internet

Are there any service providers to the Internet which route OSI traffic,
and is OSI traffic allowed on the Internet or this completely taboo?
If there is a more appropriate newsgroup I should post to, please
let me know.  Thanks.
-- 
ciao,
Jason Cross
EDS
Troy, Mi.

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 03:23:27 GMT
From:      cej@world.std.com (Craig E Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <BARNETT.93Aug24121753@grymoire.crd.ge.com> barnett@crd.ge.com writes:
>In article <2403@nikhefh.nikhef.nl> a20@nikhef.nl (Marten Terpstra) writes:
>>   machines. What's against just splitting of a few machines on a different
>>   official class C to do all the Internetworking they need (simple firewall
>>   machines) and route all stuff from there on onto their internal net ? Of
>>   course that would mean that you cannot use straight IP from all the
>>   "unregistered" machines, but most companies do not allow straight IP from all
>>   their machines anyway, and it would imply that they can never talk to the
>>   "official owner" of that class A, but if you pick your A carefully, that
>>   should not be too much of a problem either.
>
>
>Don't forget the firewall has to resolve addresses.
>The firewall must be able to address all legal hosts, including all on
>any registered class A address. Now how does it handle connected from
>the internal, illegal, class A address? It can't.
>
>You would either have to use a double firewall system, with each
>firewall unaware of the "other" Class A address, or use an unused (or unconnected)
>Class A address that has no conflicts. Of course, how can you
>guarantee this address will be unused?
>
>Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

This would be solved simply by reserving one Class-A network for this purpose,
as several have suggested.

(I have no idea whether this has been discussed at IETF or other places.
I simply know that it makes sense.)
-- 
Craig Jackson
cej@world.std.com

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 03:41:01 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

> barmar@think.com (Barry Margolin) writes:
 
> >This is why lots of things in TCP/IP don't get noticed until one or two
> >operations later.  It takes a long time (in computer time) to find out the
> >state of a machine across the network.  So write() just queues the packets
> >for transmission and returns immediately.  When a timeout occurs or a reset
> >comes back, the state of the socket is changed and the next operation
> >fails.

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

> Writing to disk gives you an option to wait until I/O is completed (O_SYNC)
> which can be useful in some circumstances.  It would probably be of benefit
> for some applications if a similar mechanism was available for network
> writes. 

The equivalent is to get an application-level acknowledgement from the far
side, with an application-level timeout to signal failure.  *Nothing* else
will guarantee that the data has reached its destination.  When TCP is
running on a smart network card at the far end, the CPU could be pulled out
and you'd still get TCP acks.

> It could certainly be made more efficient building this into the Unix kernel
> rather than relying on the application programmer needing to add a separate
> acknowledgement protocol to his/her program.

It isn't, though, because no two applications want things done in the same
way.  Even a single application will often want things done in different
ways at different times, depending on its state.  (I.e. if a client has
database records locked on the server, you want a fairly short timeout; if
the client is in a resting state with few resources in use on the server,
you want a much longer timeout.  Sendmail wants long timeouts, because it's
unattended, but the receiver-SMTP mustn't return the final ack until the
message is guaranteed written to disk.)  How can the kernel detect this?

Application-level timeouts are easy to write (in Unix, anyway).  select()
and poll() do them for you; even in the case of a single socket read, it's
easy enough to add an alarm call.  Nothing else will get you the
flexibility that a reliable application needs.

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


-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 05:12:27 GMT
From:      g2dhatch@cdf.toronto.edu (Hatch Don)
To:        comp.dcom.lans.misc,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   5250/telnet



	I have seen the tn3270 code; is there any public domain
	sources for 5250 over TELNET?

	Regards, Don.


-- 

	g2dhatch@cdf.toronto.edu


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 06:18:25 GMT
From:      keng@skypoint.com (Ken Germann)
To:        comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: telnet failure under modem login

In article <CC5G67.Dz@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes:
>In article <id.H1X11.852@nmti.com> kunkee@nmti.com (randy kunkee) writes:
>>In article <1993Aug20.145354.21675@vdoe386.vak12ed.edu> jepperso@vdoe386.vak12ed.edu (Jay Epperson) writes:
>>>
>>>Subject: Re: telnet failure under modem login
>>>Newsgroups: comp.unix.sys5.r3,comp.unix.admin,comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.questions,comp.unix.sys5.misc,comp.unix.sysv386,comp.protocols.tcp-ip
>>>Organization: Virginia's Public Education Network (Richmond)
>>>References: <1993Aug18.143612.1137@comtch.computech.spk.wa.us>
>>>
>>>For what it's worth, we have a com server running Interactive and servicing
>>>six incoming lines on a rotary.  A major function is access to an Internet
>>>feed for telnet/rlogin to other systems/networks.  Seems to work fine.
>>>
>>>"This message constructed of recycled bits."
>>
>>I just set up a customer to dial in to our system, and he had the
>>same problem.  This is an old problem, I had just forgotten about
>>it.  It's a bug in the driver for the Digiboard (pc/8e) that we have.
>>We tried a later driver from Digiboard, but it was even worse (crashed
>>the system frequently).  This is on a 386 with Intel SVR3.2 Unix.
>>Rlogin works, but telnet does not.
>>
>>Perhaps you do not have a Digiboard, and the original poster with the
>>problem does, or different versions of the driver (and O/S) are involved.
>
>If you set cooked mode off on the Digiboard, then all will work.  I
>had this problem, called Digi, asked tech support, they told me what
>to do, and it worked.
>

ditty -fastcook <Digiboard Port> 

should fix the problem.

-- 

Ken Germann		       			Sky Point Communications.
keng@skypoint.com				Administrator.
612-458-3889 Data (2400-14.4)			612-459-7554 Voice 			
	    "Rule #1: The Boss is always right, 
	 Rule #2: If the boss is wrong follow Rule #1"

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 07:41:16 GMT
From:      John Mackin <john@civil.su.oz.au>
To:        su.net,aus.wanted,comp.protocols.tcp-ip,comp.protocols.misc,comp.sources.wanted
Subject:   SUMMARY: Wanted: Source to `Single-Line' BOOTP daemon

In article <1993Aug19.134643.25797@physiol.su.OZ.AU>,
	I wrote:

> There are at least two kinds of BOOTP daemon for UNIX extant.
> [And I want source for the hard-to-find kind.]

Thanks very much indeed to Steven Bjork, <bjork@Telebit.COM>, for
the reply that cracked this open for me.  He told me that this
was the `Stanford BOOTP format' and suggested I look at Stanford.
I couldn't find it there, but an archie search for "bootp.server.shar",
which he suggested as a vaguely-recalled filename, turned up precisely
one match: at uxc.cso.uiuc.edu in /services/bootp.  And that code is
just what I was looking for.  So thanks again, Steven.  (There is also
some ROM-able BOOTP client code there, in bootp.client.shar.)

-- 
John Mackin <john@civil.su.oz.au>
Knox's box is a 286.                 Fox in Socks does hacks and tricks
Knox's box is hard to fix.           To fix poor Knox's box for kicks.

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 10:53:26 GMT
From:      rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS for PC

philip@charon.citicorp.com (Philip Gladstone) writes:
: In article <25coer$a4m@rugch4.chem.rug.nl> rudi@chem.rug.nl (Rudi van Drunen) writes:
: >Hi all !!
 
: >I'm not sure if this is the correct newsgroup for this, but anyways:
: >I am looking for a (preferably Public DOMAIN) program that runs a Domain
: >Name server on a PC (dos) machine. 
 
: I use Linux running on an old 386 running bind-4.9 to provide a cheap
: nameserver (zero cost for software). Note that Linux has to run on 386
: or better. A 40 Meg disk is more than enough. 4 Megs is more than enough.

You also have the option of NetBSD (the current version is 0.9).
It's also free and the networking is more stable and sophisticated than Linux.
(It's based on the NET/2 sources from Berkeley, that is the tcp-ip code from
BSD 4.3). To use just for DNS the hardware requirements are the same
than Linux.

BTW, the 386 might be a 386sx.

--
 Rui Salgueiro |   Dpt. de Matematica    |"In my life / Why do I smile
 rps@mat.uc.pt | Universidade de Coimbra | at people who I'd much rather
 rps@inescc.pt |    Portugal - Europe    |   kick in the eye" - Morrissey 

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 93 11:44:34 GMT
From:      a20@nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <BARNETT.93Aug24121753@grymoire.crd.ge.com> barnett@crd.ge.com writes:
>In article <2403@nikhefh.nikhef.nl> a20@nikhef.nl (Marten Terpstra) writes:
>>   machines. What's against just splitting of a few machines on a different
>>   official class C to do all the Internetworking they need (simple firewall
>>   machines) and route all stuff from there on onto their internal net ? Of
>>   course that would mean that you cannot use straight IP from all the
>>   "unregistered" machines, but most companies do not allow straight IP from all
>>   their machines anyway, and it would imply that they can never talk to the
>>   "official owner" of that class A, but if you pick your A carefully, that
>>   should not be too much of a problem either.
>
>Don't forget the firewall has to resolve addresses.
>The firewall must be able to address all legal hosts, including all on
>any registered class A address. Now how does it handle connected from
>the internal, illegal, class A address? It can't.


Indeed, that is why I said that you have to pick your class A carefully, and
both I and Craig Jackson in a later message suggested to reserve a class A
exactly for this purpose. Since most of the class A's are reserved at this
point in time, and there is not much change that any will be assigned, big
chance is that the A you picked will never be used.


>You would either have to use a double firewall system, with each firewall
>unaware of the "other" Class A address, or use an unused (or unconnected)
>Class A address that has no conflicts. Of course, how can you
>guarantee this address will be unused?


No need for a double firewall, just that your firewall machines can only talk
to your "unregistered" class A, and not to any official machine on that same
class A, but again, pick your A with care (127 ?).

Since we assign IP number for Europe, we have seen loads of requests for
LARGE amount of address space for applications like assigning numbers to
tills in department stores, and even the LCD displays on the racks, and
flight information screens on airports (yes, some of them are simply X
terminals). It is highly unlikely that these machines will ever be visible on
the Internet as we know it, and these could benefit is they could simply pick
from a reserved set of numbers just for this purpose.

I guess someone simply has to write these things down, submit to IANA and see
what they say (no, I am not the person to do so ;-) This document should of
course have big warnings on the consequences of using one of these numbers.

Marten
-----------------------------------------------------------------------------
    Marten Terpstra            |        RIPE Network Coordination Centre
 phone: +31 20 592 5065         |                 PO BOX 41882,
  fax:  +31 20 592 5090         |            NL-1098 SJ  Amsterdam,
Internet: marten@ripe.net       |                The Netherlands
------------------------------------------------------------------------------

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1993 13:58:16 GMT
From:      pascoe@wpi.edu (David Pascoe)
To:        comp.protocols.tcp-ip
Subject:   Broadcast problems


I recently tried to change the subnet mask and broadcast address on a subnet 
and ran into a few problems with getting the rwho daemon (and other 
broadcasts) to work right after the changes.

The network is a class B network subnetted into a few class C networks.  
The nets are connected by a cisco AGS+ router.  The subnet masks on the
router are all set to 255.255.255.0 (class C mask).  All of the machines
on one subnet (primarily Suns) are running with class B subnet masks 
(255.255.0.0) and a broadcast address of 144.212.255.255.

When I made changes I changed the subnet masks to 255.255.255.0 and the
broadcast address to 144.212.subnet_number.255.  When I looked at broadcasts
after the change some machines were broadcasting to 144.212.subnet_number.255
and some were still broadcasting to 144.212.255.255.  This caused ruptime
to stop reporting in a consistent manner, which makes sense.

I would like all of the broadcast addresses to be 144.212.subnet_number.255
but don't want to make another change until I learn what problems might
lie in SunOS 4.1.3.  Also, since all of the hosts are broadcasting only on
that subnet, does the router broadcast address need to be changed?  

In every other environment I have been in this has never been a real problem.


--
Dave Pascoe
pascoe@wpi.edu

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 93 14:22:03 +0100
From:      ccdarg@dct.ac.uk (Alan Greig)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet diameter?

In article <CKD.93Aug23220215@loiosh.eff.org>, ckd@eff.org (Christopher Davis) writes:
> KM> == Ken Mintz <mintz@cup.hp.com>
> 
>  KM> RFC-1122 states that a default IP TTL should be "at least big enough
>  KM> for the Internet diameter, i.e., the longest possible path".  Then it
>  KM> recommends that it be __twice__ the diameter to allow for growth.
> 
> RFC1340 says:
>    The current recommended default time to live (TTL) for the Internet
>    Protocol (IP) [45,105] is 64.
> 
> That, presumably, takes into account the projected diameter growth; I
> rarely if ever have to up the traceroute default TTL of 30.  (Or maybe I'm
> just centrally located :)

I've recently had problems with sites more than 30 hops away. DEC's
UCX (VMS) enforced a TTL of 30 meaning I couldn't talk to them
and they couldn't reach me and someone from TGV commented that they
had seen 45 hops on the Internet.

> 
> --
>  # Christopher Davis # <ckd@kei.com> # <ckd@eff.org> # [CKD1] # MIME # RIPEM #
> ``"mail" is an _uncountable_ noun.  Like water, or spam, it is not treated
>   grammatically as if it had natural, countable smallest units (except perhaps
>   in Monty Python skits).''  -- Alfred Kriman <kriman@acsu.buffalo.edu>
-- 
Alan Greig                            Janet: A.Greig@uk.ac.dct
Dundee Institute of Technology	   Internet: A.Greig@dct.ac.uk
Tel: (0382) 308810                 (Int +44 382 308810)
         ** Never feed the hand that bites you **

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 16:26:45 GMT
From:      robs@join.com (Rob Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article 528@turtle.fisher.com, schaubert@turtle.fisher.com writes:
>I have no idea if this can be supported with standard bootp but I have
>been considering the same problem (Issuing IP numbers at the
>BOOTP server).
>
>I figure if my BOOTP clients use the vendor specific area to identify
>themselves as needing an IP address assigned even if they do NOT
>have their physical address found in the bootptab file, then the
>bootp server should be able to assign them an IP address.  As far
>as I know this would be an extension to the way BOOTP servers
>work now.
>
>Can someone much more knowledgeable about BOOTP's current state
>comment on whether such a scheme has been proposed or implemented?

The IETF has just approved as a Proposed Standard the Dynamic Host Configuration
Protocol. This protocol is an extension to BOOTP and is encapsulated in BOOTP
packets. One major goal of DHCP is to allow dynamic allocation ("leasing") of
IP addresses for either temporary or permanent use by clients. The proposed
protocol is described in the following Internet-Draft:

	o "Dynamic Host Configuration Protocol"
	   draft-ietf-dhc-protocol-07.txt

Implementations are just starting to appear - we are currently looking for beta
sites for our own product. As far as ythe interoperation of BOOTP/DHCP and PPP
goes, this is something I have not looked into.

Rob Stevens
Competitive Automation.








-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 93 20:33:14 EDT
From:      edimg@willard.atl.ga.us (Ed pimentel)
To:        comp.protocols.tcp-ip
Subject:   NEEDED program that can assigned IP addresses with SOURCE

I am in DIRE need of a program that can assigned and manage the
assignments of IP address, net mask etc.....
 
THANKS IN ADVANCE


-- 
edimg@willard.atl.ga.us (Ed pimentel)
gatech!kd4nc!vdbsan!willard!edimg
emory!uumind!willard!edimg
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1993 18:26:08 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <CCAq8E.2L3@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
>> It could certainly be made more efficient building this into the Unix kernel
>> rather than relying on the application programmer needing to add a separate
>> acknowledgement protocol to his/her program.
>
>It isn't, though, because no two applications want things done in the same
>way.  Even a single application will often want things done in different
>ways at different times, depending on its state.  (I.e. if a client has
>database records locked on the server, you want a fairly short timeout; if
>the client is in a resting state with few resources in use on the server,
>you want a much longer timeout.  Sendmail wants long timeouts, because it's
>unattended, but the receiver-SMTP mustn't return the final ack until the
>message is guaranteed written to disk.)  How can the kernel detect this?

On reflection of this thread, I believe that what's necessary, and perhaps
what some of the posters were actually asking for, is not enhancements to
the protocols, but simply some better higher-level library routines.

Doug Siebert's comment above implies that there are only two parts to a
TCP-based program: the application and the kernel.  But there's a third
kind of component: library routines.  For example, RPC libraries provide a
higher level interface between applications and network system calls.

Tom Fitzgerald's message suggests that we need libraries that implement
network database calls (with locking), streams that close automatically
when they're idle for a while, etc.  There would be calls so that the
application could inform the library of appropriate state changes (e.g. an
SMTP server might want to change the idle timer depending on whether it's
in the middle of processing a message or between messages).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 19:00:33 GMT
From:      exuptr@exu.ericsson.se (*-- Sunbird --*)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   TCP/IP and ODI



Anyone have workstation drivers?  Where?
--
  --------------------------------------------------------------------------
  -------Visit the SOUNDING BOARD BBS +1 214 596 2915, a Wildcat! BBS-------
    WHO:                      DO:
    Patrick Taylor [INTP]    |Borland C++, Borland Pascal, SqlWindows.
    Ericsson Network Systems |Turbo Assembler, and Paradox 3.5
    exuptr@exu.ericsson.se   |ObWarning: "Don't let the .se fool you"

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1993 20:19:50 GMT
From:      afx@ibm.de (Andreas Siegert)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: routed not working properly on AIX?

Klaus Desinger (kld@sat.ipp-garching.mpg.de) wrote:
: Hi,
: it seems that routed is not working properly on some of our AIX
: machines. "netstat -r" doesn't show any entries for subnets that
I suggest dumping routed in favour of gated.
We always had problems with routed and subnets.
It had this tendency to insert routes to the unsubnetted class A network
into the routing table instead of honouring the subnet masks.
All those problems are history since we switched to gated.

afx
--
Andreas Siegert / Postmaster    | Vacationing at the  |  Never grep a yacc
AIX Field Support Center Munich |     ITSC Austin     |  by the i-node!
Internet: afx@ibm.de            |                     |  Opinions are my own,
VNET: SIEGERT@MUNIVM4           | Voice -512-838-9658 |  not IBM's.

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 21:03:39 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <3892@tau-ceti.isc-br.com> briana@tau-ceti.isc-br.com (Brian W. Antoine) writes:
>  In our case, the person who received the system didn't think anything about
>hooking it up to our corporate lan and turning it on.  Needless to say all
>hell broke loose when someone noticed that we were now broadcasting routes
>out the internet link for a very bogus network.

I sincerely hope you've fixed whatever procedural problem caused this
to happen.  It makes no difference whether the node's configured IP
address was registered or not.  In fact, if it were an address
officially assigned to your customer, you might have disabled your own
customer's link to the Internet by usurping the actual routes to his
network.  As it was, if you hurt anyone, it was an unrelated third
party.  That's very bad, of course, but it would have been even worse
if you had lost a customer over it.
						don provan
						donp@novell.com

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Aug 1993 21:28:37 GMT
From:      dmk@allegra.att.com (David M. Kristol)
To:        comp.protocols.tcp-ip
Subject:   non-sequential connect/accept??

Please send all responses by Email to dmk@allegra.att.com.  My
apologies if this question is a FAQ (in which case please direct me to
an FTP site for the FAQs).

I've written a simple client/server pair.  They run on SunOS 4.1.3,
SparcStation 2.  The client and server communicate by TCP streams
sockets.  The server is serial; that is, it does not fork another
process before it does its thing.  Its processing could take a second
or two.  It has the usual skeleton:

	...
	listen()
	for (;;) {
		sock = accept()
		<process>
		close(sock)
	}

My client is equally vanilla.  Its skeleton is:
	...
	sock = socket()
	connect(sock)
	<process>
	close(sock)

My problem:  if I start the server, then do
	for i in 1 2 3 4 5 6 7 8 9 10; do client $i; done
the server accept()'s the client requests out of order.  A typical order
is:  1 5 10 9 8 7 6 4 3 2.  I've determined that the client's
connect()'s complete and return before the server actually accept()'s
the connection.  (I ran both processes on the same system and printed
time stamps just after the connect()'s and accept()'s. I also passed a
timestamp from the client to the server as part of its data.)

My questions:
	1) Is this out-of-order accept() behavior valid/expected?
	2) Is this typical behavior in a BSD-derived TCP implementation?
	3) Is there a simple and standard way to serialize the accept()'s
		so they occur in the order 1 2 3 4 5 6 7 8 9 10?
		(Right now I send an ack from the server to the client
		after the accept(); the client waits for that ack.)

Many thanks for any help and insights.
Dave Kristol
dmk@allegra.att.com

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1993 18:44:22 +0200
From:      kld@sat.ipp-garching.mpg.de (Klaus Desinger)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   routed not working properly on AIX?

Hi,
it seems that routed is not working properly on some of our AIX
machines. "netstat -r" doesn't show any entries for subnets that
are advertised via RIP, but lots of entries for single hosts
flagged "UGHD" coming from ICMP redirects. 
"routed -q -t" shows that RIP packets are coming in and are
processed properly, but the update of the routing tables seems
to fail:
SIOCDELRT: No such process
SIOCADDRT: File exists
"netstat -r" also shows an entry for "130.183" and some randomly
choosen router. But there is no such net, it's subnetted as
0xffffff00. No router advertises a route to "130.183".
Though the interface is configured correctly, maybe routed
has a wrong idea about our subnetting?
There are these funny "Netmask" entries at the top of the
"netstat -r" output. What do they mean? Where do they come from?
Are they documented anywhere?

Any hints are appreciated.

Klaus

-- 
Klaus Desinger                         kld@ipp-garching.mpg.de
Rechenzentrum Garching                   Tel: +49 89-3299-2168

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 93 23:15:04 GMT
From:      briana@tau-ceti.isc-br.com (Brian W. Antoine)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

don provan (donp@novell.com) wrote:
: In article <3892@tau-ceti.isc-br.com> briana@tau-ceti.isc-br.com (Brian W. Antoine) writes:
: >  In our case, the person who received the system didn't think anything about
: >hooking it up to our corporate lan and turning it on.  Needless to say all
: >hell broke loose when someone noticed that we were now broadcasting routes
: >out the internet link for a very bogus network.
 
: I sincerely hope you've fixed whatever procedural problem caused this
: to happen.  It makes no difference whether the node's configured IP
: address was registered or not.  In fact, if it were an address
: officially assigned to your customer, you might have disabled your own
: customer's link to the Internet by usurping the actual routes to his
: network.  As it was, if you hurt anyone, it was an unrelated third
: party.  That's very bad, of course, but it would have been even worse
: if you had lost a customer over it.

  Yes, it's been fixed, or at least it's fixed if the procedures are followed.
Returning systems are not hooked to the main lan at all.  At best they get
hooked to an isolated lan in either the repair area or a special test lab.
The potential is still there though for us, or anyone else that ever gets
a system back from a customer.  You're right, it doesn't even have to be
an invalid address to cause problems.  It makes you wonder just what
percentage of routing problems on the internet are caused by screwups
like this.  I'd hope that they were a very small percentage, but I'd also
bet that the number is larger then zero.
-- 
Brian W. Antoine   --------|        "Most sane people try to avoid annoying
Olivetti North AM   ||   *             wizards, what's your excuse?"
E. 22425 Appleway   ||   |/\
Spokane, WA 99220   ||   `7l==  *  *  *  *  *  *  *  (*)            "Ribbit!"
                   ====  / l   briana@tau-ceti.isc-br.com

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 10:15:16 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI access to TCP/IP

By the way, Comer's TLI client/server programming is now out.  It is
the recommended reference for folks using or trying to use TLI.

Authors:	Douglas E. Comer & David L. Stevens
Title:		Internetworking with TCP/IP :
			Volume III Client-Server Programming & Applications
			(AT&T TLI Edition)
ISBN:		0-13-474230-3
Publisher:	Prentice-Hall, Englewood Cliffs, NJ, 07632, USA
Cost:		about $50


-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 10:57:27 GMT
From:      wood@underdog.ee.wits.ac.za (WOOD DC)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for ICL Series 39 35XP

I would appreciate it if any could e-mail me with infomation regarding 
TCP/IP software for an ICL Series 39 mainframe. I am familiar with ICL's 
OSLAN connectivity software which is based on OSI standards, however I 
wish to make use of TCP/IP standard due other machines which have to be 
connected. 

The name, version, distributer and approximated cost of this software
(if it exists) would also be greatly appreciated.

Thanks

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 93 12:21:01 GMT
From:      brooks@underdog.ee.wits.ac.za (Goth)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Help - TCP/IP compatibility.

Please help. I need to know if the following machines can run TCP/IP 
protocols:

Convex
HP 3000
DEC MicroVAX II
IBM RISC 6000
ICL Series 39 35XP

Please would anyone who knows mail me. Also, for the ones that don't run 
TCP/IP, what are the best alternatives?

Thanks in advance,
Goth

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 17:51:23
From:      Michel.Dalle@sni.be (Michel Dalle)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP to a VAX ?


Hi,

I've run into an interconnection problem here between a UNIX and a VAX.

What exactly can you do between a UNIX and a VAX (VMS) system with TCP/IP ? 
I mean, is it just telnet, ftp etc., or can I use other existing applications ?
Can I expect any problems when using "older" VAX systems (I heard somewhere 
that they didn't really support TCP/IP in native mode or something before 
DECnet Phase IV or V), or can any application running on the VAX use TCP/IP as 
a protocol stack ?
Any other peculiarities we're not used to when connecting UNIX boxes together ?

I know these questions are all a bit vague, but I'd like to know what to 
expect. Thanks for any information. Please email any comments, and I'll 
summarize if there's any interest in this matter.

Michel.

( email : Michel.Dalle@sni.be )



-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 93 18:21:30
From:      ses@tipper.oit.unc.edu (Simon E Spero)
To:        comp.protocols.tcp-ip
Subject:   Re: FREE Talk on IP Addresses

In article <clbooksCCDoIK.3ns@netcom.com> clbooks@netcom.com (Computer Literacy Bookshop) writes:
   core Internet Protocol (IP) must be changed. Piscitello describes 
   the underlying technical issues and the likely solution (TCP/UDP 
   over Big Addresses, or TUBA).

I think one is getting a little ahead of oneself. 
--
Hackers Local 42- National Union of Computer Operatives, Chapel Hill section
------------------------------------------------------------------------------
Tar Heel Information Services - Nothing but net!   | WAIS/Z39.50 spoken here
CLNP - The C is for Clue 		   | DoD #612 | Tel: +1-919-962-9107

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 93 17:54:25 EDT
From:      edimg@willard.atl.ga.us (Ed pimentel)
To:        comp.protocols.tcp-ip
Subject:   NEED a program that assigns IP addresses with source

I am dire need for a program that assigns ip addresses and net masks.
 
THANKS IN ADVANCE

-- 
edimg@willard.atl.ga.us (Ed pimentel)
gatech!kd4nc!vdbsan!willard!edimg
emory!uumind!willard!edimg
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 16:55:19 GMT
From:      mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF])
To:        comp.protocols.tcp-ip
Subject:   echo/tcp service

Are there any RFCs or other standard-dictating documents that
assert that all Internet hosts must offer the echo/tcp service?

--
-- Murray S. Kucherawy ----------------------------------------+--------------
Software Systems Co-op, Math Faculty Computing Facility [MFCF] | All spelling
University of Waterloo, Ontario, Canada                        | errors caused
E-mail: mskucherawy@{math,watdragon}.UWaterloo.ca              | by Pnews.
---------------------------------------------------------------+--------------

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 17:19:53 GMT
From:      exuptr@exu.ericsson.se (*-- Sunbird --*)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <3901@tau-ceti.isc-br.com> briana@tau-ceti.isc-br.com (Brian W. Antoine) writes:

>don provan (donp@novell.com) wrote:
 
>: In article <3892@tau-ceti.isc-br.com> briana@tau-ceti.isc-br.com (Brian W. 
Antoine) writes:>: >  In our case, the person who received the system didn't 
think anything about>: >hooking it up to our corporate lan and turning it on.  
Needless to say all>: >hell broke loose when someone noticed that we were now 
broadcasting routes>: >out the internet link for a very bogus network.

>: I sincerely hope you've fixed whatever procedural problem caused this
>: to happen.  It makes no difference whether the node's configured IP
>: address was registered or not.  In fact, if it were an address
>: officially assigned to your customer, you might have disabled your own
>: customer's link to the Internet by usurping the actual routes to his
>: network.  As it was, if you hurt anyone, it was an unrelated third
>: party.  That's very bad, of course, but it would have been even worse
>: if you had lost a customer over it.
 
>  Yes, it's been fixed, or at least it's fixed if the procedures are followed.
>Returning systems are not hooked to the main lan at all.  At best they get
>hooked to an isolated lan in either the repair area or a special test lab.
>The potential is still there though for us, or anyone else that ever gets
>a system back from a customer.  You're right, it doesn't even have to be
>an invalid address to cause problems.  It makes you wonder just what
>percentage of routing problems on the internet are caused by screwups
>like this.  I'd hope that they were a very small percentage, but I'd also
>bet that the number is larger then zero.

[unlurk]

While we're on the subject, how does one go about registering?  In my case, 
I suppose it would be class C.

--
  --------------------------------------------------------------------------
  -------Visit the SOUNDING BOARD BBS +1 214 596 2915, a Wildcat! BBS-------
    WHO:                      DO:
    Patrick Taylor [INTP]    |Borland C++, Borland Pascal, SqlWindows.
    Ericsson Network Systems |Turbo Assembler, and Paradox 3.5
    exuptr@exu.ericsson.se   |ObWarning: "Don't let the .se fool you"

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 17:24:01 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: non-sequential connect/accept??

>My problem:  if I start the server, then do
>	for i in 1 2 3 4 5 6 7 8 9 10; do client $i; done
>the server accept()'s the client requests out of order.  A typical order
>is:  1 5 10 9 8 7 6 4 3 2.  I've determined that the client's
>connect()'s complete and return before the server actually accept()'s
>the connection.  (I ran both processes on the same system and printed
>time stamps just after the connect()'s and accept()'s. I also passed a
>timestamp from the client to the server as part of its data.)
>
>My questions:
>	1) Is this out-of-order accept() behavior valid/expected?
>	2) Is this typical behavior in a BSD-derived TCP implementation?

I'm told this LIFO instead of FIFO returning of the accepted connections
is an old Berkeley bug that some vendors have fixed, and others haven't.
I know it's still in SunOS 4.1.3, but has been fixed in SunOS 5.  As I
recall AIX 3.<something> also has the correction.

I've never tried to determine exactly what the source code fix is.
Anyone know?

>	3) Is there a simple and standard way to serialize the accept()'s
>		so they occur in the order 1 2 3 4 5 6 7 8 9 10?

Bug your vendor. :-)  I'd bet you're on SunOS 4.1.x?

>I've determined that the client's
>connect()'s complete and return before the server actually accept()'s
>the connection.

This is the common implementation technique for TCP.  accept() does
not return until the 3-way handshake is complete.  This means that
the TLI notion of t_listen() returning when the connection request
arrives, and the use calling t_accept() to explicitly accept the
connection is patently false for TCP.  (It may apply to TP4, but
who cares.)  Also, SunOS 5 has a way to change this (try turning
tcp_eager_listeners off) but I'm told that it breaks many existing
applications (such as FTP).

	Rich Stevens  (rstevens@noao.edu)

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 1993 17:34:31 GMT
From:      nam@peregrine.esl.com (Nam N. Nguyen)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   netmasks

I have a question about the UNIX netmasks and broadcasts thing:

I have two SUN sparcstations, A and B, connected to the same backbond.

On A, when I do ifconfig -a, the netmask and the broadcast value are

	fffffc00, 129.193.144.0, respectively.

On B, the same command yields:

	ffff0000, 129.193.0.0.

From my basic understanding of these commands, I thought this would
prevent A and B from seeing each other because of different masks.
But that was not the case!  They can 'ping' each other, ...

Netters with thorough understanding of 'netmasks' and 'broadcasts',
please explain the above to me (via e-mail).  Also, what differences,
in behavior, would the above cause to hosts A and B?  Please give
me some examples!

Thanks,

Nam N.


-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 17:56:43 GMT
From:      clbooks@netcom.com (Computer Literacy Bookshop)
To:        comp.protocols.tcp-ip
Subject:   FREE Talk on IP Addresses

FREE talk as part of Computer Literacy Bookshops' Grand Opening of
East Coast location. For complete speaker schedule, get from
netcom.com /pub/clbooks/tcspeak.txt or ftp.uu.net /vendor/clbooks/tcspeak.txt
or email to rachel@clbooks.com

=====================
Wednesday September 8 
=====================
6:00 PM
-----------
Dave Piscitello
Author of Open Systems Networking: TCP/IP and OSI
"TUBA: A Solution for IP Address Exhaustion"
The Internet is a victim of its own success. Its current 32-bit 
address space is inadequate for global addressing and routing; the 
core Internet Protocol (IP) must be changed. Piscitello describes 
the underlying technical issues and the likely solution (TCP/UDP 
over Big Addresses, or TUBA).

Dave Piscitello works on broadband data services and network 
management at Bellcore. He participated in OSI/Internet standards 
development and has written several OSI standards including ISO 
CLNP.

To subscribe to our ongoing event mailing list, send your email 
address to:
East Coast: events_va-request@clbooks.com
West Coast: events_ca-request@clbooks.com

   
Computer Literacy 
Bookshop

Hours:  Monday-Friday 9AM-9PM
	   Saturday-Sunday 10AM-6PM
Tysons Corner (Vienna), Virginia
8603 Westwood Center Drive (near American Cafe)

From the beltway: Take Leesburg Pike (Route 7) West to Westwood 
Center Drive. Turn left at the American Cafe. We're in the same 
complex, two buildings down on the left.

Phone:  703-734-7771

Questions? rachel@clbooks.com

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 19:24:26 GMT
From:      dwing@uh01.Colorado.EDU (Dan Wing)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP to a VAX ?

In article <Michel.Dalle.10.0011DBC3@sni.be>, Michel.Dalle@sni.be (Michel 
Dalle) writes:

>What exactly can you do between a UNIX and a VAX (VMS) system with TCP/IP ? 
>I mean, is it just telnet, ftp etc., or can I use other existing applications ?

Depends entirely, 100%, on which TCP/IP package you're running on the VAX.
A VAX, straight out of the box, doesn't have TCP/IP software, and you must
purchase the software from one of about 8 vendors of VMS TCP/IP software.

Some of the packages only support a few applications, while others support
a full suite of applications.  There are also a bunch of applications that
are freely available from the Internet for VMS, just like Unix applications 
are available:  gopher, an SMTP MTA, POP, name server utilities, news 
readers and news servers, etc.

>Can I expect any problems when using "older" VAX systems (I heard somewhere 
>that they didn't really support TCP/IP in native mode or something before 
>DECnet Phase IV or V), or can any application running on the VAX use TCP/IP as 
>a protocol stack ?

DECnet has nothing to do with TCP/IP.  And a VAX does not need to run 
DECnet -- you only need to have/use DECnet if you are going to use DECnet.

"Old" VAX hardware doesn't have to run "old" software, though -- you can
upgrade the software on your system to be newest versions of VMS if you 
want, thus allowing you to run the software from a wider variety of sources 
(some software requires a certain minimum version of VMS).

>Any other peculiarities we're not used to when connecting UNIX boxes together

Depends on which TCP/IP package you have on your VAX - some are better than
others.

>I know these questions are all a bit vague, but I'd like to know what to 
>expect. Thanks for any information. Please email any comments, and I'll 
>summarize if there's any interest in this matter.

[Emailed and posted]

-Dan Wing, Systems Administrator, University Hospital, Denver
 dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 1993 20:11:06 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <1993Aug20.142504.528@turtle.fisher.com> schaubert@turtle.fisher.com writes:

I've been working with a guy at Vanderbilt to produce a new bootp based on
the Stanford/CMU code including Frank da Cruz' RFC 1395 mdos and my RFC 1497
mods; we plan on releasing the code for beta tomorrow or Monday. (Think of
it as bootpd 2.4, since that's what we're calling it.)

Once that's out, I plan on tossing in dynamic IP address allocation as well.
Maybe I ought to look at the DHCP stuff instead...

Jason Zions
jazz@hal.com



-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 1993 20:29:17 GMT
From:      jazz@jazz.hal.com (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <1993Aug23.111425.412@eisner.decus.org> saunders@eisner.decus.org writes:

   Be careful with absolutes like "everyone". I believe my expectations are
   based on AppleTalk's ATP protocol and Xerox's SPP protocol,

I've got some great expectations based on TOPS-20 and Unix. They seldom get
met under MS-DOS or Windows. Welcome to the IP world, built on different
assumptions than ATP or SPP.

   and by the
   feeling that if the Transport layer informs me when my connection has
   been established (by completing my select(), perhaps), then it should
   also inform me when the connection breaks.

It does. You get informed when the application on the other side of your
connection took explicit action (via accept()) to make the connection; you
get informed when the application on the other side takes explicit action
(via close()) to break the connection.

   Recognizing that dead
   connection establishment requires resources, I'm willing to tell it how
   important detection is to me, by telling it the number of round-trip
   delays during which I'm willing to allow a dead connection to remain.

What does "dead" mean? If the PC gets powered off, that's dead. If the
application locks up, is that dead? Especially if the TCP stack is still
alive and answering pings?

   Of course I'd like to permit the connection to recover from a network
   error, but is it really likely to recover after two hours? And what about
   applications where the network is reasonably reliable? They shouldn't
   have to wait that long.

John, show us an API (function definition with parameters). Show us how it
maps to protocol mechanisms (TCP, IP). If you can make it work and make your
mechanism and API sufficiently flexible to meet all needs, then I'm sure
that most of use implementors would love to implement it.

Until then, only the application developer knows what "dead" means in the
context of his/her application and must take responsibility for doing
peer-death-detection.

(Someone mentioned that there was a "library" layer between the kernel and
application, and that this library layer could provide a higher level of
abstraction and provide this liveness detection. Feel free to build your own
library; at the library level, though, data which gets transmitted to detect
death pretty much has to be in-band, so the remote side has to be using the
same library. Not a general solution. SunRPC includes the concept of a Null
Procedure; by convention, procedure 0 generates a quick-turnaround reponse.
One could build an appropriate library on top of SunRPC that invoked
Procedure 0 if it hadn't heard from the server in X seconds. That's getting
close enough to being under application control rather than system control
that it's not really to the point.)

Jason


-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 21:21:43 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: routed not working properly on AIX?

FYI:  RIP doesn't support subnetting at all.  RIP only advertising the
natural part of the subnetted nettwork.  RIP version 2 will do it.

I don't know if this gives you much help.
**************************
Have a "phuongtastic" day,
Best regards,
Phuong Thanh Nguyen
Networking System.
**************************

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 21:33:56 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: routed not working properly on AIX?

It's hard to see what's wrong if you don't supply the netmask along with
the addresses.

*********************************
Opnions are mine alone not IBM's
Have a "phuongtastic" day,
Best regards,
Phuong Thanh Nguyen
Networking System.
*********************************

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 22:27:23 GMT
From:      jzwiebel@page.mmc.com (John Zwiebel 303-977-1480)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

Several people have discussed automatic allocation of IP addresses via the BootP
 server.

I'm very interested in this because the ICMP Information Request Message is
 going to go away.  (This is discussed in the  ICMP Type15/16 & ARP subject)

I have one problem with the dynamic allocation of the IP address.  The advantage
 of BootP is that it uses UDP broadcasts so the request can transition a router.
  If a server gets a request, but doesn't know the hardware address of the
requestor, how can it be sure of which subnet the request is being made from?

Perhaps this is answered in the draft proposal.  I'll read it, but if someone 
can provide me with a quick summary via email, I'd appreciate it.

-- 
John M. Zwiebel
PAGE Communications
I launch rockets -- sometimes. 

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Aug 1993 22:53:50 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <JAZZ.93Aug26151106@jazz.hal.com> jazz@jazz.hal.com (Jason Zions) writes:

>Maybe I ought to look at the DHCP stuff instead...

Recommended.  

  BOOTP is very useful, but the future is likely to be spelled DHCP.
A couple of the big players in the small computer marketplace have
indicated that they plan to release DHCP support in their next major
releases.



-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 93 23:49:02 GMT
From:      pradeep@starfire.sj.unisys.com (Pradeep Venkatesan)
To:        comp.protocols.tcp-ip
Subject:   rawip brodcasts

I have an application that broadcasts over the network using rawip (protocol
number = 255). The router on the network sends back an ICMP error with type = 3
and code = 2 which translates to "Bad Protocol". None of the hosts on the
network seem to do this.

Is the router misbehaving?. Is it legal to use 255 as a protocol number?.

Thanks for any help,

Pradeep.

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Aug 1993 01:53:49 GMT
From:      db@diana.ocunix.on.ca (Dyane Bruce)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.dcom.lans.misc,comp.sources.wanted
Subject:   DOS client modem sharing

  I apologize in advance if I have posted to an inappropriate group.
I am at the tail end of a slow uucp feed, and I do not get a full feed.
I do _not_ normally see articles for "comp.dcom.lans" for example.

  I am looking for DOS (yech) TCP/IP client software that will convert
a "soft int 14" (Proably the same or similar standard as FOSSIL)
serial connection into an over the wire TCP/IP connection to a
shared modem resource on a unix client. Note I am NOT looking for
an emulation which simply results in a glorified dedicated TELNET.
For example Beame and Whiteside have BWCOM14 which simply allows one
to use your favourite serial MessyDog terminal program instead of their
provided telnet client. This is "hard-wired" to provide a port "23" (TELNET)
only connection to desired client. This is NOT what I want.
What I want to do is have a daemon running on the unix host translate
a TCP connection, into an outside modem connection. The DOS terminal
program would simply see a modem that it can dial out on etc. The
unix client would negotiate the modem port locking ala uucp locking etc.
and report back a busy status if necessary, which could be reported back to
the DOS client as an AT code on a simulated Hayes(TM) interface.
The unix end is trivial to write. It is the DOS client software that
is needed. This is a standard thing that is easily done under Novell,
and other DOS networks. I can't believe that there isn't such a thing
for DOS TCP clients.

  I am already checking into TUN to see if they can do this.
Does anybody know of a package that already does this?

  Failing this, does the CRWNR (sp) package allow this? Perhaps
I will have to the DOS end myself?

  It would probably be best to reply by email.

Thank You...
-- 
Dyane Bruce				db@diana.ocunix.on.ca
29 Vanson Ave. Nepean On, K2E 6A9	So who first started the tradition of
613-225-9920				putting witty sayings in sigs anyway?

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 93 08:44:24 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <CCAq8E.2L3@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:
>> barmar@think.com (Barry Margolin) writes:
>> It could certainly be made more efficient building this into the Unix kernel
>> rather than relying on the application programmer needing to add a separate
>> acknowledgement protocol to his/her program.
> 
> It isn't, though, because no two applications want things done in the same
> way.  Even a single application will often want things done in different
> ways at different times, depending on its state.  (I.e. if a client has
> database records locked on the server, you want a fairly short timeout; if
> the client is in a resting state with few resources in use on the server,
> you want a much longer timeout.  Sendmail wants long timeouts, because it's
> unattended, but the receiver-SMTP mustn't return the final ack until the
> message is guaranteed written to disk.)  How can the kernel detect this?
> 

It's tru that no two applications want things done "in the same way", but I
believe that the "difference" in most cases amounts to a different timeout
setting, and perhaps a different retry count. I would think that two socket
options could accommodate that.

In all applications I've ever worked on, if the client's TCP/IP implementation
is unreachable for a sufficiently long time, we can presume that the client's
connections at the session layers and above are either nonrecoverable, or at
least not recoverable on the same transport connection.

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

John Saunders
saunders@eisner.decus.org

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 93 08:49:44 -0400
From:      saunders@eisner.decus.org
To:        comp.protocols.tcp-ip
Subject:   Re: Application Standard for Keepalive?

In article <25gas0INNd4r@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> In article <CCAq8E.2L3@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>>dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
>>> It could certainly be made more efficient building this into the Unix kernel
>>> rather than relying on the application programmer needing to add a separate
>>> acknowledgement protocol to his/her program.
>>
>>It isn't, though, because no two applications want things done in the same
>>way.  Even a single application will often want things done in different
>>ways at different times, depending on its state.  (I.e. if a client has
>>database records locked on the server, you want a fairly short timeout; if
>>the client is in a resting state with few resources in use on the server,
>>you want a much longer timeout.  Sendmail wants long timeouts, because it's
>>unattended, but the receiver-SMTP mustn't return the final ack until the
>>message is guaranteed written to disk.)  How can the kernel detect this?
> 
> On reflection of this thread, I believe that what's necessary, and perhaps
> what some of the posters were actually asking for, is not enhancements to
> the protocols, but simply some better higher-level library routines.
> 

Speaking only for myself, what I want is simpler.

1) I believe the TCP/IP protocol already has the facilities a network kernel
would need to implement keepalive.

2) I want to know when a transport connection enters a state in which it will
never again be useable. As an approximation to this, I want to know when the
client's TCP/IP has failed to ack keepalive packets sent at interval "x" over
timespan "y".

3) I require that this be settable per-server

4) I'd like this to be settable on a per-connection basis, during a connection.

> -- 
> Barry Margolin
> System Manager, Thinking Machines Corp.
> 
> barmar@think.com          {uunet,harvard}!think!barmar


John Saunders
saunders@eisner.decus.org

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 93 09:54:11 EET
From:      jaakola@cc.helsinki.fi
To:        comp.protocols.tcp-ip
Subject:   "Terminal Server" RS-port to RS-port

Hi!

We have two buildings and we need to connect machines on those
buildings. The problem is that the machines only communicate via RS-232
or RS-422 lines. However, I have UNIX boxes on both locations, and those
boxes have RS ports. We have an ethernet between those locations and
would like to use that. We hate the idea of having many cross-building
RS cables.

How can I make the UNIX boxes a kind of "terminal servers", which would
provide a transparent connection from one RS port to another?  I think I
could do some hacker work with UNIX, rlogin and so on, but is there a
package or application protocol designed for this? I hate to struggle
with automatic login via telnet/rlogin and struggling with control
characters.
--
Juhani Jaakola, jaakola@cc.helsinki.fi

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 1993 09:24:59 +0200
From:      behe@inasys.uucp (Bernd Hentig)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: routed not working properly on AIX?

In article <CCDy07.GJr@sernews.raleigh.ibm.com> phuong@rocky.raleigh.ibm.com (Phuong Nguyen) writes:
>FYI:  RIP doesn't support subnetting at all.  RIP only advertising the
>natural part of the subnetted nettwork.  RIP version 2 will do it.
>
How about just starting /etc/gated ?
This works perfectly for us, though I don't know whether it will solve
your special problem (your original posting got expired, sorry).
However, with gated enabled, I can reach several subnets within our
domain that are advertised via RIP (even Novell Netware 3.1 can be
used for routing ...).

Bernd

-- 
Bernd Hentig       | Email behe%inasys.uucp@Germany.Eu.net
inasys GmbH        | Phone Voice (Germany) (0)228 5205 451  FAX ~ 100
D-53121 Bonn       | 
  Germany          | ======== INTERNET - Gateway to Infinity ========

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Aug 1993 13:30:41 GMT
From:      bounds@gulaam.glv.com (Frank Bounds)
To:        comp.protocols.tcp-ip
Subject:   recoverable ftp/ftp wrapper


Anyone aware of a version of ftp that can detect failed xfers and
restart or flag the fact that it failed in some meaningful way
(so it could be restarted automatically)? We would need to do this on UNIX 
and VAX/VMS systems. 
--
                                                        ___
                                                       |___|
                                      +----------------||-----++
                                      | Frank Bounds   ||     ||
                                     /| bounds@gulaam.glv.com ||
                                    | | ENCOMPASS             ||
                                    | | Cary, North Carolina  ||
                                  --| +-----------------------++
                                  --| |-----------------------/

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 1993 21:34:03 -0400
From:      masato@access.digex.net (J M Thompson)
To:        comp.protocols.tcp-ip,comp.protocols.time.ntp
Subject:   SUMMARY:  NTP for IBM MVS/ESA environment

Well gang, it looks like the news is not good  :-(

First my original question:

>I am looking for an implementation of Network Time Protocol (NTP)
>(public domain or otherwise) for an IBM MVS/ESA system.  IBM's 
>MVS/TCP/IP program product is on the MVS system.  As I understand it,
>IBM does not currently have an implementation of NTP in the current version,
>and it is questionable if there will be a NTP in the next release.
>
>If a full implementation is not available, I am willing to settle for
>the MVS host serving as a time server and other UNIX-based systems
>setting their times to MVS.  It is also not required that the 
>MVS host sync with an external time source.  I just need to keep
>the MVS and UNIX systems in our internal network time synchronized.
>
>To help prevent news group clutter, email response to me and I will
>summarize for the news group as appropriate.

After about four days I received three replies.  The respondents did not
know of any MVS-based implementations for NTP.  The replies ranged from
mutual interest to some views on implmentation.  Some of the comments 
received follows:

>I have been looking for the same thing for about 6 months.
 
>I was originally looking for a timed daemon for MVS TCP/IP, and I had no 
>luck. IBM gets really upset about changing the time on an MVS without
>warning. They have no plans, either currently or future, to support anything
>like that, according to the MVS group.

---

>IBM has demonstrated OSF's DCE running on MVS in public forums.  This
>interoperates with all of the UNIX and PC versions as well.  
>
>One of the components of DCE is the Distributed Time Server (DTS).  While
>there appear to be strong feelings on both camps of which is "better" as
>a time synchronization protocol, both solve the problems of keeping a single
>view of time consistent.

---

>Well, maybe they fixed it in the S/390, but on the S/360, S/370,
>43xx, and 30xx machines, there was this ugly little thing called
>the TOD Enable Key that had to be depressed in order to allow a
>Set Clock instruction suceed.  NTP makes the assumption that
>it can "bump" the system clock by several milliseconds, every
>few seconds.

---------

Since it looks like Plan A is not viable, I am thinking about Plan B, 
which is to take a PD NTP available from anon ftp and port what I need
to MVS.  For my purposes, I do not need to time sync with an external
primary clock.   I just need to sync to the local MVS time, so I don't
think I will have to "bump" the clock.

Any comments or ideas on Plan B would be greatly appreciated.


-- 
---------------------------------------------------------------------
Jim Thompson                     
email: masato@access.digex.com  
daytime phone: 703-759-8252    

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Aug 1993 16:01:50 GMT
From:      jzwiebel@page.mmc.com (John Zwiebel 303-977-1480)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Type15/16 & ARP

I want to thank Tony Li of cisco for his patience and assistance and Don Provan
of Novell for his suggestions.

After much debate and research the reasons for implementing ICMP Information
Request/Response packets has largely gone away.  The propose Router Requirements 
being edited by  Philip Almquist (Jessica.Stanford.EDU) which is suppose to
replace RFC1009 specifically states that a router SHOULD NOT respond to these 
requests.  SHOULD NOT means it is the vendors option to implement code that
will provide a response but it would have to be configurable and should default
to off.  RFC1122 says the same thing about HOSTS.

I have a test tool that doesn't support a console and that can be plugged into
my network on any subnet.  I needed to get the subnet octet and the Type15/16 
worked perfectly.

Don Provan suggested that I use the Address Mask Request/Reply: RFC-950 to get 
the subnet octet.  The proposed router requirements document states that a
router MUST support this request.  I'll be kludging the use of the response but
it will work.

The other options were to use RARP and BootP.  Both of which require special 
configuration files that would have to have been kept on several hosts and 
which would change depending on where the test tool was connected.  This is
workable but I feel will require too much coordination between the Test Tool 
users and the Network Administrator, resulting in a lot of trouble getting
that test tool up and running.

There is another proposed protocol DHCP that is being discussed in this news
group.  This protocol may support the functionality I require.  

So, I'm keeping the Type15/16 request on my test tool but adding the Type17/18
and DHCP requests.  That way I'll be able to bridge from the current practice
which works to the new stuff that should be coming.  I'm also thinking about 
including a RARP request in the Test Tools boot procedure.  

Thanks again to all for their input including Cynthia Clark <cclark@cnri.reston.va.us> for pointing me to the IETF hosts listed below:


IETF Information is available by anonymous FTP from several sites.

        East Coast (US) Address:  ds.internic.net (198.49.45.10)

        West Coast (US) Address:  ftp.nisc.sri.com (192.33.33.22)

        Europe Address:  nic.nordu.net (192.36.148.17)

        Pacific Rim Address:  munnari.oz.au (128.250.1.21)

-- 
John M. Zwiebel
PAGE Communications
I launch rockets -- sometimes.

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 93 16:40:18 GMT
From:      sheketof@grip.cis.upenn.edu (Mike Sheketoff)
To:        comp.protocols.tcp-ip
Subject:   Matching physical to logical addresses

Hello,

	I am in need of some utility or protocol that would allow me
to find out the physical address of a given IP address (such as ARP)
or vice versa (such as RARP).  Some of the problems I have encountered
is ARP will only work if the host talks ARP and is on the same
segment as the requesting host.  Otherwise the routers will
answer and you would get the wrong physical address.
	RARP on the other hand seems to require a name server on the
same segment as the requestor otherwise the bridges and routers will
filter broadcast addresses.
	Is there another protocol I can use to find out this information
without having to enter all this in manually.

	Please respond via email to this address.
Thanks in advanced.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Aug 1993 18:25:37 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Using Class C Net for Net Interfaces


	We have a situation where we would like to connect several remote
class C networks to our campus network using 3Com bridge-routers.  We have
one class C network which we would like to use for the network Interfaces
of the routers joining the remote nets to ours.  Our regional Internet
provider uses this scheme and a subnetted class B network to handle their
lines.  What we would like to know is has anybody successfully subnetted a
Class C network for this purpose?  I am quite aware that class C networks
are usually not subnetted, but the only interfaces appearing on each of the
lines in this situation would be the routers on each end.  Their subnet masks
would be the only considerations involved.  

	This looks theoreticallypossible, but I would like to know if anybody
has tried this and discovered that it did not work.
We are presently bridging the remote networks to our network and being eaten
alive with broadcasts which fill the serial lines with excess traffic and
prevent valid traffic from being sent.

	Any ideas are appreciated.  Thank you.

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

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 93 19:13:29 GMT
From:      chougaby@inf.enst.fr (Gaby Choucrallah)
To:        comp.protocols.tcp-ip
Subject:   FTP and SMTP use in programs ?


Hi all,

As stated in RFC959, the FTP protocol, though usable directly by a 
user at a terminal, is designed MAINLY for use by programs.

Could anybody please tell me how to do that: What are the APIs to
use in order to implement the FTP in an application program ?

What about SMTP ?

Thanks for posting or replying to chougaby@inf.enst.fr

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Aug 1993 19:29:08 GMT
From:      jzwiebel@page.mmc.com (John Zwiebel 303-977-1480)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

Can someone point me to some example code for DHCP?

-- 
John M. Zwiebel
PAGE Communications
I launch rockets -- sometimes.

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Aug 1993 16:33:00 GMT
From:      evans@ubvms.cc.buffalo.edu (Doug Evans - CIT, Comm Systems Eng)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

In article <1993Aug15.020842.16520@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James) writes...
>I would offer slightly different advice.
> 
>If I were you I would use the ODI interface and use odipkt or pdether. 
>The way I always do this is change the net.cfg 
> 
>add the following
> 
>link driver 3c509    	# replace 3c509 with your mlid name.
>   frame ethernet_802.3	# this is what we run our ipx over
>   frame ethernet_II 	# this is what we run ip over

Are you saying that you're running NCSA Telnet over ODI?  From my experience,
I've never been able to get Telnet to run with any type of ODI stack.

Doug
--
                                  |                              Doug Evans
                                  | State University of New York at Buffalo
                                  |             evans@ubvmsb.cc.buffalo.edu


-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Aug 1993 17:49:11 GMT
From:      phuong@rocky.raleigh.ibm.com (Phuong Nguyen)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: netmasks

They both have the same natural class B address = 129.193.0.0, even though,
in A you try to subnetted with mask 255.255.252.0.  But B will not have
problem to find A and A can find B also.

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Aug 1993 19:14:01 GMT
From:      lesv@ppvku.ericsson.se (Lennart Svensson)
To:        comp.protocols.tcp-ip
Subject:   Count gateways

I wonder if somebody can solve my problem. Is it possible in some way to
see how many gateways a datagram has passed.

The problem is a server - client connection where the server should not
answer (Maybe negative) in the case that there is to many gateways
involved.

The best solution for me is to solve everything on the server side
so there is no change in the client code.

Please help somebody


			Regards
			LeSve


E-mail      lesv@ppvku.ericsson.se




-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Aug 1993 20:43:47 GMT
From:      Dave@Yost.COM (Dave Yost)
To:        comp.protocols.tcp-ip
Subject:   FTP demon notifies of new versions

New ftpd features:

1.  When I ftp file F from host H, ftpd on H associates
    my email address, A, with F in its database.  The
    next time F is updated it sends me email announcing
    the change.  Once the email has been sent, or when F
    has been deleted from the server for n days, ftpd
    breaks the connection between A and F.  When A is
    no longer associated with any files, A is deleted
    from the database.

2.  When a user with email address A ftpees file F to
    host H, H associates A as the maintainer of F in
    its database.  Subsequent email to ftpd@H with a
    subject line that containes the full path to F is
    dist'ed to A.

Has anyone built anything like this?

-- 
  Dave Yost
      @    .COM

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Aug 1993 01:16:45 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Count gateways

In article <1993Aug28.191401.10011@ericsson.se>, lesv@ppvku.ericsson.se (Lennart Svensson) writes:
> I wonder if somebody can solve my problem. Is it possible in some way to
> see how many gateways a datagram has passed.
> 
> The problem is a server - client connection where the server should not
> answer (Maybe negative) in the case that there is to many gateways
> involved.
> 
> The best solution for me is to solve everything on the server side
> so there is no change in the client code.
> ...


There is the Record-Route IP option.

Sample code is in 4.3BSD source for `ping`.  Perhaps not in Net2,
but later.  Buy one of the CDROM's of Net2 source.


Vernon Schryver,  vjs@sgi.com

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 1993 14:53:23 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <juhi586@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com
 (Vernon Schryver) wrote:
>In article <254srp$dmo@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam)
 writes:
>>Because in a typical terminal server which also support SLIP/PPP
>>(like a Cisco or an Annex), the IP address it assigns to a serial
>>port is actually for the far-end (user-end) of the serial line.
>
>That seems like a dumb way to do things, at least with PPP where
>you could force the remote address only when necessary, ...

Those terminal servers worked that way because they only expect/allow
a single remote host, not a network of them, to be at the far-end of
the serial line.  The single IP address such a terminal server assigns
to the far-end of a serial lines is actually one from the IP subnet
which its own LAN interface is connected to, and it also does proxy-ARP
for this IP address on the LAN to make it look like the remote machine
is actually part of that LAN.

The result of this is that although you can only attach one host at the
end of each serial line, your host will look to the rest of the Internet
to be on the LAN the terminal server is on (except it takes longer to
ping you) and the routing issue is automatically taken care of without
involving routing protocols and extra IP network/subnet numbers.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>


-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 1993 21:07:04 -0700
From:      koreth@spud.Hyperion.COM (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Firewalls could help put off the IP address shortage

As I was poking around the Internet this evening, it occurred to me that many
of the organizations with large chunks of the network address space (Xerox,
to pick one at random) have relatively few machines actually connected to the
outside world.  The vast majority are hidden behind IP-proof firewalls that
won't pass any packets from inside to outside or vice versa.

Then it occurred to me: Why can't nets behind firewalls use the entire IP
address space as they see fit?  All they need to be able to do is route to
the firewall (or a secondary firewall -- more on that in a sec) to get mail
out, establish connections via proxy-telnet servers, and so on.  What harm
is it if Xerox uses, say, Hyperion's net number of 192.65.216 internally,
since no routing information is propogated outside of Xerox?

And, turning it around, why does the rest of the net need to lose a class-A
network number to a net full of unreachable machines?

Maybe I'm crazy, but it seems to me that firewalled organizations should
only need a few class-C addresses assigned to them officially; they can do
whatever addressing they want behind the firewalls, and nobody will be any
the wiser.

In reality, you'd want a two-stage firewall, one that knew the routes to
the internal machines and one that knew the routes to the outside world;
if you only had one firewall, it wouldn't know what to do with a packet
addressed to a network existing on both sides of the wall.  With two
firewall machines that can route to each other and their respective sides
of the wall, everything would work nicely.

Apart from aesthetic concerns, is there a problem with this idea?  It seems
like implementing it -- having firewalled organizations pick a class-C net
or two for their gateway machines, then giving their assigned A or B network
numbers to someone fully-connected -- would instantly free up a huge number
of addresses and at least stave off the IP address shortage for a while
longer.

Comments?

-Steve

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 93 15:30:47 MDT
From:      atheist@Apocalypse.CAD.UCLA.EDU (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   SOSS as nfs server with sun mounting to it


Would anyone who has managed to set soss up as a pcnfs server to a SUN
please e-mail me.  Thanks

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 93 21:17:54 PDT
From:      olson@osiris (Brian Olson)
To:        comp.protocols.tcp-ip
Subject:   Re: pc nfs

In article <CCI309.8Is@nmrdc1.nmrdc.nnmc.navy.mil> you wrote:

: I'm trying to run an nfs daemon on a PC (cheaper than buying a new
: unix hard drive for our sun).  
: I've got a copy of soss
:  on a machine with a 3c501,,
: the 3c501 is loaded at 0x7e interupt,
: I've used custom to put the inportant information in it, and it's 
: loaded device=netdev.sys.  
: soss runs and claims current exported filesystms are :
: c:\ and d:\   
: As I've told it to,
: then 
: netd: port mapper, mountd and nfs server running,
: Yet when I try to mount a file system from a sun , I get nothing
: the sun gives and rpc error after a while.
: but there's nothing from the pc, I can't even ping it
: any suggestions?

As I seem to recall, SOSS has an NFS read/write size limitation of 1024,
so be sure to specify these upper limits when mounting from the Sun.

Hope this helps.

-Brian


Brian Olson
Emeritus Technologies - Home of the TapeWare tape backup software.
2750 N. Clovis Ave.         !FREE TAPEWARE DEMO - just e-yell!
Fresno CA 93727  U.S.A.
voice: (209) 292-8888   fax: (209) 292-8908   14.4K BBS: (209) 292-0541
----------------------------------------------------------------------------




-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Aug 1993 17:51:59 GMT
From:      ben@osuunx.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip
Subject:   Re: Can I have IPX and TCP/IP at the same time?

In article <CCH9uu.39K@acsu.buffalo.edu> evans@ubvms.cc.buffalo.edu (Doug Evans - CIT, Comm Systems Eng) writes:
>In article <1993Aug15.020842.16520@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James) writes...
>>I would offer slightly different advice.
>> 
>>If I were you I would use the ODI interface and use odipkt or pdether. 
>>The way I always do this is change the net.cfg 
>> 
>>add the following
>> 
>>link driver 3c509    	# replace 3c509 with your mlid name.
>>   frame ethernet_802.3	# this is what we run our ipx over
>>   frame ethernet_II 	# this is what we run ip over
>
>Are you saying that you're running NCSA Telnet over ODI?  From my experience,
>I've never been able to get Telnet to run with any type of ODI stack.
>

NCSA does work over odipkt which is a odi to packet-driver shim.  ODIPKT
links into the ODI interface as a Default packet stack which means that
any packets which are not accepted by stacks registered to the lsl will
be given to odipkt.  The only time ODIPKT will not work for TCPIP is if
you load Novell's TCPIP.EXE since they will accept all of the TCPIP
packets and odipkt will never recieve any.

With the above configuration you would load odipkt with the command line
parameters of odipkt 1 96 to get a packet-driver loaded onto your 3c509
at hex interrupt 0x60 and using ethernet_II frameing.

The command line parameters are first the packet stack offset number
where you start at zero and count the number of frames loaded by the
mlid drivers until you get to the one which you would like to load
odipkt over.  In the above example 0 would be for ethernet_802.3 and 1
for ethernet_II and 2 for the next frame type if there were one.

The second is the interrupt vector in decimal which 96 is equivalent to
0x60 hex which you would define in your config.tel.  

Ben James 



-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 93 23:02:10 GMT
From:      jeff@neon.rain.com (Jeff Beadles)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

koreth@spud.Hyperion.COM (Steven Grimm) writes:

...
>Then it occurred to me: Why can't nets behind firewalls use the entire IP
>address space as they see fit?  All they need to be able to do is route to
>the firewall (or a secondary firewall -- more on that in a sec) to get mail
>out, establish connections via proxy-telnet servers, and so on.  What harm
>is it if Xerox uses, say, Hyperion's net number of 192.65.216 internally,
>since no routing information is propogated outside of Xerox?
...

This won't work.

How will the firewall get to the real "Hyperion's" net?  They will see
the routes to the internal "Xerox" networks, and take that route.
(If they didn't see that route, then nobody could connect via IP to the
firewall anyway.)

This is un-good.

Now, if all sites behind firewalls used the same IP addresses,
and you removed all incompetent sysadmin's who would do things like
leak routing and DNS information, & stuff, then you might have a chance
in making something like this work.  I doubt it though, if past
performances are any indication.

	-Jeff
-- 
Jeff Beadles       jeff@onion.rain.com

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 00:24:18 GMT
From:      bfriesen@iphase.com (Bob Friesenhahn)
To:        comp.protocols.tcp-ip
Subject:   Socket to serial interface program?

I am looking for UNIX source code to a program which accepts opens on a
specified TCP port and then copies data to/from a specified serial
port.  The idea is to allow programs that currently use sockets to
instead use a serial port with no code changes to the program.

I am interested in either a daemon style server or a program that
can be intiated on a per-instance basis.

Thanks,

Bob




-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1993 17:37:50 -0700
From:      koreth@spud.Hyperion.COM (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In <25stoi$ie0@neon.rain.com> jeff@neon.rain.com (Jeff Beadles) writes:
>This won't work.
>How will the firewall get to the real "Hyperion's" net?

I addressed that in my original post.  You use two firewalls that can route
to each other; one, the "external" firewall, also has routes to the outside
world, while an "internal" firewall (a separate machine) has routes to the
inside world.  The two don't propogate routing information to each other.

-Steve

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 06:09:16 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <25r8gj$2jb@vanbc.wimsey.com>, skl@Connectivity.com (Samuel Lam) writes:
> >
> >That seems like a dumb way to do things, at least with PPP where
> >you could force the remote address only when necessary, ...
> 
> Those terminal servers worked that way because they only expect/allow
> a single remote host, not a network of them, to be at the far-end of
> the serial line.  The single IP address such a terminal server assigns
> to the far-end of a serial lines is actually one from the IP subnet
> which its own LAN interface is connected to, and it also does proxy-ARP
> for this IP address on the LAN to make it look like the remote machine
> is actually part of that LAN.
> 
> The result of this is that although you can only attach one host at the
> end of each serial line, your host will look to the rest of the Internet
> to be on the LAN the terminal server is on (except it takes longer to
> ping you) and the routing issue is automatically taken care of without
> involving routing protocols and extra IP network/subnet numbers.


Oh, proxy-ARP.  Ack.  Ptooey.

If SLIP or PPP is being used only as part of a fancy, multi-session,
file transfering terminal emulator with disks, I guess that's a
reasonable if distasteful solution.  Hassling with full Internet
routing for such customers would be a more expensive, more error-prone,
more distasteful waste of time and effort.

Still, as the author of commerical SLIP and PPP code, I regularly hear
complaints from people who mess up their proxy-ARP schemes, or who buy
a second remote machine, or decide it would be swell to connect both
their PC and their MAC to the Internet at once, and then discover that
proxy-ARP is not a substitute for routing.

Using proxy-ARP conserves address space and core router table entries,
but in the promised future wired-world, proxy-ARP will have to go away.
I hope.


Vernon Schryver,  vjs@sgi.com

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 93 08:37:53 GMT
From:      mvbr@se.alcbel.be (Marc Verbruggen)
To:        comp.protocols.tcp-ip
Subject:   Winsock vs. JSB


--
We are lookinh for a TCP/IP package running on OS/2 and supporting the JSB 
sockets. Is Microsofts Winsock solution ok ?
-----------------------------------------------------------
Marc Verbruggen                 tel : 03.240.94.19
Alcatel Bell Telephone          fax : 03.240.99.50
F. Wellesplein 1                email : mvbr@se.alcbel.be
B-2018 Antwerp
Belgium
 
"System Manager's Headaches Are Not Cured With Aspirin,
 There Is A Better Way ..."

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 08:53:37 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <25rud8$hi2@spud.Hyperion.COM> koreth@spud.Hyperion.COM writes:
>
>Then it occurred to me: Why can't nets behind firewalls use the entire IP
>address space as they see fit?  

Yes, I have been nudging this issue around for months.  I am
developing an IP internetworking strategy for a large UK organisation
who DOES NOT WANT to be connected to the Internet ...  (except
a few workstations in a medical physics department.... :-)

>
>Maybe I'm crazy, but it seems to me that firewalled organizations should
>only need a few class-C addresses assigned to them officially; they can do
>whatever addressing they want behind the firewalls, and nobody will be any
>the wiser.

Yes, That's what I'd like for this organisation.

However, one answer I had on this newsgroup was that we couldn't
use FQ domain names, or have a real Internet registered domain name...
This may be true, but I don't really understand why?

> with two
>firewall machines that can route to each other and their respective sides
>of the wall, everything would work nicely.

Interesting.


What sort of organisation do you see using this type of scheme?

It seems to me a key workability issue is whether:

	a) the people who want Internet access are clearly and 
	strictly defined in advance - ie. you can configure them,

or	b) You have got no idea who might want Internet access,
	what their patterns of usage are, outgoing only or incoming
	FTP accesses, how long they want to retain use of the service,
	is it a shifting population..etc..?

With the first scenario it might be easy to do what you suggest?

-- 

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

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1993 09:42:49 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <25rud8$hi2@spud.Hyperion.COM> koreth@spud.Hyperion.COM (Steven
Grimm) writes: 

    As I was poking around the Internet this evening, it occurred to me
    that many of the organizations with large chunks of the network address
    space (Xerox, to pick one at random) have relatively few machines
    actually connected to the outside world.  The vast majority are hidden
    behind IP-proof firewalls that won't pass any packets from inside to
    outside or vice versa.
    
Indeed.  Many people at IETF have already been discussing this.  We call it
a Network Address Translator (NAT).  Think of it as an application layer
gateway.  At this point it appears tractable and very useful.

Tony

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1993 09:44:29 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and IP addresses

In article <k460382@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon
Schryver) writes: 
    
    Using proxy-ARP conserves address space and core router table entries,
    but in the promised future wired-world, proxy-ARP will have to go away.
    I hope.
    
Indeed.  And if things go their current way, we will get a type of
proxy-IDRP that Vern will hate even more....  ;-)

Tony


-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1993 11:37:54 GMT
From:      mcn@b62103.cwru.edu (Michael C Neuman)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <25rud8$hi2@spud.Hyperion.COM> koreth@spud.Hyperion.COM (Steven Grimm) writes:
>
>Then it occurred to me: Why can't nets behind firewalls use the entire IP
>address space as they see fit?  All they need to be able to do is route to
>the firewall (or a secondary firewall -- more on that in a sec) to get mail
>out, establish connections via proxy-telnet servers, and so on.  What harm
>is it if Xerox uses, say, Hyperion's net number of 192.65.216 internally,
>since no routing information is propogated outside of Xerox?
>
>And, turning it around, why does the rest of the net need to lose a class-A
>network number to a net full of unreachable machines?

  Another example being Los Alamos which has it's Red and Yellow partition
machines registered even though they are physically disconnected from the
rest of the internet, with no routing possible.

  The only problem I can see is if someone inside Xerox (to take your
example) wants to send packets to 192.65.216.12, which is both the machine next
door to his, and a machine on Hyperion's net, how does Xerox resolve that
internally? Would there have to be a different procedure used for connecting
to outside-the-firewall machines? If that's the case, how does the firewall
route then, if it gets a packet for 192.65.216.12--how does it redirect it?
Was it meant for Xerox? Or for Hyperion?

  Just some ideas...


-- 
        Mike Neuman                mcn@b62103.student.cwru.edu
  "To make a machine that will be proud of us." - Thinking Machine's motto
==============================================================================
* Maintainer: NeXT netrek archive--b62103.student.cwru.edu:/pub/games/netrek *

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 93 12:40:38 GMT
From:      milionis@odie.ee.wits.ac.za (Taki Milionis)
To:        comp.protocols.tcp-ip
Subject:   Maintaining a large address space

Hello world,

I would like any referneces to a program/database which keeps track of IP 
address allocations. Basically, I have been allocated many class B addresses 
which will be variably subnetted to address WANs and LANs and would like to 
know if anyone has written a program which makes address recording and 
allocation easy, preferably a task which is done by  a non-technical 
person.

Please let me know if this is avail via anon FTP. Also, please contact me by 
e-mail.

TIA,
Taki Milionis,		milionisodie.ee.wits.ac.za.

                              H
Taki Milionis                HHH      ___  milionis@odie.ee.wits.ac.za
                         ___  H ____  |.|  (..011) 716-5423
Wits Elec Eng        O __|.|_ H |. | _|.|  "This snake-skin jacket is a
Joburg               | |.|..| H | .| | .|   symbol of my individuality.."

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 13:26:57 GMT
From:      gnn@cs.utwente.nl (George Neville-Neil)
To:        alt.toolkits.xview,comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Version 2.0 of xv_ping up for anonymous ftp.

Hi Folks,

	I've put up the newest version of xv_ping (an XView based program
to keep track of hosts using ICMP messages) on pegasus.cs.utwente.nl.  You
can anonymous ftp it from there and it is in pub/bandwidth.  The new
version has the ability to read a .xv_pingrc so that you can always get
your favorite hosts when the program starts, and it can also log to a file
(as well as to the output window).

	Please report any bugs to gnn@cs.utwente.nl

Later,
George

--
The sun was shining on the sea, shining with all its might.
It did its very best to make, the billows clean and bright.
And this was very odd for it was the middle of the night.
- Lewis Carrol

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 14:08:20 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   Socket Shutdown

We have a TCP/IP application written using sockets.  We are trying to simulate
a failure by disconnecting the ethernet segment from the back of the machine.  
At this point a timer kicks in, and we do a shutdown.  But this shutdown never
completes.  Looking at the stack trace, one can see that the application is
trying to do the close but the close doesn't finish.  What is strange is that 
when I try to sdb the process, the process will be released and he will try
to reconnect again to the server.  Now my question is how do you force a close
in TCP/IP using sockets?  How do you force an immediate shutdown of the socket?
We have tried using shutdown with "howto" set to 2, but this does not help.  
Our applications have to detect network failures quickly so that we can suspend
our queues, and have it not saturate our processor.  When we are hung on
the TCP/IP socket close, then we are not awakened for about 4 minutes.  How
can we get around this problem?  
                                         Thanks. 

-- 

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 93 15:03:41 GMT
From:      a20@nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <25stoi$ie0@neon.rain.com> jeff@onion.rain.com (Jeff Beadles) writes:

 * This won't work.
 * 
 * How will the firewall get to the real "Hyperion's" net?  They will see
 * the routes to the internal "Xerox" networks, and take that route.
 * (If they didn't see that route, then nobody could connect via IP to the
 * firewall anyway.)
 * 
 * This is un-good.
 * 
 * Now, if all sites behind firewalls used the same IP addresses,
 * and you removed all incompetent sysadmin's who would do things like
 * leak routing and DNS information, & stuff, then you might have a chance
 * in making something like this work.  I doubt it though, if past
 * performances are any indication.

Well, let me say once more what I suggested just some days ago (and many with
me). What if we reserve a class A, some Bs and some Cs just for this purpose ?
If everyone knows what the numbers are, then it would be simple to install
filters to simply never route this net, never send any packet to this net ...

-Marten
RIPE Network Coordination Centre

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 18:04:44 GMT
From:      jq@phcs.com (Jim Quick)
To:        comp.protocols.tcp-ip
Subject:   One Way TCP error detection and recovery

I am using a TCP connection to feed information in one direction from a
serial line protocol converter on one host to a message based server
on another system.  The phone_agent which consumes the messages
provides service by relaying data to other processes.  It does not
return any useful information to the original x328_agent converter.

Here is a simplified description of the processes.

 RS232 (x3.28 protocol) -----> x328_agent ---- TCP socket ----> phone_agent

1.      open a known tcp service address.
2.      loop to accept() service connections from the x328 agent.
3.      for each accept()ed stream, read '\n' terminated messages
        until EOF (typically signalling network down or x328 death).

x328_agent
1.      loop on attempt to connect() to phone_agent with timeout.
2.      open line to x328 device.
3.      on parsing x328 message, send an ascii message to phone_agent
        via socket.
4.      on SIGPIPE write failure loop on re-connect() and retransmit
        failed message.

Problem:

When the phone_agent dies the first subsequent write apparently
succeeds but actually fails.  Only the write of the second message
after failure causes SIGPIPE in the x328_agent.

I know that I could :
a.      Send a small message trailer in a second write.
b.      Send an acknowledgement byte back from the phone_agent
        to the x328 agent after each message.

However, this seems terribly inelegant to me.

Questions:
1.      Is this failure to acknowledge the first failed write
        endemic to all TCP implementations or local to my
        implementation (NeXSTEP)?
2.      I have tried setsockopt TCP_NODELAY at both ends to no avail.
        Is this the solution (but I cannot see it because I'm using
        it wrong)?


Any help would be much appreciated.

If you send mail rather than followup to this group, I will 
summarize in a post of the solution.
-- 
  ___ ___   mail: uunet!phcs!jq     PHCS, Inc. Advanced Technology Group
   / /  /      or jq@phcs.com      It's spelled "Luxury Yacht", but it's
\_/ (_\/     Fax: (617) 863-8575   pronounced "Throat-Warbler Mangrove".
       )   Voice: (617) 861-5579                          NeXTMail O.K.

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 18:09:51 GMT
From:      pradeep@unislc.slc.unisys.com (Venkatesan Pradeep)
To:        comp.protocols.tcp-ip
Subject:   rawip broadcasts

I tried posting this earlier, but apparently it didn't quite make it:

I have an application that broadcasts over the network using rawip (protocol
number = 255). The router on the network sends back an ICMP error with type = 3
and code = 2 which translates to "Bad Protocol". None of the hosts on the
network seem to do this.

Is the router misbehaving?. Is it legal to use 255 as a protocol number?.

Thanks for any help,

Pradeep.

(pradeep@sj.unisys.com)


-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 18:50:55 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How to send ICMP packets?

In article <25teo4$6mt@oak4.doc.ic.ac.uk> cmft@doc.ic.ac.uk (C M F Tsang) writes:
>
>I am trying to send some ICMP packets to some machines, the system
>we are using is SunOS, i.e. bsd Unix. I know you can open a TCP
>socket in bsd and use services like whois, but I can find the 
>method to send a raw ICMP packet, indeed an IP packet down the net.
>
>Could someone advice me how to do it? The basic thing I know is
>to open a RAW UDP socket, but I'm not sure about how to assemble
>the packet and write it, and how to receive the reply?
>Do I use recv, recvfrom ... which of that lot?


Look at the 4.3BSD ping.c source.  It should be on Uunet somewhere.
Or in the 386bsd and NetBSD archives on agate.berkeley.edu.  Or
on several published CDROMs.


Vernon Schryver,  vjs@rhyolite.com

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 19:02:38 GMT
From:      ajj@beta.lanl.gov (Andrew J. Johnson)
To:        comp.protocols.tcp-ip
Subject:   MacTCP BOOTp Multicast

Latest version (2.0.2) that I have of MacTCP uses a Multicast
address (01005E7FFFFF) to send out BOOTp request. BOOTP server
NLM on Netware box is ignoring the request. Last version of MacTCP used
Broadcast address, and Novell server did fine. Anybody know what is
going on here?
 


-- 
                                       Andy Johnson
                                       Westinghouse Savannah River Company
                                       ajj@srs.gov
                                       (803) 644-1493

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1993 19:33:56 GMT
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP BOOTp Multicast

ajj@beta.lanl.gov (Andrew J. Johnson) writes:

>Latest version (2.0.2) that I have of MacTCP uses a Multicast
>address (01005E7FFFFF) to send out BOOTp request. BOOTP server
>NLM on Netware box is ignoring the request. Last version of MacTCP used
>Broadcast address, and Novell server did fine. Anybody know what is
>going on here?

This is a bug in 2.0.2. It will be fixed in 2.0.3. I don't know when
it is due out, but it is in alpha test.

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

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1993 18:52:04 +0100
From:      cmft@doc.ic.ac.uk (C M F Tsang)
To:        comp.protocols.tcp-ip
Subject:   How to send ICMP packets?


I am trying to send some ICMP packets to some machines, the system
we are using is SunOS, i.e. bsd Unix. I know you can open a TCP
socket in bsd and use services like whois, but I can find the 
method to send a raw ICMP packet, indeed an IP packet down the net.

Could someone advice me how to do it? The basic thing I know is
to open a RAW UDP socket, but I'm not sure about how to assemble
the packet and write it, and how to receive the reply?
Do I use recv, recvfrom ... which of that lot?

Thanks for any help or pointers.

Frank Tsang


-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 93 21:35:27 GMT
From:      yeh@netix.com (Mr Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   a question

Hi,

One month ago, a Chinese student at UIC.EDU sent us hundreds of pages of junk 
FAX by using UIC's computerized fax system (e-mail/fax), and this junk faxing 
caused damage to us.  One fact about this matter is that it was done 
intentionally in revenge to a Netix employee's personal opinion of, "CSPA 
(Chinese Students Protection Act), which allows dozens of thousnads of Chinese
students to become legal immigrants as long as they delcare their trouble with
the Chinese government, is the abuse of assylum, and those Chinese students 
simply use whatever excuse to stay in the US".  But we are not sure if UIC is 
obligated (required) to release that user's identity according to the current 
internet regulations.  So far, neither did UIC tell us who that user was, nor 
did they agree to solve this problem positively, nor did they make any 
apology.  All they told us is: 1) they like to protect their student; 2) it
will not happen again.

Could someone offer me some knowledge on this?


thanks,

shannon
-------

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 09:26:35 -0700
From:      koreth@spud.Hyperion.COM (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In <1993Aug31.083904.18521@ucl.ac.uk> ccaajac@ucl.ac.uk (Jon Crowcroft) writes:
>see also
>1335  Two-tier address structure for the Internet: A solution to the problem
>      of address space exhaustion.  Wang, Z.; Crowcroft, J.  1992 May;

Aha, hadn't noticed that one.  That's sort of what I had in mind, though
my conception of it was a bit simpler.

The advantage of doing it the RFC's way is that it'll let internal machines
pass packets to the outside world as desired, assuming there is some internal
host doling out temporary external addresses and the machines in question
have been modified to handle dual-address network interfaces.

What I was talking about is, of course, more limited, since it really only
applies to nets that can't talk to the outside world directly.  But it would
be considerably easier to implement, given that it requires no changes to
anyone's network software, just an extra firewall machine and a couple of
address changes.

Of course, neither proposal precludes the other, since either can be applied
to any given site without affecting the outside world.

-Steve

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 22:17:36 GMT
From:      oosten@$LOGNAME@ee.ualberta.ca (Brian Oostenbrink)
To:        comp.protocols.tcp-ip
Subject:   HELP?? SLIP and modems

I am trying to implement a slip connection between two IBM RS6000's 
(AIX 3.2.3) over a pair of modems using the builtin slip software. 
My problem is that I can't get the slattach command to dial the modem 
like IBM says it will.  Has anyone gotten this to work??
Alternatively, is there any easy way to initiate a connection between
the modems using cu or tip, and then allowing slattach to take over the 
tty port??

Any help you can offer would be most appreciated

--
***********************************************************************
Brian Oostenbrink
Department of Electrical Engineering
University of Alberta

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

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 23:11:34 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   SCO Slip

Gentle Folk:

I am trying to get slip to work between two SCO machines running 
SCO Unix ver 3.2.4...I can get some activity out of the modems, but
it just does not want to work (activity = if one ping's the other, I see the
lights blink, but I never get a response from my pings..)

Has anybody done this / any suggestions / help would be appreciated...


Larry Krone
swslr@well.sf.ca.us


-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Aug 1993 23:35:38 GMT
From:      naran@fraser.sfu.ca (Ranger Mau'Dib)
To:        comp.protocols.tcp-ip
Subject:   Looking for an NNTP server

Hi,

	I'm looking for an NNTP server I can connect to. The access I have is
through my University account but my university's nntp server won't accept
external connections. E-Mail or follow-up, your choice. Thanks in advance!

-- 
--------------------------------------------------------------------------
Travers Naran                                           | "We fear
Mail address: naran@fraser.sfu.ca or naran@sfu.ca       |  change. WHACK!
Simon Fraser University, British Columbia, Canada       | WHACK! WHACK!"
Cmpt. Science student wanna-be                          | -Garth 
Trekker, Leaper, Red Dwarf'er, Prober, etc.             |  "Wayne's World"
--------------------------------------------------------------------------

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 00:15:18 GMT
From:      bleys@vpnet.chi.il.us (Bleys Ahrens)
To:        comp.protocols.tcp-ip
Subject:   350 Site Unix network (Need advice.)

We are in the process of creating a WAN with 350 sites (each with a
Unix server) connected via 56K VSAT satellite connections.  Because
of the nature of the satellite network, groups of sites share outgoing
paths (i.e. all 350 sites can't be transmitting at once.)  This means
that bandwidth is at a premium.  

The company that provides our satellite connection wants us to use
bridging at each of the sites.  Several of us feel that we would be
better servedr with routers at each site (either dedicated boxes or
use the server as an IP router.)

Each site will have Intel based PCs using PC-NFS to connect to the
unix server.  Each PC will also be capable of talking to the central
mainframe via TN3270 (a form of telnet).  

We are trying to compile a list of all the types of TCP/IP traffic
and how they will be different if we are using bridges or routers.

In particular, how do things like ARP, Reverse ARP, Proxy ARP, RIP,
broadcasts, multicasts get handles by bridges versus routers.  Also,
which actions will cause the above mentioned types of traffic.  
        
Comments and suggestions from administrators with practical experience
in these areas will be greatly appreciated.  Email is prefered, due
to a short expiration of this group on my news server.

Thanks.

Bleys Ahrens

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 01:44:48 GMT
From:      sh7000157@ntuvax.ntu.ac.sg
To:        comp.protocols.tcp-ip
Subject:   Unix Talk On PC?

Hi,

I'm looking for a program that is similar to the Unix Talk that can
run on MS DOS.  Could anybody out there give some pointers as to if
such a program is available?

sim huat
email : sh7000157@ntuvax.ntu.ac.sg


-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 93 04:42:51 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket Shutdown

In article <CCKsLx.Cv8@ncratl.AtlantaGA.NCR.COM>, brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama) writes:
| We have a TCP/IP application written using sockets.  We are trying to simulate
| a failure by disconnecting the ethernet segment from the back of the machine.
| At this point a timer kicks in, and we do a shutdown.  But this shutdown never
| completes.  Looking at the stack trace, one can see that the application is
| trying to do the close but the close doesn't finish.  What is strange is that 
| when I try to sdb the process, the process will be released and he will try
| to reconnect again to the server.  Now my question is how do you force a close
| in TCP/IP using sockets? How do you force an immediate shutdown of the socket?

This question comes up from time to time.  There is an answer, but it sometimes
generates controversy.  The trick is to do a ``hard'' close.  Under most BSD-
derived socket implementations, you can accomplish this by enabling the linger
option (SO_LINGER) with a linger time of 0 before closing the socket.  A RST
will be sent to the peer and the socket will be discarded immediately.  Now,
some will argue, this is not a very graceful way to close a tcp connection.
But that's the idea...

				Dan Lanciani
				ddl@harvard.*

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 08:39:04 GMT
From:      ccaajac@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <746700817snz@peeras.demon.co.uk>, proyse@peeras.demon.co.uk (Phil Royse) writes:
|> In article <25rud8$hi2@spud.Hyperion.COM> koreth@spud.Hyperion.COM writes:
|> >
|> >Then it occurred to me: Why can't nets behind firewalls use the entire IP
|> >address space as they see fit?  
|> 
|> Yes, I have been nudging this issue around for months.  I am
|> developing an IP internetworking strategy for a large UK organisation
|> who DOES NOT WANT to be connected to the Internet ...  (except
|> a few workstations in a medical physics department.... :-)
|> 
|> >
|> >Maybe I'm crazy, but it seems to me that firewalled organizations should
|> >only need a few class-C addresses assigned to them officially; they can do
|> >whatever addressing they want behind the firewalls, and nobody will be any
|> >the wiser.

see also

1335  Two-tier address structure for the Internet: A solution to the problem
      of address space exhaustion.  Wang, Z.; Crowcroft, J.  1992 May;

please check the rfcs, they _do_ hold a number of suggestions that are not entirely without merit:-)

-- 
jon crowcroft (hmmm...)

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 16:11:44 -0400
From:      phoff@panix.com (Phill Hoff)
To:        comp.protocols.tcp-ip
Subject:   traceroute documentation

Can someone tell me where I can get the documentation on traceroute.
I have the binary, but need to know exactly what it is telling me.

Regards,
Phil

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 16:45:51 -0400
From:      jaitken@csugrad.cs.vt.edu (Jeff Aitken)
To:        comp.protocols.tcp-ip
Subject:   A (not-so) simple question

     I have a DECstation and a PC which I would like to connect via
ethernet.  I have a rather odd situation however.  My link to the
outside world is through a SLIP connection on the DECstation.  My
DEC's IP address is 128.173.18.165.  I cannot get a second IP address
so I need to just pick a bogus one for my PC.  Problem is, I need to
insure that no computer other than my DECstation knows about the PC.  

Perhaps a diagram will help...

                                                      /\
  +-------------------------+                         ||
  +         beavis          +-------------------------||
  +                         +      SLIP Connection    || <-- Campus backbone
  +       DECstation        +-------------------------||       (ethernet)
  +     128.173.18.165      +                         ||
  +-------------------------+                         ||
             /\                                       \/
             ||
             ||
             ||
             ||  <-- My LAN (such as it is)
             ||            (ethernet)
             ||
             ||
             ||
             ||
             \/
  +-------------------------+
  +       butthead          +
  +                         +
  +          PC             +
  +        x.x.x.x          +
  +-------------------------+


How can I configure this to work?  I don't know too much about
networking, but I believe I need to create a bogus subnet for the PC.
At least that's what I was told :)  I actually think I have a decent
idea of the basic principles, but I need help actually doing it.  I
would also like to do this right the FIRST time, as I don't want to
cause screwy network problems for anyone...

Thanks for any help,

Jeff
-- 
Jeff Aitken                     |     
jaitken@csugrad.cs.vt.edu       |     Someone who can't lead and won't
DEC User's Group Vice President |     follow makes for an excellent
Va. Tech Computer Science Dept. |     roadblock.

-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 10:17:52 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP utilities source

Where can I get source for ping, ftp, telnet, remsh, rcp, etc?

Could somebody explain the SO_LINGER option?  When should it be set?
What's is the default value if not set?  In one of my programs, I did
a getsockopt call for SO_LINGER, and the structure returned all zeroes.
Is the default the linger a period of 4 minutes for connection establishment,
and to linger till data transfer is completed on a socket close?  Is this true?
-- 

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 11:30:07 GMT
From:      ben@piglet.cr.usgs.gov (Ben A. Mesander)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP utilities source

In article <CCMCLt.Kyp@ncratl.AtlantaGA.NCR.COM> brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama) writes:

>   Where can I get source for ping, ftp, telnet, remsh, rcp, etc?

The source code to BSD UNIX, including all the tcp/ip stuff is available for
anonymous ftp. A good place to look for it is:

gatekeeper.dec.com:pub/BSD/net2

--Ben

-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 93 19:23:06 -0400
From:      "Andrew Luck" <p00078@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Performance ? re:SMC8003

While running ftp over ethernet to several hosts, i.e  sun ipx,
intergraph, we notice some performance anomolies.  We use several type
of network cards in our PC clients, including SMC & 3COM.  Generally the
performance is fine (>50 Kb/sec) except when going from a PC with an
SMC8013 to a unix host where performace drops to 1/10th of that or less!
Any suggestions regarding known limitations in hardware or drivers, or 
where else we might look for clues, would be appreciated.

Thanks in advance.



-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 93 22:31:56 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewalls could help put off the IP address shortage

In article <CCnGGJ.5ro@joymrmn.on.ca>, marcelm@joymrmn.on.ca (Marcel Mongeon) writes:
> a20@nikhef.nl (Marten Terpstra) writes:
 [munch]
>>Well, let me say once more what I suggested just some days ago (and many with
>>me). What if we reserve a class A, some Bs and some Cs just for this purpose ?
>>If everyone knows what the numbers are, then it would be simple to install
>>filters to simply never route this net, never send any packet to this net ...
>
> There is actually a great Class A address available for this.  The address
> is 127.  Sure 127.0.0.1 is a reserved loop-back address but you can make a
> lot of machines work on other addresses in this space.

And thus none of these TCP/IP stacks are compliant with RFC 1122.
Doesn't sound like such a great idea to me.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax
Disclaimer: These are my opinions, not those of Indiana University.

-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 14:45:00 GMT
From:      eks@daimi.aau.dk (Eigil Krogh S|rensen)
To:        comp.protocols.tcp-ip,comp.unix.sys5.misc,comp.unix.sys5.r3
Subject:   Nameserver problem

Please help me with the following problem:

I have to configure a Motorola sysV/69 R3V6.2 to use an external Nameserver.

How do I do that correct ?

What I've done until now is to create the file  /etc/resolv.config
with this content:

nameserver  name-server-address

But that seems not to be enough. It can't find the nameserver.

Any help and hints are wellcome.

Thanx

Eigil Krogh Sorensen


-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 15:06:09 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Unregistered Class A network

In article <1993Aug19.163205.20462@ajax.rsre.mod.uk> hearn@minotaur.dra.hmg.gb (Dave Hearn) writes:
>WiseGuy (sysdhw@atscv1.gsfc.nasa.gov) wrote:
>: There are some people who are thinking of using an unregistered Class A
>: address for their IP network.  I am not a fan of this idea.  A direct
>: connection from the Internet would then be unlikely ;-), but they would
>: then have all of the addresses they could possibly need.
 
>: I'm looking for some good PLUSES and MINUSES to pass along to them (to
>: help them in the decision making process).
>
>
>Well,
>
>they could do that.. but then .. I assume they never ever want to be connected
>to the net in the future..  Forever is a long time!
>
>I would hate to be the guy who had to administer a massive overnight 
>reassignment of Internet addresses across such a net. They sure would have to 
>if they chose to follow the unassigned class A net route.
>
>
>Dave 

Depending on how quickly you believe the IP:TNG protocol solution(s) will be
adopted and deployed, this could be a really bad idea, or it could be semi-ok.

The single point that comes up again and again in proposals of this type is
the "hiding" of at least one network (the one whose network portion of the
address field you are using), which is then inaccessible to your users (because
your routers don't have a clue).

I wish there was an obvious network number to choose (no reason to shoot
yourself in the foot with an unnecessarily large-caliber pistol). Network
10 (the original arpanet, now dismantled)? Could this network be set aside
(yea, I know it's a class A, but those aren't being handed out these days
anyway)?

This seems supportive of at least one of the IP:TNG proposals, which "hides"
interior addresses...

Spencer
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 15:35:12 GMT
From:      eks@daimi.aau.dk (Eigil Krogh S|rensen)
To:        comp.protocols.tcp-ip,comp.unix.sys5.misc,comp.unix.sys5.r3
Subject:   Re: Nameserver problem - Correction.

Thus spake eks@daimi.aau.dk (Eigil Krogh S|rensen):


>Please help me with the following problem:
 
>I have to configure a Motorola sysV/69 R3V6.2 to use an external Nameserver.
 
>How do I do that correct ?
 
>What I've done until now is to create the file  /etc/resolv.config
>with this content:
 
>nameserver  name-server-address
 
>But that seems not to be enough. It can't find the nameserver.
 
>Any help and hints are wellcome.


Naturally I meant  /etc/resolv.conf  instead of  /etc/resolv.config.


thanks
Eigil

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 15:39:03 GMT
From:      bleimeyp@wolf.mayo.edu (Paul Bleimeyer)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   **Syntax corp - How well do their Products work for you? Questionaire**

Hello, 

I am interested in hearing from people who are using the Syntax LM server  
and TotalMac server products. Below are a few questions concerning their  
product line.
We are considering testing the product as a replacement for PCNFS to allow  
native access to our preexisting Lan Manager pc based file servers. We are  
also considering replacing/supplementing our existing Kshare (mac server)  
product as well. If you have either the TotalMac or the LMserver product,  
I would really appreciate hearing from you. Please answer the questions  
that fit your site below and feel free to add comments at the end. All  
Answers will be kept confidential unless otherwise requested.


Syntax - LM Server and TotalMac products.

Which platform are you running you LMserver and totalmac software from?

How many systems are connecting to your server?

How much disk space do you have on your server?

How many servers are you running these products on presently?

How much disk, memory, cpu is in each one? How many users per server?

How many Netbuei sessions can your server handle concurrently?

How many Appletalk clients can your server handle concurrently?

How many printers do you have connected and which ones?

Any problems with the queue software from either side?

How will does the LM 2.2 client from Microsoft work with LMserver?

What clients are you running to connect to the server? 

What clients are you running to connect to the server? 

Which Transport do you use with the DOS/Windows PCs? TCP/IP or Netbuei?

Do you have an existing OS/2 based or NT based Microsoft LM Server that  
your users login to?

If so, how well does the account management between the two work for you?

How well does the file interchange and record locking work between the Mac  
and PC access? 

Any known problems when users on unlike systems open the same file? 



Support Section:

On average, over the past 12 months, how many calls have you made to 
the support number?

How many were resolved?

How long was the delay before getting an answer?

How many times were you promised a fix "in the next version" vs. just  
emailing or downloading a patch?

How long during a call did you have to wait for a tech support person to 
answer the hold line if there was any wait at all?

ON a scale of 1 - 5 (5 being the highest) how knowledgeable would you
rate syntax's tech support group on their knowledge of their product sets.

If you had to pick a platform you felt they were better at supporting for  
a server which one would you pick? Sun, Dec, RS6000, AT&T, etc.

Overall:

How would you rate the performance of your server? Is it faster than the 
pc file server you would have or did buy in the first place?
(please describe mac and pc separately.

At what point in the connection numbers does your server begin to drop off
in performance, and where does it first show up? I/O, Memory, Disk,  
Network Bandwidth, etc.

What did you do to correct the performance change, and were you  
successful?

Finally, If you had to purchase this product again, would you?
Why? (If yes or no, please tell me why?)

Additional Comments:

Thanks for filling out this list of questions and if there is something I  
can do in the future to return the favor, please email.
Fax Replies are fine as well. 

--
Paul Bleimeyer
Mayo Foundation
Rochester, MN 55905
(507) 284-5173 fax

-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 15:39:49 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: rawip broadcasts

In article <1993Aug30.180951.14318@unislc.slc.unisys.com> pradeep@unislc.UUCP (5730) writes:
>I tried posting this earlier, but apparently it didn't quite make it:
>
>I have an application that broadcasts over the network using rawip (protocol
>number = 255). The router on the network sends back an ICMP error with type = 3
>and code = 2 which translates to "Bad Protocol". None of the hosts on the
>network seem to do this.
>
>Is the router misbehaving?. Is it legal to use 255 as a protocol number?.

The Router Requirements draft states that a router should not respond to a
broadcast with an ICMP Error response.

I'd be a little leery of using protocol number 255, Assigned Numbers lists
it as "reserved".

Art


-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1993 15:40:26 GMT
From:      veit@acds10.physik.rwth-aachen.de
To:        comp.protocols.tcp-ip
Subject:   POP3-server problems with DECstation/ultrix3.4


Hi :-)
======
We have some trouble with the POP3-server (popper-1.831) running on a
DEC-station 5000/240 under ultrix 4.3.
The server is reachable under port 110 (=POP3).
Everthing works fine,
but the telnet-login asks two times for the login-name before asking
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
the password (???).
Nevertheless the remote login works properly and also ftp access.
The POP3-services are working as expected.
This double login doesn´t vanish when the POP3-server is not running,
you have to reboot the machine to get rid of the problem.

So any idea what´s about the double telnet-login question or what
might be going on there ?

thanks in advance

Andreas and Veit

veit@acds10.physik.rwth-aachen.de (email)


-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 16:55:10 GMT
From:      dedgar@Cybercon.nb.ca (Dale L. Edgar)
To:        comp.protocols.tcp-ip
Subject:   Specs on Talk Protocols????

Hello Net

I am looking for the specifications on the talk protocol(s). I have
done an archie search on "talk" and all that seems to turn up are a
variety of man pages on talk, ytalk, ntalk et.al. plus the odd bit of 
source code. Source is nice, but if one wishes to write a talk 
application a spec sheet is desirable.

Are protocol specifications for the talk protocol (similar to RFC's) 
available? Are there any doc's around which explain the differences
between the various talk protocols? Anybody care to shed some light
on how all of these protocols evolved and what one has to do to ensure
a home grown talk program is compatible?

All help and hints will be gratefully appreciated.

Thanks
Dale Edgar
Cybernetic Control Inc.
dedgar@cybercon.nb.ca

-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 17:05:00 GMT
From:      Andy Malis <malis_a@timeplex.com>
To:        comp.protocols.tcp-ip
Subject:   RFC 1356 (IP/X.25) experience wanted

My last plea for assistance went over like a lead balloon; please send a
reply if you can.

I am looking for any and all implementation experience with RFC 1356,
which is the multiprotocol update to RFC 877 (IP over X.25).  If you can
do ANYTHING at all other than IP over X.25 (such as CLNP or IPX), please
send mail to let me know - it does NOT have to be a full implementation.
Or if you can support 1356's larger IP MTU, again let me know.

I'm also interested in any interoperability experience you may have with
other 877 and/or 1356 implementations.

Thanks much for your assistance.  This information is strictly
confidential, to enable RFC 1356 to be advanced to Draft Standard.  It
will be summarized (numbers only, no names) for IESG use.

If for some reason you could answer but don't want to, please let me
know that as well, and we'll see if we can work around the problem (such
as having you reply directly to the WG chair or IESG area director).

Thanks much,
Andy
_______________________________________________________________________
____
Andrew G. Malis   malis_a@timeplex.com   -or-  
malis@maelstrom.timeplex.com
Ascom Timeplex    289 Great Rd., Acton MA 01720  USA         +1 508
266-4522

-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Aug 1993 17:59:20 GMT
From:      schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder)
To:        comp.lang.tcl,comp.protocols.tcp-ip
Subject:   tkined-0.5 and scotty-0.6 available for ftp

The second public release of our network editor tkined is now available
from ftp.ibr.cs.tu-bs.de [134.169.34.15]. The files are:

	/ftp/ibr/pub/local/tkined-0.5.tar.Z
	/ftp/ibr/pub/local/scotty-0.6.tar.Z


What is tkined?

tkined is a drawing program that allows you to produce maps of your
network configuration. But the most important feature of tkined is
its programming interface that can be used to turn the editor into a
network management system. tkined provides commands to present status
information in stripcharts, barcharts or as piecharts.


And what about scotty?

scotty is a tcl interpreter that has extensions to set up TCP
connections, to submit ICMP packets and to query various RPC services.
There are some sample scripts for troubleshooting your network
(ping, traceroute, finger, query tcp services, query RPC services),
for monitoring network status and to layout your IP network map.


Whats new in tkined-0.5 and scotty-0.6 ?

	- tkined is now a real binary. You do not need addinput
	  anymore. But you still need tk 3.2 / tcl 6.7
	- group objects are here
	- speed up

	- scotty has a dns command to query the domain name system
	- extensions of the scotty scripts to make use of group objects


Where do I report bugs and suggestions?

If you have problems or if you have made any changes to run tkined and
scotty on your hardware or if you have found any serious bugs, please 
contact us. You are also invited to join our tkined mailing list.
To join, send a request to tkined-request@ibr.cs.tu-bs.de. Messages
that are to be distributed by the list should be send to
tkined@ibr.cs.tu-bs.de.

We would also like to collect icons for all kinds of machines. If you
make new icons and if you are willing to share them with us, please
drop us a note (and the icons :-). 

						Juergen


-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 93 01:39:01
From:      adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
To:        comp.protocols.tcp-ip,comp.unix.sys5.misc,comp.unix.sys5.r3
Subject:   Re: Nameserver problem - Correction.

In article <25vr3g$5ph@belfort.daimi.aau.dk> eks@daimi.aau.dk (Eigil Krogh S|rensen) writes:

   Thus spake eks@daimi.aau.dk (Eigil Krogh S|rensen):


   >Please help me with the following problem:
 
   >I have to configure a Motorola sysV/69 R3V6.2 to use an external Nameserver.
 
   >How do I do that correct ?
 
   >What I've done until now is to create the file  /etc/resolv.config
   >with this content:
 
   >nameserver  name-server-address
 
   >But that seems not to be enough. It can't find the nameserver.
 
   >Any help and hints are wellcome.


   Naturally I meant  /etc/resolv.conf  instead of  /etc/resolv.config.


   thanks
   Eigil

Hallo Eigil,
to make this work, a new bind library, which would actually use a nameserver,
would be a prerequest. As all binaries a statically linked under sysV68, 
porting BSD bind lib would not be sufficient.... 

If you succed, PLEASE POST zour solution ....

best, adams

END OF DOCUMENT